Details: Category: Developer News

A common misconception is that Capacitor ONLY works if you have a React, Vue, or Angular app, but did you know that it works for other frameworks as well? I recently began my journey into learning Sveltekit and discovered that Sveltekit apps can use Capacitor as well as be deployed to iOS and Android just like those other frameworks. Let’s take a look at how you can use Svelte with Capacitor and create cross-platform apps like you can with React, Vue, or Angular. A demo of the project can be found on GitHub.

Sveltekit

What is Sveltekit? According to the Sveltekit website, it’s a UI framework that allows you to write concise components with HTML, CSS, and JavaScript built on Svelte and Vite. It’s a completely free open-source software that’s growing in popularity. While the Sveltekit team classifies it as a love letter to web development, I’ve recently discovered that it just might be crushing on cross-platform development with how easy it is to get it to work with Capacitor… (Don’t worry Sveltekit, your secret is safe with us).

Getting a Sveltekit project setup is incredibly simple. Just start with creating my-app:

npm create svelte@latest my-app

Select Skeleton Project and select Yes, using TypeScript syntax if you are using TypeScript:

When prompted for additional options, I selected Add ESLint for code linting but select the option that’s best for your project:

Once that is completed, we’ll need to go into the app directory and install all the boilerplate libraries:

cd my-app
npm install

Then open the project in your IDE of choice and run the project from the built-in terminal:

npm run dev -- --open

This should open up the application on https://localhost:5173/:

Capacitor

Once you have your Sveltekit project, we’ll need to get Capacitor running with the default Sveltekit project by installing @capacitor/core, @capacitor/cli, @capacitor/geolocation (we’ll be using geolocation later) and create the config (I’m using the default options so make sure you adjust these to work for your project as they’ll likely vary when/if you get to mobile deployments):

npm install @capacitor/core @capacitor/cli @capacitor/geolocation
npx cap init

Once installed, we’ll need to build the web app to compile everything:

npm run build

With the build completed, let’s test add a native Capacitor call to our Sveltekit project by updating src/routes/+page.svelte file:

<script>
    import { Geolocation } from '@capacitor/geolocation';

    let loc = null;
    async function getCurrentPosition(){
        const res = await Geolocation.getCurrentPosition()
        loc = res
    }
</script>

<div>
    <h1>Geolocation</h1>
    <p>Your location is:</p>
    <p>Latitude: {loc?.coords.latitude}</p>
    <p>Longitude: {loc?.coords.longitude}</p>

    <button on:click={getCurrentPosition}>
        Get Current Location
    </button>
</div>

<style>
    div {
        padding-top: 50px;
    }
</style>

With the landing page updated, navigate back to https://localhost:5173/ and we should see the generic Geolocation page. If you click on Get Current Location in the browser, you should be prompted to share your location and you’ll get your current coordinates if you agree to share your location:

If you are just looking to integrate Sveltekit and Capacitor then you are done! However, if you want to take your Sveltekit projects to mobile then continue reading.

Sveltekit On Mobile

In order to get Sveltekit on mobile, we’ll need to make some changes to our project. First thing is to update our capacitor.config.ts file webDir config option to “build”. Why do we do this? When we alter our Sveltekit project, we’ll be turning it into a static application and it will build our application to a folder called build:

import { CapacitorConfig } from '@capacitor/cli';

const config: CapacitorConfig = {
  appId: 'com.example.app',
  appName: 'my-app',
  webDir: 'build',
  bundledWebRuntime: false
};

export default config;

Now that we’ve updated our Capacitor settings, let’s change out Sveltekit project to a static application by downloading the proper static adapter package:

npm i -D @sveltejs/adapter-static

After the package is installed, we’ll need to alter svelte.config.js file from the auto-adapter to static:

import adapter from '@sveltejs/adapter-static';
import { vitePreprocess } from '@sveltejs/kit/vite';

