if you’re new here, Capacitor is the latest project from the team behind Ionic Framework that provides an abstraction on top of Native SDKs so you can write modern web apps and access any Native SDK through a cross-platform, portable layer. Capacitor apps work on iOS, Android, Electron, and the web as a PWA.

It’s our take on a stew with Cordova and Turbolinks and a bit of React Native for seasoning, focused on building modern web apps on mobile, what we call “Native Progressive Web Apps.”

Capacitor and Ionic Framework are a delightful pairing, with Ionic providing the cross-platform UI controls, and Capacitor providing the runtime and Native SDK access. You might even detect subtle notes of cherry and leather and cigar smoke.

In 2018, Capacitor largely flew under the radar. This was intentional. Today, most Ionic apps run Cordova, which is working well for many users. We felt no need to cause even more of a stir by forcing a whole new native layer on users, and we also knew that there would be bugs, as Capacitor, in general, wouldn’t be production ready for a bit. With Ionic 4 creating enough stress as it were, we didn’t want to add more to the mix with Capacitor.

Despite that, we were excited to see an increased interest in Capacitor from the Ionic community and communities outside of Ionic. Many Ionic users built apps with Capacitor and had very positive impressions of the project. I also personally received encouraging inbound interest from reporters and some dev rel folks at projects like Angular. Despite being largely an improvement on existing approaches, something about Capacitor felt new and fresh.

Above all, what got me jazzed most about Capacitor is how many folks from non-web JS projects like React Native and NativeScript were excited about Capacitor. The feedback from them was similar: “I always wanted to continue to build with web technologies on mobile, but I struggled with Cordova and the native tooling and at some point, I got fed up and was just done with it. Capacitor will bring me back.”

This feedback was critical for us, as it meant that Capacitor was following the right vision (“the web will win”), and that making some major UX improvements on how past tools like Cordova worked were paying off.

During the rest of 2018, the Capacitor team, now led by Julio Cesar with contributions from the community, added a number of key features to Capacitor. Those features included Push and Local Notification support out of the box, so apps can get notifications without worrying about installing extra plugins or adding new libraries—Plus, support for Electron, tons of bug fixes, and web implementations for key plugins.

Fast forward to November 2018, and the team at Ionic is finally coming up for air with Ionic 4 final fast approaching. We’ve been having a lot of internal conversations about our plans for open source in 2019 and where Capacitor fits in…

In 2019, Capacitor will become the official native abstraction and runtime for all Ionic apps. But in order to get there, a few things need to happen:

First, we need to ship the 1.0, production-ready release of Capacitor. We plan to do that close to the v4 final release which is slated for January.

Next, while we added Capacitor support to Ionic CLI this year, we haven’t promoted it or made a big splash about it, yet. In 2019, we are going to encourage users to try it out for new apps. That means prompts in the CLI and more promotion on the getting started guide.

Finally, Capacitor needs to be integrated into our commercial DevOps product (Ionic Pro). Developers need to be able to do builds with Capacitor and push remote updates in Capacitor apps—All that work will be ongoing in 2019.

For the project itself, a big priority for 2019 is not adding features, but instead doubling down on stability. That means investing in more unit and automated testing. We want Capacitor to be the most stable mobile platform around, and we do that by letting the community build on top of it, while we focus on creating a wonderfully stable and reliable core runtime.

Speaking of the community, we have work to do to help the community flourish and be everything that it can be. Despite the fact that we did not do a lot of community work in 2018, I am thrilled about the 1300 folks that joined our Slack and the volume of PRs and contributions we’ve had on the Capacitor Github repo. Whenever you make something new like Capacitor it’s always hard to know if it’s going to be a thing. Having seen projects like Ionic definitely become a thing, it’s thrilling to see the same early adopter passion for Capacitor that Ionic had when we started.

Beyond community development, a major priority for us is making it easy for developers to build awesome plugins and native integrations, and getting those in front of the Capacitor community. That means adding an index of existing Capacitor plugins and investing in our plugin development guides.

Even though Ionic has been working on a new project that essentially replaces Cordova, we still use Cordova heavily and continue to invest in the platform. In fact, we are planning on directly supporting Cordova for Enterprise customers for a long time to come. That means our investment in the platform will grow rather than shrink. Stay tuned for more updates on this specific support plan in 2019.

We get asked often: why couldn’t we have just improved or modified Cordova? Unfortunately, I don’t have an answer that will satisfy many people as for why we built our own thing instead. The open source space is filled with new projects that built on older projects and made tangible improvements that couldn’t have been done without radically changing the original product, which is what Capacitor would have required. We felt like we couldn’t do that with Cordova for technical and political reasons. Whether that is right or wrong that is the conclusion we came to.

On the plus side, Ionic now controls almost all of its stack. When you build an Ionic v4 app and use Capacitor, we control the native runtime layer, the UI controls, and the “framework” used to build the controls (Stencil). The only part we don’t control is the frontend framework you use on top (Angular, React, Vue, or nothing). This is significant: If there’s an issue in any part of the stack that we control, we can fix it right away. We are already seeing some wonderful returns on this investment and it’s enabling us to build a stronger Ionic and focus on what we do uniquely well.

One last thing: For our enterprise customers that are using some of our premium Cordova plugins like Identity Vault or Couchbase Lite Enterprise integration, expect those plugins to work for both Cordova and Capacitor in 2019 as we have been deliberate in building them in a cross-runtime fashion.

Well, okay, maybe a few, but we’re not necessarily forcing them to happen in 2019.

One of the big things that I want to see happen with Capacitor is easier integration with Native SDKs. The reality of the mobile market is that many services and SDK vendors are pulling back from building plugins for third-party frameworks like Cordova or React Native, and instead focusing on their native iOS and Android SDKs (while encouraging the community to build wrappers for their framework of choice). A lot of this is a reaction to the sheer number of options in the market, as it’s just not feasible for many companies to support every cross-platform solution under the sun.

We’ve been noodling on an idea we are calling Capacitor Native Views: A super simple way to wrap a Native SDK and expose it as a reusable component that can be easily consumed in JavaScript.

Some toolkits, like NativeScript, take the approach of exposing every Native SDK API to JavaScript. We think the security implications of that are undesirable, and it doesn’t remove your need to learn platform-specific APIs. We don’t think you should have to learn those APIs if you don’t want to, and we don’t think you should expose all Native APIs to JavaScript for security reasons.

Instead, Native Views provide a structure for wrapping and consuming a Native SDK so that it can be easily and safely exposed to JS and your web code, with rich TypeScript support and minimal maintenance required for the actual wrapper.

This idea is still super early, so don’t expect this to land in 2019, but we mainly want to gauge interest in the concept and figure out what we need to do to make it happen at a larger scale.

Beyond that, we want to make it easy for Capacitor to embed into existing native projects, something we’ve already started to see. In fact, we’ve had several requests for embedding Capacitor into a React Native shell so you can build most of your app with Ionic + Web Technology, and wrap it with some React Native calls. That was something we didn’t anticipate, but is really exciting because it further proves to us that developers can get huge productivity gains by building 90%+ of their app with web technology. Expect to see embed work happen in 2019.

We’re heads down and focused on getting some big releases out at Ionic for the end of the year, Capacitor included. We’re more excited than ever about the opportunity to make building mobile apps even easier than before, all by focusing on the most widely used and known technology stack in the world: The web.

Stay tuned for a big 1.0 update from us on Capacitor soon, and until then we hope to see you around the repo!

Interested in getting started with Capacitor? Check out our announcement webinar: