Today I’m thrilled to announce the 1.0 release of Capacitor, Ionic’s new Native API Container that makes it easy to build web apps that run on iOS, Android, Electron, and on the web as Progressive Web Apps—with full access to native functionality on each platform.

Capacitor containerizes your Web App and provides consistent access to Native APIs for every platform that app runs on. That means, for example, that accessing the Camera uses the same code on iOS/Android as it does in Electron and on the web. This makes it easy to build one web app that runs natively on mobile, desktop, and the web!

Ionic apps use Capacitor much like Cordova to seamlessly run your app across a variety of platforms without platform-specific code. However, Capacitor brings some significant changes to the Cordova approach that you’ll want to read more about below.

With this release, we are one step closer to making Capacitor the official native container for every new Ionic app, so read on to see what this means and how it will affect your Ionic development:

How Capacitor works

Imagine a typical web app: You probably have some framework code to make your app render and to manage business logic. It’s likely written using a typical framework like Angular, React, Vue, or something like Stencil. Below that, you’re probably using a UI system like Ionic to get quality UI controls.

For many Web Apps, there’s not much more to think about because your app generally runs in a browser and, for good security reasons, you only have access to the set of Web APIs natively supported in the browser. However, that’s not true when running in a Web View environment on mobile and desktop!

In this case, because your app is running outside of the typical browser sandbox, there’s no reason your web app can’t access every Native API available on the given platform. For example, using biometric authentication and storing data in the keychain.

However, it’s not straightforward to take a Web App, put it in a native Web View control (as opposed to a full browser like Chrome/Firefox/Safari), and then proxy JavaScript calls to native code, returning data to your Web App in the process.

This is what Capacitor does: it containerizes your Web App and puts it into a managed native Web View (if running natively), then it exposes native functionality to your web app in a cross-platform way. Capacitor then provides a simple way to expose custom native functionality to your web app (through plugins), along with tooling to work with the web app container on the command line.

How is Capacitor different from Cordova?

In spirit, Capacitor and Cordova are very similar. Both manage a Web View and provide a structured way of exposing native functionality to your web code.

Both provide common core plugins out of the box for accessing services like Camera and the Filesystem. In fact, one of the design goals with Capacitor is to support Cordova plugins out of the box! While Capacitor doesn’t support every plugin (some are simply incompatible), it generally supports most plugins from the Cordova ecosystem.

However, at each step Capacitor has taken a slightly different approach that we think developers will enjoy, though some have tradeoffs to keep in mind:

Native Project as Source Artifact

Capacitor generally expects you to commit your native app project (Xcode, Android Studio, etc.) as a source artifact. This means it’s easy to add custom native code (for example, to integrate an SDK that requires modifying AppDelegate on iOS), build “plugins” to expose native functionality to your web app without having to actually build a standalone plugin, and also debug and manage your app in the way that embraces the best tooling for that platform.

We think this is the right balance since resources like Stack Overflow and typical native app project management work exactly the same as they do for native developers of that platform. This helps you take full advantage of help resources when you run into platform-specific issues, and enable blended teams that have native and web developers to work better together.

However, there are tradeoffs with this approach. Upgrades require more manual work as you have to bring along your native project. You can’t just blow away your native project and recreate it (unless you haven’t modified any of it). Installing plugins doesn’t modify your project so you will need to make manual modifications to preferences files like Info.plist.

However, we find that being able to manage your native project fully ends up being a big relief as your project scales.

No more deviceready

Capacitor kills the deviceready event by loading all plugin JavaScript before your page loads, making every API available immediately. Also unlike Cordova, plugin methods are exposed directly as opposed to being called through an exec() function.

That means no more wondering why your app isn’t working and why deviceready hasn’t fired.

Embracing NPM & Easier Plugin Development

Capacitor embraces NPM for every dependency in your project, including plugins and platforms. That means you never capacitor install plugin-x, you just npm install plugin-x and then when you sync your project Capacitor will detect and automatically link in any plugins you’ve installed.

With that in mind, making it easy to build and share plugins was one of the major areas of focus for us with Capacitor. Developers of Cordova plugins know that it is not easy to build plugins, and it’s nearly impossible to build and test them as standalone projects without importing into an existing app as they are generally just a collection of source files without project scaffolding.

Capacitor makes a few big changes to how Plugins work that also makes them easier to build. First, instead of copying plugin files directly into a project, Capacitor requires your plugins to be Cocoa Pods for iOS or typical android libraries for Android. Then, capacitor comes with a plugin:generate command to quickly scaffold out plugin projects, complete with Xcode and Android Studio projects and unit tests.

We hope this focus on improving the plugin development experience means more plugins will get built and plugins will be better maintained over time. If you’re interested in building your own plugin for Capacitor, take a look at our Plugin Development Guide.