/** @type {import('@sveltejs/kit').Config} */
const config = {
        // Consult https://kit.svelte.dev/docs/integrations#preprocessors
        // for more information about preprocessors
        preprocess: vitePreprocess(),

        kit: {
                // adapter-auto only supports some environments, see https://kit.svelte.dev/docs/adapter-auto for a list.
                // If your environment is not supported or you settled on a specific environment, switch out the adapter.
                // See https://kit.svelte.dev/docs/adapters for more information about adapters.
                adapter: adapter({
                        // default options are shown. On some platforms
                        // these options are set automatically — see below
                        pages: 'build',
                        assets: 'build',
                        fallback: null,
                        precompress: false,
                        strict: true
                })
        }
};

export default config;

With the svelte.config.js updated, we’ll need to add a prerender option by creating a +layout.js page to src/routes and just add the following export to +layout.js:

export const prerender = true;

After adding and updating the +layout.js page, we’ll need to add our mobile platforms, re-build our project to create the build folder, and sync our web app to Capacitor to get our mobile dependencies updated:

npm install @capacitor/android
npm install @capacitor/ios
npx cap add android
npx cap add ios
npm run build
npx cap sync

The next part is dependent on if you’ll be running Android, iOS, or both but you’ll need to configure the permissions to allow Geolocation to run on your device. For more information on native device permission, please visit the @capacitor/geolocation documentation. For Android, you’ll update the AndroidManifest.xml file at android/app/src/main/AndroidManifest.xml in your IDE and for iOS you’ll update the info.plist file once you open the project in XCode.

Open your Sveltekit project in iOS/Android:

npx cap open ios
npx cap open android

Run your emulator and your Sveltekit app will be running on mobile!:

Final Thoughts

While setting up Sveltekit with Capacitor may be different than React, Vue, or Angular it is entirely possible to make your Sveltekit project cross-platform. All it takes is a little configuration and a few minutes of your time to make your project work on the web or mobile. If you have any questions about getting your Sveltekit project set up with Capacitor feel free to ask the Ionic team at our official Discord server!

The post Cross-Platform Sveltekit & Capacitor Application: Yes It’s Possible! appeared first on Ionic Blog.

Details: Category: Developer News

In April 2022, Microsoft App Center deprecated Cordova support, a true sign of the waning popularity of the framework. Despite its decreasing popularity, and a shortening list of tools to support the development of apps with the SDK, it’s estimated that around 180 companies (including many fortune 500 companies) still use Cordova in their tech stack. With months of no updates, many are finding themselves looking for an alternative platform.

Enter Capacitor. Ionic’s open-source powerhouse is the perfect replacement for those looking to migrate from Cordova. Improved developer experience, consistency, and tons of support are just some of the highlights of Capacitor. But how can you tell that it’s time to make the switch?

Are you frustrated with compatibility plugins?

Cordova iterates slowly and requires a set of plugins that exist solely to augment the build system. If a plugin author wanted to write Cordova plugins using Swift and Android X libraries, they’re out of luck because Cordova doesn’t support them out of the box. To solve this, “compatibility plugins” need to be created and used in addition to the functional plugins which require newer native compatibility. This means valuable development resources going toward creating these plugins or relying on the community.

Cordova also forces you to manipulate native projects through hooks, which can lead to writing a lot of scripts to make modifications. These scripts are often difficult to troubleshoot when changes occur to the native environment.

In contrast, Capacitor leverages native projects as a source artifact. This allows developers to make adjustments to the actual Android and iOS projects to enable capabilities such as Swift or Android X libraries without needing to create or use any compatibility plugins, additional unnecessary hooks, etc. Capacitor also doesn’t require creating native iOS and Android projects from scratch every time, saving development teams time and headaches. Ionic offers a core set of plugins that cover a range of common native API needs, and the community maintains a slew of other plugins to choose from. However, if you can’t find what you need, it’s simple to open the native project directly and implement that functionality or quickly build out your own plugin that can then be used in multiple projects.

