👋 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.

So…2018…Amiright?

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…

2019

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.

What about Cordova?

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.

So, no new features?

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.

Until next time…

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:

Signup for the Ionic Newsletter to get the latest news and updates!

  • RhysC

    Great work everyone Capacitor is truly an awesome project. Are there any docs/tutorials for push notifications with Capacitor?, im keen to ditch Cordova asap.

  • http://janpiotrowski.de/ Jan Piotrowski

    Time to dust off https://ionic.zone/capacitor then and publish a few new articles I guess.

    I shoud probably also check if my introduction at https://ionic.zone/capacitor/overview and the Capacitor CLI tutorial at https://ionic.zone/capacitor/cli is still fully valid. You and all your changes all the time… 🙂

  • http://lifestylebusinesstransformation.com/ Simon Grimm

    Looking forward to the v4 final release and the next steps you take with Capacitor! Knowing Ionic for some time now, I’m sure 2019 will be just as amazing and interesting for all Devs like 2018 was.

    You never fail to have “One more thing” in the end 🙂

  • https://troydcthompson.com Troy DC Thompson

    Really excited about the future of the web and the official v4 release in January! Working with capacitor has been a nice change of scenery. Keep up the great work!!

  • FssRepository

    I think, the capacitor is a big and quick win. When i replaced the ionic framework to my own one, as i needed something totally different and more integrated with the back-end, i was thinking to recreate cordova. (i think cordova has many problems) and i feel personally that within a week i have recreated many of the buggy plugins with capacitor and fixed the issues easily, that ionic should force enterprise users to convert plugins to capacitor and make it available.

    It’s simply very easy to create anything in capacitor. It’s just so lightweight, and more maintainable as it’s not making another complexity for the pure swift or android developers.

    The main support is, that cordova is failing on swift, and i haven’t seen a working plugin, because of its messy xml based configuration.

    Even the webview is available on plugin level, and can be extended. (back button override for example)

    I’m not satisfied of the work being done on ionic. I think the capacitor will be the only project which really remains. Sooner or later the stencil will be replaced by framework implementations. (angular elements etc.) At the moment it’s in very early beta. It’s trying to solve complex problem, and many browsers still not support. So majority of the people might wait, and at that point angular-elements will be easier to use, and can be more trusted in nature.

    • http://twitter.com/maxlynch Max, Ionic CEO

      I appreciate that you like Capacitor, but I don’t agree with a lot of what you have to say here, especially about Stencil and Ionic components.

      • FssRepository

        I have wasted almost 8 month on ionic, when i realized i can do it far better, and easier with less boilerplate.

        I know ionic and many even native components in code level, and i have picked up some of the idea. Spent almost a year now full time (10-15 hours a day) – and i have 15 years of experience worldwide and java / c++ / web anything.

        I have tons of experiences with v3, how to not code, and i realized that v4 didn’t add anything more to it, just convert (you have a team, i’m alone and making stored procedures, native plugins and backend work – when i have started there was a promise that v4 will be shipped, now it seems my framework will be finished sooner). Think of it in a different prospective. What would you do if you start a project from angular v7, and not where angular v2 was in beta, and there were no real options. (even angular-cli was a mess, and every time after upgrade i had to make workarounds and shadow the original functionality)

        I didn’t like also that for some image i needed to go to the ionic server, while building.

        The tab and the virtual scroll just killed me really.

        1) Virtual scroll:
        Many problems like lazy load images / orientation change, and the virtual elements is not always in the center aligned vertically, so white gaps can happen to scroll down and scroll up immediately)

        So there are more tricks here, to show somehow the border of the real items until it’s not rendered there. Variable heights also a missing part. I have added panel selection also. i have seen some robust ng-select which was nice.

        I have made some json structure which will be passed to my own virtual scroll implementation. like menu (frame / css grid etc.) There is a benefit, that i can load even from the back-end.

        Stabilized the scrolling even if the orientation has been changed.

        There are additional problems, if you scroll back, the initial max. height is disappearing, so if you have some anchoring thing, you cannot scroll back easily.

        You cannot just make scrollTo easily.

        Naturally there are other things, only that component took me 1-2 month, as the browsers behaving very differently. I grabbed back some html 5 standards.

        When you have wider screen than more panels can go the same row. So the virtual scroll just being slipped away.

        2) Tab:
        Tab was not that responsive, and i realized that, i had to to 2 level of lazy load, and z-Index even instead of display manipulation, as when you close the tab, angular trying to destroy all the components, which meant the buttons was the big issue, even if i have set to 10 virtual items.

        display:none what the ionic does simply made my program a crap on mobile.

        Tab included the buttons, which is the used scenario, but what if we are thinking about a responsive tab, which can appear in a different ways on the same data set. (can be a menu or anything else), what if we are extracting the buttons as a whole from the tab.

        The styling of the tab button was a nightmare. To send tab event outside the tab also was horrific, i just hacked the tab to make it possible.

        —————————————————————————–
        Ionic has got so many bloatware, that i ended up at 3MB, and guys told me that it’s ok for a simple responsive webpage.

        I really realized that ionic didn’t really add up anything, what you cannot do with a little bit of skills in pure html / css, if you don’t count the tab / virtual scroll, which was a nightmare.

        My biggest problem was the two knob slider, but i have seen some lines of polyfill to do that. My knob system are very flexible, and can be used as a menu, can drag menu item from the menu, put into a div, or to an another line.

        I also ended up with the idea, that in my country many developers has been left, and i need to do my project alone. So i had to solve issues in the backend, not to make converters for everything. So i have abstracted the business logic, reduced the converters by 95%.

        So the interfaces are more business oriented even if they can be used alone, than just an interface.

        I’m not just criticizing ionic, there are some part of the angular which is unnatural and little bit messy.

        I think the two biggest problem was, one what the capacitor is for, to reduce the messy non-maintained buggy cordova plugins, which is solved partially.
        Second, javascript frameworks at the moment has been written in a way that it’s very hard to integrate with backend. So it’s more time-wasting, then productive.

        Maybe i’m wrong, and my project is far beyond the limit, what a person can actually do alone, but my gut feeling to create the same webpage 10 years before was less time-wasting than with angular or react, which is kept changing.

        Can you imagine that the initial facebook MVP has been done in two weeks?
        Can you imagine that i can do the same in two weeks time know?

        Javascript frameworks hardly took away the heavy load, what you need to focus on. Yes you can use with any backend, but the serious jobs are not relying on some fancy UI. The serious job is relying when you would like to connect the backend with the UI, and saw the performance issues, the interface rigidity and so on.

        Stencil is a different kind of project, i just do think when it’s released there will be other projects as well with similar qualities, at least Google might look at it as an example and grab the idea to make the angular elements better. Stencil also is trying to solve a hard problem, because relies on something which can be changed drastically. On Swift and Android there is backward compatibility at least.

        I have to say angular material is worse then ionic by far (to make custom css angular attributes is the worst thing, what you can make in angular), but ionic is very-very far from perfect.

        Ionic also got some elements, what browser does, safari is a little bit behind on input elements (unlike iphone), but anyway i like to use the native date picker and so on, which is one line of html code.

        Last word, there is also an expectation, when users are going back to the same screen, even if they have been connected, the screen should look exactly how it has been left. So look at it as a work-space.

        I’m not sure when i can really achieve it with ionic, yes service workers are there, but it’s not solving the issue entirely.

        • Purple Edge

          I look forward to seeing your project on github 😉

          • FssRepository

            I have planned to make it available for free, but nobody really joined and the initial idea has been developed drastically, that it will be closed source. (i’m not a framework maker, i just would have liked to create an android app, just made my work because of anger that i have wasted so many time on other’s not well-maintained jobs)

            Unfortunately 95% of my angular project is reusable UI and json data, so my project can be easily replicated. However there is something else in my mind. No offence if i’m not working in a project 2 years full time with some gaps, and nobody really helps on it, github does not make any sense.

            I have shared several ideas, and very likely will be done next year. If it’s a private work and goes to my project why on earth to help the competitors. If it would be a group work, it would be totally different.

            On github most of the people look on you as a bug fix machine.

            Ionic has income from elsewhere i haven’t yet.

  • Charles EDOU NZE

    So excited thinking about all of the things we’ll do with these new features !!

  • demetrio812

    I was looking forward to testing the final release, but frankly after the unfounded native api security argument (come on guys) and the fact that I’ve seen some comment deleted I’m rethinking it, I really like the NativeScript community and fair approach with the other frameworks

    • http://twitter.com/maxlynch Max, Ionic CEO

      NativeScript takes a fair approach to other frameworks? Are you serious? That must be why they invested in building an entire site dedicated to promoting FUD about Ionic 🙃

      The deleted comment, if I know what you’re referring to, was deleted by the author.

      • demetrio812

        I didn’t have the impression, not in the official blog for sure, here some link about React and Ionic/Cordova:

        https://www.nativescript.org/faq/is-nativescript-kind-of-like-react-native
        https://www.nativescript.org/faq/can-i-use-cordova-plugins-in-nativescript
        https://www.nativescript.org/blog/the-road-from-hybrid-back-to-native-is-a-sweet-one

        I don’t see any FUD or clearly false claims (I may have missed something, but I would have espected some links from you in support of your claims – again). Same thing in the Slack channels and (old) forum.

        On the contrary, as a native iOS and Android developer, I think that saying that “exposing every Native SDK API to JavaScript is a security issue” is sort of promoting FUD about native frameworks too (LOL) If you have an argument I would have liked some more explanation to such a bold statement.
        As a Nativescript developer, is has been so helpful having access to native API to add some quick native code without having to wait for the plugin developer to support that specific call I really needed. And you will always have to deal with plugin problems, so with native code, so better to have it always available rather than having to build a plugin for everything. This is my experience, obviosuly I come from a full stack background (I also use Java/Kotlin with Spring for the back-end), so other may have different opinion, but it doesn’t justify saying that if you develop a native app in Swift there are security issues because you have access to all the native API.

        Cheers,
        Dem

        • http://twitter.com/maxlynch Max, Ionic CEO

          That’s not the site I was referring to (rather, it’s a separate domain and SEO play), and I’m not going to link to it here out of principle.

          re: security, imagine importing some malicious 3rd party code, such as an errant npm module (event-stream, anyone?) that now as full access to every native API and can easily perform filesystem operations, access HealthKit data, basically do anything your app is allowed to do.

          Sure, Cordova isn’t free of security challenges like this, but arguably the attack surface area is much smaller given that plugins have explicitly-defined APIs (Cordova and React Native have very similar plugin models so they both apply here). At a high level, we’d rather limit the surface area of a Plugin to JS than expose the whole Native runtime underneath.

          • demetrio812

            But you are writing you the official blog, it’s quite different in terms of exposure.

            About the example, you know better than me that in order to access HealthKit data you will also need to change the entitlements and the info.plist, plus you will need to request the access authorization to the user.

            Again, your argument in my opinion is not that strong because it could be applied to native apps as well, moreover the malicious module should have been built specifically for Nativescript, so nothing stop the development of a malicious module to attack another framework, and a plugin can import malicious code as well.

            IMHO, you are limiting the developer because of something that can happen everywhere, and frankly it’s not even THAT common I’d say.

            Cheers,
            Dem

          • http://twitter.com/maxlynch Max, Ionic CEO

            Not going to get into the past stuff the NativeScript and Progress team have done to spread FUD, you’ll just have to take my word on it.

            The Native vs JS stuff isn’t as simple as JS is more often dynamically executed and the community is built around using thousands upon thousands of small 3rd-party modules which is not really the case in native iOS or Android (at least not nearly at that scale)

          • demetrio812

            I understand what you mean with the thousands 3rd-party modules, but the dependencies in a nativescript app are more similar to a native app and more limited than a standard js project. Moreover, most of the time the plugins are mainly ts wrappers of native ios and android libraries, with the advantage that I can still “enhance” the wrapper but accessing the native object and call the native methods directly. I’m using the Angular integration of NS so there isn’t much of external libraries (that are not NS plugins) to integrate in order to get all the needed functionalities. Anyway, I really don’t see the problem and I actually I have always seen it as an advantage of NS over React/Cordova.

            Cheers,
            Dem