Updated Plugin APIs

Developers will likely appreciate some of the changes we’ve made to core plugins, like the Filesystem plugin which is much more node-like and avoids the now-defunct Web Filesystem API.

First-class Electron and PWA support

Capacitor embraces Electron for desktop functionality, along with adding first-class support for web apps and Progressive Web Apps.

In fact, we’ve taken it a step further by building out a collection of UI experiences for APIs like Camera that bring the native app UI experience users expect to Progressive Web Apps. We call this the Progressive Web App OS.

On top of that, building plugins that offer web functionality as a fallback is just as easy as adding a few files to your plugin! Capacitor will only use your web implementation if the native one is not available, so users can use the exact same API when running on iOS, Android, Electron, and the Web.

Local CLI experience

Capacitor provides a tiny CLI that is installed locally to each app. That means there are no global dependencies to manage and it’s easy to use different versions of Capacitor across every app you build.

But that’s not all, folks!

There are several other changes we’ve made to the experience, and developers will probably notice that Capacitor “feels” quite a bit different than Cordova. To learn more, follow our installation guide.

What about Ionic Supporting Cordova?

Though Capacitor is meant to one day replace Cordova in each Ionic app, that doesn’t mean we’re no longer supporting Cordova! In fact, we’ve been building out a number of new plugins and features for Cordova, with the goal of also supporting them in Capacitor. We think Cordova is a great project that has been a key asset to Ionic’s success, which is why we’re in no rush to replace it and will be supporting it for many years to come!

That being said, we are obsessive about the developer experience behind building apps with Ionic, and see Capacitor as the way we can control every aspect of it and better align the native layer with the goals of Ionic, so we do plan to push Capacitor more prominently as time goes on.

Who’s using Capacitor?

Capacitor has been “out” for a little over a year. Since then, we’ve seen some pretty amazing apps being built on it, along with some major enterprise customers adopting it for apps that you will very likely use one day.

Top global fast-food chains are deploying in-store experiences for mobile and desktop on Capacitor. Companies like Southwest are building out all new hire onboarding experiences on Capacitor and Ionic, and popular consumer apps like Sworkit have built their latest-and-greatest versions on top of Capacitor (and Ionic 4 in this case!).

That’s just a small sample of teams building on Capacitor. Are you planning on building your next app with Capacitor? This email address is being protected from spambots. You need JavaScript enabled to view it. We’d love to learn more and even do a case study if you’re interested.

Getting Started

Yesterday we recorded a special Capacitor launch webinar. In it we demo’d some of the Capacitor APIs and showed off how simple it is to add Capacitor to an existing Ionic app currently using Cordova plugins. Didn’t make it? The recording can be found on our YouTube channel.

You can also get started right away. It’s easy to drop Capacitor into any existing modern web app (that includes, of course, Ionic apps).

Thank you

Capacitor has been in the works since late 2017 when we started to explore creating an alternative to Cordova. We were driven by the desire to make some significant changes to the approach pioneered by Cordova, as well as fulfill the need to fully support desktop and web platforms as Ionic’s mission expanded to helping teams build great apps everywhere.

Since then, we’ve had some wonderful contributions from the community and I want to thank everyone that filed issues, submitted PRs, or just spread the word about the project.

Now that Capacitor 1.0 is here, we hope you’ll see why we’ve invested in this new project over the last year and a half. We’re truly just getting started and expect to see a lot more Capacitor in the future.

Get started with Capacitor Today!

Read more

Today, we’re thrilled to announce the release of Stencil 1.0 beta (what we’re calling Stencil One), featuring an all-new compiler architecture. It is not only able to better optimize your components, but is designed to be completely future-proof.

What is Stencil?

If you’re not familiar with Stencil, it is an open source (MIT) toolchain that builds reusable, scalable Design Systems by combining the best features from popular frontend frameworks and generating standard Web Components (instead of a third-party component model).

Stencil was first announced in 2017 at Polymer Summit by my colleagues, Adam Bradley and Max Lynch. Originally called “Ionic core” internally, Stencil was born out of our desire to solve our own JS Framework dependency problems and increase performance for Ionic Framework. As it turns out, Stencil ended up solving a lot more than that.

Building Stencil allowed us to release Ionic 4 for Angular, React, Vue, or for no framework at all, powering roughly 100 cross-platform UI components in two separate styles (iOS and Material Design). As a result, the Ionic Framework team is now able to focus 100% of its time on shipping the best collection of UI components, gestures, animations, etc. without having to worry about browser-support, framework integrations, or performance—as Stencil automatically applies these built-in best practices.