Do you wish your teams could work together seamlessly?

Cordova works through an abstraction layer that manages the underlying native platform project and source files for you. This makes it harder to drop down to native code or work with a traditional native mobile development process. This can also result in custom changes being lost.

On the other hand, Capacitor apps are actual native apps, so a key design consideration is that Capacitor embraces native tooling. It enables teams that have a mixture of traditional native mobile and web developers to collaborate on mobile app projects without worrying about losing any changes. Developers can also quickly add custom native code for specific platforms and optionally expose that code to the Web layer, ensuring an app team never gets stuck when implementing new functionality.

Are your security plugins outdated?

If you’re handling sensitive data like personal information or financial data in your Cordova application, security may be a concern. The security posture of your application is ultimately left up to you, or the Cordova community, to maintain and update. This popular secure storage plugin was forked from the original in an effort to keep it updated but has since been left untouched for nearly three years (at the time of writing). There’s also a widely used biometric plugin that has sat idle for more than a year. Without SLAs to lean on, there is simply no guarantee that the plugins that your applications may rely on will remain up to date with the latest iOS and Android security policy changes.

With Capacitor, you have the option of leveraging plugins that were specifically designed for the platform, rather than relying on third party or home-grown solutions. With guaranteed SLAs, Ionic takes ownership of ensuring that Capacitor and Capacitor plugins meet the ever-changing security demands of development ecosystems.

When you build with Capacitor, you can also add on a slew of enterprise-grade features that ensure security is baked in from the outset of your project. Enterprise plugins, such as Auth Connect, provide enhanced security features which makes it easy to integrate with popular auth providers and custom solutions, from Azure AD to Auth0 and more. Meanwhile, Identity Vault allows you to add biometric protections to new or existing apps. Enterprise customers can also leverage Secure Storage, a powerful local database that makes it easy to encrypt, store, access, and manage data across all platforms.

If you’re already using our security solutions as part of a Cordova project, don’t worry – they work seamlessly with Capacitor, so migrating is a breeze.

Are you tired of having to add/remove platforms when errors occur?

Cordova projects tend to lack a fundamental piece of functionality: version control. When building with Cordova, your native projects are build artifacts that are generated with each build. As a result, modifications to the native projects need to be handled through obscure markup in an XML file or via code patching by way of Cordova hooks. Both of these methods are potentially fragile.

In addition, when developing with Cordova, it is common for developers to have to remove the native projects and regenerate them on a regular basis. Often a new plugin is added or changes are made to the config.xml file. Sometimes those changes are propagated to the existing native platforms and everything works fine. Other times, the native applications will behave oddly because changes were not propagated properly and developers need to completely remove the platforms as well as the plugin cache and regenerate them. The problem is the time wasted figuring out when they need to do this versus when they have another issue that needs to be addressed.

When building with Capacitor, your platforms are easily version controlled, allowing you to better manage projects if any errors do arise. This means a cleaner final product and less time and resources wasted during development.

Do you wish you had some support?

Official support for Cordova ended back in 2020 when Adobe shut down PhoneGap. These days, Cordova is driven by volunteers that operate on a group consensus system. The open-source project is not driven by business goals nor do they prioritize the needs of any specific user.

Since Capacitor is a key aspect of Ionic’s mobile infrastructure and the infrastructure of its customers, security and functionality issues are discovered, fixed, and released quickly. There are teams of engineers, product managers, and customer success experts dedicated to customer and project success. Capacitor is currently used by thousands of developers worldwide with a robust community behind it.

Beyond Capacitor’s widespread community support, Ionic offers Enterprise Support and Advisory services for enterprises building mission-critical apps. With guaranteed response SLAs throughout the app lifecycle, our professional support team is on-hand to help you troubleshoot and address issues occuring at the native layer. Enjoy peace of mind knowing that you have a team of mobile experts with you every step of the way as you build out your next project.

Are you worried it’s too hard to migrate? (It’s not)

While migration may seem intimidating, it’s not as difficult as you think. Capacitor has backwards compatible support for a large swath of existing Cordova plugins. Following migration, you can enjoy a smoother build process, improved developer experience, and better end product.

In short, you’ll first add Capacitor to your projects and modify them appropriately. Then, you’ll migrate your plugins, set permissions, and update your preferences. Lastly, you’ll set the scheme and remove Cordova from the project.

We wrote up a handy migration guide to walk you through the process, step by step.

If you still have questions, reach out to us for Support and Advisory services and we can provide bespoke suggestions for your app needs.

The post Signs It’s Time to Migrate Your Cordova App appeared first on Ionic Blog.

Details: Category: Developer News

Configuring and managing build environments is critical in mobile development, but keeping everything organized can feel like a job even Marie Kondo couldn’t handle. Without build environments, ensuring you have the right tools in place to successfully build your app is cumbersome at best. One wrong configuration value and your build pipeline can come to a screeching halt.

A build environment is essentially the collection of dependencies and configurations needed to build your app. Now multiply that by each platform, version, and delivery channel, and you have a lot of environments to manage. Fortunately Appflow, Ionic’s mobile DevOps solution, is designed for easily managing build environments to ensure your app is built and deployed consistently across all platforms.

Appflow manages the dependencies for you by providing build stacks and provides multiple options for easily specifying configuration details.

Custom Environments

Mobile teams will typically have multiple versions of their application, such as for testing or internal use, as well as for each supported platform like iOS and Android. Each of these versions will have different configurations, such as:

API endpoints
Version code, name, or number
Bundle identifier
API keys or other credentials

These are typically managed with environment variables and secret keys that are set for each specific build environment. Managing these manually can be difficult, but Appflow lets you define and store custom environments to streamline and simplify your automated builds.

To create a custom environment, go to Build > Environments. Give your environment a name and provide key/value pairs for secret keys and environment variables for that environment. Keep in mind that secret keys cannot be viewed once set.

Once created, you can choose a custom environment from the Builds or Automations screen to make variables and secret keys available during build time. The environments can be updated at any time, allowing for security best practices such as key rotation.

iOS Schemes and Android Variants

Appflow custom environments are particularly powerful when combined with Appflow’s iOS Schemes and Android Variants support. Use the `IOS_SCHEME`, `ANDROID_BUILD_TYPE`, and `ANDROID_FLAVOR` environment variables to use a scheme or variant defined in your project, and Appflow will apply it during the build. This means you won’t have to duplicate configurations you’ve already defined in your Android or iOS project.

Native Configurations

For specific configuration overrides such as the app name or bundle ID, or to customize variables for Appflow Live Updates, you can also leverage built-in custom native configurations. Just like custom environments, native configurations can be defined and selectively applied at build time for native iOS and Android builds.

Ad-Hoc Environments

While predefined custom environments make it easy to manage build environments for your most common build types, sometimes you need flexibility for a single build. This is helpful when testing new environment changes before adding them to your regular workflow or for unique one-off changes.

To support this nimble workflow, Appflow introduced Ad-Hoc Environments that allow you to set or override environment variables for a single build. From the build screen, you can pass key/value pairs which apply to that specific build only. These values are not saved after the build, and it’s not recommended to use sensitive data.

If you’d like to create and save a new custom environment from the build screen, use the Environment section.

Get Started

Appflow custom environments and ad-hoc environments are now available for all Appflow plans. To leverage them for your mobile deployments, sign up for a free account today and start building. If you have any questions about getting started, our team is here to help.

The post Managing build environments in Appflow appeared first on Ionic Blog.

Details: Category: Developer News

Hot on the heels of our second alpha, we’re releasing a third (and unexpected) alpha for v5.3.0 today with some fixes for some Node Sass compilation errors. In addition, we’ve added a handful of other updates. We’re still on target to ship our stable release soon!