Over the last two years, we’ve been surprised and incredibly humbled by the groundswell of community adoption Stencil has garnered. The project has over 200 contributors around the world, with thousands of developers, teams, and large organizations building on it. Frankly, we couldn’t be more grateful!

With that said, let’s dive into some of the exciting features shipping with Stencil One.

Machine Learning-inspired Bundling

Stencil One uses a new bundling algorithm inspired by “word embedding”, a popular Machine Learning technique. It allows us to pack components more efficiently, therefore reducing the network throughput and round-trips. In order to do this, we generate a N-dimensional vector space where each component represents a coordinate. These coordinates are generated based on the previous static analysis of how components depend on each other. Later, the components that are located close enough in the vectorial space are bundled together. A blog post explaining this technique will be coming soon!

While we bundle components to reduce the number of scripts, Stencil relies on ES modules that execute natively in the browser. Today, all major browsers (Chrome, Firefox, Safari and Edge) implement ES2017 and ES modules, which means we don’t ship any runtime to load modules.

At the same time, we still support old browsers such as IE11, thanks to “differential bundling”, which automatically generates the smallest possible bundle for each browser based on their capabilities.

In addition, all the metadata collected by the compiler and the dependency graph generated by rollup can be used to automatically create “modulepreload” links, reducing the amount of network round-trips required to download all the JS in the critical path to zero. This drastically reduces the Time-To-Interactive of apps built with Stencil.

Advanced Runtime Removal

With the new compiler, Stencil now shrinks the size and number of bundles sent to users. The metadata collected during the static analysis phase is used together with tree-shaking to completely remove the parts of the runtime that are not used.

While the hello-world demo is clearly an artificial example, we are excited about being able to generate incredibly small dependency-free components that include only what they need. Our 133bytes Hello World app (including runtime) is an example of the power of the compiler.

This optimization also scales as the complexity of the components increases. Here’s an example with the TodoMVC app:

JIT-friendly Runtime

We have also profiled and refactored the runtime to be smaller and much faster at execution-time. The new runtime avoids patterns that lead to non-optimal bytecode (usually called optimization killers), improves our async scheduler, and adopts new APIs like Constructable Stylesheets, native ES modules, and native async-await.

In this benchmark, we add 8,000 ion-button components (yes, eight-THOUSAND) to an app. At first glance, ion-button might appear simple, but it hides a great deal of complexity. It’s comprised of many classes and nested elements which give it the professional and polished visual appearance on both iOS and Android. Put another way, this stress test is attaching more than 200,000 nodes to the DOM.

Historically, it took ~6 seconds to fully initialize the app with well over 269,000 nodes:

With Stencil One, the exact same test finishes in 3 seconds. That’s 2x times faster! In addition, the memory usage is reduced from 180MB to 80MB.

Best of all, Ionic developers don’t have to go through any painful rewrites. Instead, they will automatically unlock these performance improvements on their existing projects just from the compiler upgrade.

A lot more in Stencil One…

The above is just a preview of some of the amazing features built into Stencil One. Here’s what else it will ship with:

  • New prerendering architecture compatible with Shadow DOM and designed to be integrated with third party tools, such as Angular Universal.
  • Generation of raw web components that extend directly from HTMLElement.
  • A new and powerful plugin system for third party output targets.
  • A continuing effort to ensure Stencil is as future-proof as possible.
  • A new compiler architecture that relies on ECMA features instead of Typescript for metadata collection.
  • Better built-in generation of Service Workers.
  • Better asset generation for more efficient cache policies.

We can’t wait to dive into all of these topics in upcoming blog posts!

Building a Design System?

We provide expert Advisory services & Software to large companies around the world building out the Design Systems that their company’s software will be built on for years and years to come.

If you or your company would like our help along the way, as well as other software surrounding Stencil and Design Systems, check out our Stencil DS product offering for building future-proof, production-ready Design Systems at scale.

Try the Beta!

We’d love for you to test out the Stencil One beta and to give us your early feedback. Upgrading your components to Stencil One is as easy as running the following command:

npm install @stencil/core@one

And remember to look at our breaking-changes file for any changes you might have to apply to your app.

We also released a new version of our Docs, documenting some of the new APIs of Stencil One.

What’s Next?

The Stencil One 1.0 release sets an important milestone in the development of Stencil, switching focus from being solely an open sourced internal tool, to an actual product that can help any developer or company building design systems or blazing fast apps using pure web components.

We are currently targeting early June 2019 for the final release. This is just the beginning for Stencil.

Read more

The Capacitor team has been heads down the last few months preparing for a version 1.0 release, currently slated for early June. Here’s the latest news on the Capacitor beta.

Haven’t heard of Capacitor? It’s our new open source cross-platform app runtime that makes it easier to build web apps that run natively on iOS, Android, Electron, and the web. It provides web-focused APIs that enable an app to stay as close to web-standards as possible while accessing rich native device features on platforms that support them. The best part? It’s backward-compatible with Cordova, so you can comfortably switch your existing Ionic apps to it whenever you’re ready.

Bug Fixes and Enhancements

A majority of the team’s focus has been on Capacitor internals and ensuring the APIs are rock solid. This includes tweaks to the native project templates and as well as keeping dependencies up to date. Additionally, ensuring that Capacitor integrates smoothly with Ionic Angular, Ionic React, and the PWA Elements library.

We also added some community contributions. Special thanks to the following people:

maedewiza, javebratt, msepena, jabiinfante, stewwan, sbannigan

Looking to get involved with Capacitor? Check out the Contributing Guide.

Docs Refresh

In addition to working on Capacitor’s code, we’re taking a fresh look at the documentation. We’re continuing to update them – in the meantime, check out the updated Getting Started section, which includes revamped instructions on how to use Capacitor with Ionic.

Ionic + Capacitor Guide Now Available

The Ionic DevRel and Customer Success teams have kept busy creating two new Capacitor guides. Using Capacitor in an Ionic Framework App is available now and keep an eye out for “Using Push Notifications with Firebase in an Ionic Angular 4 App” soon.


But that’s not all! Please join me for a very special webinar on Wednesday, May 22nd dedicated to the latest news about Capacitor, an overview of the changes from the beta to the 1.0 release, and a live demo of all of the Capacitor native APIs. Maybe even details on when we’re planning to launch Capacitor 1.0 (early June 😅)?

Start Using Capacitor Now

Things are shaping up nicely for Capacitor as we head towards 1.0. Lots of enhancements (thanks in big part to our community contributions!), rolling updates to the documentation including in-depth guides, and a webinar next week.

Capacitor is ready now for your web and Ionic projects. A simple npm install and you’re off to the races!

Read more

After a brief hiatus, our Bet on the Web podcast is back with a new episode. This time, we’re chatting with David Dal Busco, the creator of DeckDeckGo and organizer of the Ionic Zurich meetup group.

David’s Ionic journey began when he was tasked with building a mobile app at work. He quickly found success with Ionic, Angular, and Firebase. Today, his stack of choice also includes building web components with Stencil.

In this episode of Bet on the Web, David walks us through DeckDeckGo, his incredible open source Progressive Web App presentation builder created with Ionic 4 and custom web components (powered by Stencil). The idea came about after he was tasked with delivering a presentation on web components for work colleagues. DeckDeckGo was born after he decided to apply his newfound knowledge of web components towards creating an app.

Please join us for a deep dive into how David built DeckDeckGo, how Stencil makes it easy to build web components, and details on how app frameworks like Angular fit alongside web components. Tune in below or wherever you enjoy podcasts. Happy listening!

Read more

Well hello there you lovely people, I hope everything is going well! We’re happy to share that Ionic 4.4.0 (Beryllium) is available today 🎉. This release includes some new features, so let’s dive right in.

Given that this is a minor release, we’ve added some highly requested features from the community. These features were all pull requests from the community, so thank you to the following people on Github:

adamlacombe, jlbeard84, JustDoItSascha, paulstelzer, shreeshbhat, vhinic

With that, let’s dive into some of these new features.

Cards as Buttons

Cards are the go-to piece of UI when you need to show a lot of information, but also make it visually appealing to users. With this in mind, card has been updated to accept a button attribute which will apply the appropriate styles for both iOS and Android. On iOS, the card will now scale when activated (similar to the iOS App Store UI) and Android will get a ripple effect.

Open Method on Sliding Items

Sliding items are a great component when you want to have a lot of actions on an item, without overloading the item itself. Sometimes though, it may not be clear that an item could have these actions, and your users are left wondering what to do. Well, now developers can programmatically open a sliding item to reveal the item options!

Refined control over Pull-to-refresh

Pull to refresh is used quite a bit in apps, especially when wanting to load more data on user interaction. Some users have said that the pulling action happens too quickly and that it was hard to notice that the gestured had even been triggered. Well not anymore with the pullFactor property. The pullFactor allows devs to customize the speed of the pull in alignment with the drag of the content in order to trigger the refresh. This is better seen in an example:

Here, when the pullFactor property is 0.2, it requires dragging the content further to cause the refresh action to happen. Meaning no more accidentally triggering a refresh and potentially losing your scroll position.

There’s plenty more bug fixes and enhancements in 4.4.0, so be sure to check out the full changelog for a complete list.

Cheers 🍻!

Read more

© 2020 Extly, CB - All rights reserved.