Once again, if you’re new to the v5.3.0 alpha releases, please read through the Migration guide for the first alpha and last month’s second alpha.

Here’s a look at what’s changed in this quick release:

Fixed wrong interpolated variables with node-sass/Hugo.
Added a check for interpolated variables to catch compilation errors with Node Sass when using Sass variables in calc() functions.
Started using --bs-border-radius variables across more components.
Added .d-inline-grid utility class.
Fixed .tooltip-inner placement when using variations in fallbackPlacements.
Fix selectors for dark mode carousel overrides when compiling with $color-mode-type: media-query.
Updated the styling of floating labels when “floated” to include a background-color to help with multiple lines of text in textareas. This also fixes the colors when form elements are disabled in floating forms.
Updated RFS to v10.0.0.

Get the release

Head to https://getbootstrap.com for the latest. It’s also been pushed to npm:

npm i This email address is being protected from spambots. You need JavaScript enabled to view it.

Read the GitHub v5.3.0-alpha3 changelog for a complete list of changes in this release.

Support the team

Visit our Open Collective page or our team members’ GitHub profiles to help support the maintainers contributing to Bootstrap.

Details: Category: Developer News

Today, we are excited to announce the release of Ionic 7! This stable release of Ionic comes after several betas and release candidates with improvements suggested by the Ionic community. Thanks to all of your contributions and the hard work of our team, we’re thrilled to officially bring Ionic 7 to market.

What’s new in Ionic 7?

Ionic 7 brings developer experience improvements when working with overlays, forms, and events! It also brings performance improvements for Angular, React, and Vue applications. Changes include:

Inline Overlays – Declarative overlays are now available on all overlay components, including action sheets, alerts, loaders, pickers, and toasts. You can now use every single Ionic overlay component without relying on controllers.
Consistent Event Emissions – In the past, ionChange would unexpectedly fire due to value prop changes. Instead, we’ve changed the behavior to better align with native input elements, and ionChange will only fire as a result of user interaction.
Simplified Form Control Syntax – Improved compatibility with assistive technologies and less code boilerplate
Performance Improvements – Tab switches are up to 70% faster than they were in v6 with Ionic React and Ionic Vue. Thanks to optimizations in Stencil, Ionic components initialize quicker than they did in v6 with Ionic Angular.
Improved Vite Compatibility – We’ve removed the CommonJS entry points for Ionic React and Ionic Vue which makes Ionic easier to use with Vite and Vitest.
IonSlides – This has been removed in favor of using Swiper.js directly
IonVirtualScroll – This was an Angular-only solution, and we’ve decided to remove it in order to use a solution provided by more JS Frameworks.

Updated Documentation

The Ionic Docs have been updated with the latest usage examples: https://ionicframework.com/docs

We have also added a new “Upgrade Guides” section in the sidebar for developers updating from older versions of Ionic.

Starter Applications Tooling

With the release of the new Ionic CLI v7, all new Ionic React and Ionic Vue starter applications will use Vite. This tooling replaces the Vue CLI and Create React App tools used in previous starter applications. Since this change only impacts new Ionic apps created with Ionic CLI v7, developers can continue to use the Vue CLI and Create React App tools in their existing Ionic apps.

Be on the lookout for a blog post with more information about Ionic CLI v7 soon!

Getting Started

Developers can follow the Ionic 7 Migration Guide to update their existing Ionic 6 apps.

Looking to start with a brand new Ionic 7 app? Try our app creation wizard!

Please report any issues you encounter on our GitHub repo.

Thank you to everyone who tested or provided feedback during the Ionic 7 beta process. Thanks to you, we have a great product that’s sure to make development easier than ever. Stay tuned, as we have many more great improvements planned for Ionic in 2023!

The post <strong>Ionic 7 is here!</strong> appeared first on Ionic Blog.

Subcategories

Developer News

Page 10 of 161

Cross-Platform Sveltekit & Capacitor Application: Yes It’s Possible!