Capacitor: Universal Web Applications(capacitor.ionicframework.com)
capacitor.ionicframework.com
Capacitor: Universal Web Applications
https://capacitor.ionicframework.com
51 comments
Why not just PWAs? I think the browser has come a long way, and a great number of things can now be accomplished in the browser without any additional frameworks. We built Bx (https://usebx.com) without any frameworks and it feels much like a native app on a phone or tablet when added to the home screen.
I think there's a lot of instances you need more than is currently exposed for PWAs, especially on iOS. Push notifications is a big one. And the home screen installation on iOS (even with 11.3) leaves a lot to be desired compared to Android.
P.S. Bx looks pretty awesome :)
P.S. Bx looks pretty awesome :)
You're right, but I see it coming soon. Service workers have just appeared in Safari, so I can expect push notifs to be there soon as well.
Also, thanks! You should check Bx in a month when we roll out the next major release which (we think) makes it even better :)
Also, thanks! You should check Bx in a month when we roll out the next major release which (we think) makes it even better :)
>And the home screen installation on iOS (even with 11.3) leaves a lot to be desired compared to Android.
Can you elaborate on this? I recently added a web site to the home screen of an iPhone 6 and a Galaxy S7 and they look the same to me. Is there additional functionality in the Android home page icon of which I'm unaware? (Not an Android expert by any stretch of the imagination.)
Can you elaborate on this? I recently added a web site to the home screen of an iPhone 6 and a Galaxy S7 and they look the same to me. Is there additional functionality in the Android home page icon of which I'm unaware? (Not an Android expert by any stretch of the imagination.)
As soon as you like to access any sensors on the device, the PWA sadly isnt an option anymore.
It depends on the sensors you need access to. An iOS PWA has access to Geolocation, Magnetometer, Accelerometer, Gyroscope, Camera, Audio, Apple Pay, etc.
Also bluetooth on Chrome.
Assuming the audio happens after user interaction within what iOS consiters "one event" and/or the camera is used within a safari tab and NOT "added to home screen" (once you do that getUserMedia does not work any more).
Until iOS gets their shit together and makes it so that adding a glorified bookmark doesn't remove features, it's not a real viable option.
Until iOS gets their shit together and makes it so that adding a glorified bookmark doesn't remove features, it's not a real viable option.
That may be, but I tend to see soo many apps now days that just need basic rendering. I almost wish there was a revolution to go back to when the IOS app store just installed links to URLs. It's so terrible inside phonegap apps such that apps simply can't save my f-ing password! Instead of building out more mobile features to complete the progress made by HTML5 we keep going back to native apps for no reason. Yes I get that there is a certain class of apps that MUST be native, but I would argue the bulk of apps don't need this.
Yes, but half the apps just need to maintain state without logging in.
You're not wrong, but I see this becoming a smaller issue as time progresses. Browsers are adding features all the time and I can see this one being resolved soon as lots of devs are asking for it!
PWAs are awesome, but we don’t see it as either or. If your app needs access to proprietary native SDKs then you need a native app. Capacitor gives you optionality to do both with the same code.
Instead of this madness device manufacturers could work together with HTML5 cons... to make a set of APIs that access native things, and for not-so-standardized features they could use prefixes kinda like we did in CSS. The websites accessing these HTML5 APIs would simply check for their existence first, then start using them. Usage of the APIs would then kick of device specific permission prompts, etc... Think about the integrations too, we would no longer have to set up application forwarding URLs like twitter:// to route to our app, everything would work from any device!
Even if manufacturers don't work together, if they at least provided JS API access built into their native browsers - then we can build shims on top of them.
Even if manufacturers don't work together, if they at least provided JS API access built into their native browsers - then we can build shims on top of them.
I don't think we need manufacturers to cooperate as much as we need the major browser developers to cooperate! Prefixes are not great either - it sets you up for incompatibilities later on. The point is we want collaboration across Google/Apple etc to create one truly cross-platform platform with a standardised API. For all its shortcomings, the browser IS slowly moving towards that goal.
I think that's a fair point. I had a more detailed look at your proposed deliverables, and it all looks pretty cool. Wish you all the best with the launch :)
I fully support PWAs, but it's not just a matter of doing what's practical, it's also a matter of user expectations. It's become standard business strategy that you need an app store presence whether or not it's an effective way to deliver functionality. Plenty of users (iPhone users in particular) just expect it.
We built a PWA with vanilla javascript that does a lot of augmented reality work with the camera. The main issue is the lack of iOS support. Apple recently updated iOS to include support for the service worker (literally like this week) but it still lacks a huge number of features that chrome on Android has and basically every desktop browser has.
You do get access to a lot of the core sensors on the device but the inconsistencies on iOS just really make life a lot harder. Hopefully this will change over the next year but I'm not sure how quickly it will happen. So basically yes, you should build PWAs but until apple gets completely on board you can't really leverage them to their full extent like you can with chrome on android.
You do get access to a lot of the core sensors on the device but the inconsistencies on iOS just really make life a lot harder. Hopefully this will change over the next year but I'm not sure how quickly it will happen. So basically yes, you should build PWAs but until apple gets completely on board you can't really leverage them to their full extent like you can with chrome on android.
ios supports PWAs (service workers) now doesn't it?
Yes, just released in 11.3
Yeah they added it in the most recent version of iOS (11.3) but progressive web apps have a very loose definition the most basic of which is, as you correctly stated, using a service worker. However service workers are just the ground floor of a much bigger building of features that should be able to be leveraged cross browsers.
Android webviews is a total turtle (even with hacks and crosswalk).
Early 2018?
Link should probably be updated to something which has some information:
https://capacitor.ionicframework.com/docs/
https://capacitor.ionicframework.com/docs/
Technically it's here already (in alpha), just haven't updated the landing page.
I stumbled upon https://blog.ionicframework.com/announcing-capacitor-1-0-0-a... last week, much more info there.
I had an early look and wrote a bit about it as well:
Introduction article that touches on all the relevant bits at https://ionic.zone/capacitor/overview and an Overview of the CLI at https://ionic.zone/capacitor/cli
Is this a competitor to React Native? RN seems to be the ideal: truly native components but a JS programming model.
We’re focused on pure web applications, and being able to run an app in the App Store and on the web as a PWA and Electron with the same code is a problem our users and customers are asking us to solve. It’s a different approach and I think those that want to stay web-native but still have easy access to native SDKs will find Capacitor interesting.
We’ve had some good feedback from some react native developers that they’d love to build out pages with web content and wrap it with a native shell (nav/menu/etc), while easily exposing native modules/plugins to the webview, so that’s a use case we’re going to support. Being able to use that app as a PWA is a compelling value prop of this project as well.
We’ve had some good feedback from some react native developers that they’d love to build out pages with web content and wrap it with a native shell (nav/menu/etc), while easily exposing native modules/plugins to the webview, so that’s a use case we’re going to support. Being able to use that app as a PWA is a compelling value prop of this project as well.
Gotcha. Thanks for the clarification.
My concern is that too often, embedded web apps still never feel right. It's that uncanny valley. I'm sure it's better than its ever been, but do you have thoughts on bridging that uncanny valley? (through maybe some CSS animation libraries that mimic the native controls?)
My concern is that too often, embedded web apps still never feel right. It's that uncanny valley. I'm sure it's better than its ever been, but do you have thoughts on bridging that uncanny valley? (through maybe some CSS animation libraries that mimic the native controls?)
We'd like to think Ionic does this well, but also I think people would be surprised how many successful, popular apps actually utilize native shell wrapped web views!
Got some examples? (not trying to be a devil's advocate, but I suspect my view on this is a bit outdated!).
> RN seems to be the ideal: truly native components but a JS programming model.
I'm not sure i would call React Native "ideal". I think it's "progress" though.
I'm not sure i would call React Native "ideal". I think it's "progress" though.
There are actually several. NativeScript supports Angular, vanillajs, and recently VueJS. There is also a bridge to use VueJS inside of reactnative itself. There are many other libraries that claim to be "native" but are actually only "native look and feel" (meaning HTML+CSS+Cordova/Phonegap, not native components).
Capacitor creator/Ionic co-founder here. Didn’t expect to see this on the front page! Disclaimer: it’s still alpha.
We’re building Capacitor based on feedback from the Ionic community to improve our ability to move across platforms such as App Store/web/electron, make it easier to interact with Native SDKs, mix web and native UI, and manage native app projects/tooling.
One feature I'm really excited about is having Web UI implementations of many Native experiences when running on the web/electron. Here's an example of how the `Camera` plugin looks when running in the web: https://twitter.com/maxlynch/status/961749127657910272. This uses our new Ionic Web Components so you can easily use these controls with low overhead even if you aren't using Ionic.
We hope Capacitor will be useful to other web developers that want to build mobile and desktop web apps, even if they aren’t using Ionic, and we’re building support for hitting the hybrid sweet spot of native UI shell (nav/menus) with web content.
Capacitor will eventually be replacing Cordova in Ionic’s toolchain so it’s going to be a core part of the experience.
We’re building Capacitor based on feedback from the Ionic community to improve our ability to move across platforms such as App Store/web/electron, make it easier to interact with Native SDKs, mix web and native UI, and manage native app projects/tooling.
One feature I'm really excited about is having Web UI implementations of many Native experiences when running on the web/electron. Here's an example of how the `Camera` plugin looks when running in the web: https://twitter.com/maxlynch/status/961749127657910272. This uses our new Ionic Web Components so you can easily use these controls with low overhead even if you aren't using Ionic.
We hope Capacitor will be useful to other web developers that want to build mobile and desktop web apps, even if they aren’t using Ionic, and we’re building support for hitting the hybrid sweet spot of native UI shell (nav/menus) with web content.
Capacitor will eventually be replacing Cordova in Ionic’s toolchain so it’s going to be a core part of the experience.
Why not add changes to Cordova instead of making a replacement?
Capacitor is not Cordova plus a bit of stuff, but a total reimagining how such a tool should work. Cordova for example is defined by dynamic platforms you can add or remove, or that builds are (or can be) done with the CLI. Capacitor has none of that.
Can you point me in the direction of any documentation you might have on how a project should be handled with regards to source control? Currently my team doesn't commit the generated platforms/plugins folders but it appears that with Capacitor we might need to start committing some/all of these since it isn't expect to re-generate them from a config.xml like it was with cordova.
You commit it all (except what .gitignore already ignores or your IDE adds), the native projects are are not build but source artifacts here. Benefit: Once the project is created, you can modify and adapt it in any way you want and have those changes versioned like all other code changes.
That is awesome news! Rebuilding the native projects on a CI server was always a huge PITA with gross hacks to make certain things work.
Glad to see they're moving beyond Cordova's main issue: trying to fully automate the native build processes with disastrous results.
I am perfectly happy opening up Xcode to build and configure. Same with Android Studio. Trying to find a "Cordova solution" to very common build tasks was a continual nightmare for me.
I ended up just switching to React Native to wrap a progressive web app. It makes no sense since I'm only using a single React component (UIWebView), but the build / deploy process was just so much easier to manage than the mess of Cordova scripts and outdated/broken plugins.
I am perfectly happy opening up Xcode to build and configure. Same with Android Studio. Trying to find a "Cordova solution" to very common build tasks was a continual nightmare for me.
I ended up just switching to React Native to wrap a progressive web app. It makes no sense since I'm only using a single React component (UIWebView), but the build / deploy process was just so much easier to manage than the mess of Cordova scripts and outdated/broken plugins.
You're hitting on something we hear a lot, and that's a use case we are really going after. Even if you use RN today with a webview, there's no core way to expose plugins/modules to that web view (like Cordova does). I think there's a middle ground here where the web layer is first class but it's easier to drop into native code and manage your native project as you wish, while staying as close as possible to the standard tools/APIs that each platform developers typically use. If we can save you 95% of the time on your app, and have simple escape hatches to get full control, that's a win.
Love to see this happen, but how's the performance (responsiveness, memory consumptions) compared to native? I believe the main reason people are reluctant to develop web-based apps is performance, which results in poor user experience.
Any benchmarks/testings to show the performance is on par?
Any benchmarks/testings to show the performance is on par?
We're not building Capacitor in a vacuum, it's targeted at the existing and large community of Ionic developers that are already successfully building these web-based mobile apps today. If you need the highest performance option for your app and don't care about PWAs or Electron compatibility, you should just build a pure native app and get as close to the metal as possible.
I see this is from the ionic people - What are the goals for this vs ionic? Is this supposed to eventually replace it? Will it still be pushing Angular on us, or is it possible to use any JS framework?
This is not a replacement for Ionic! Ionic provides a cross-platform UI layer for mobile web apps. Capacitor is a replacement for Cordova which manages the native SDK interaction and native app project management/tooling side of your app.
Once we integrate it into the Ionic CLI, you won't really have to think about which part is Ionic UI and which part is Capacitor.
Once we integrate it into the Ionic CLI, you won't really have to think about which part is Ionic UI and which part is Capacitor.
With this in mind do you plan on offering a path for migration from existing Cordova apps?
Once all your plugins are supported in one way or another (Capacitor plugin or compat for Cordova plugin) you should just be able to install Capacitor in your project and see if it all works. Required code modifications in your app should be limited to the interaction with native.
I hope this works out, and I hope it fixes some of the grief that Cordova causes. We've ended up with some legacy apps built with Ionic, and have had so many problems that trace directly back to Cordova that we're looking very seriously at complete rewrites.
Integrating with some third-party like Auth0 goes smoothly for our projects until we get to Cordova, at which point we start chasing absurd bugs and explaining to their support that we do actually need Cordova support. We've been told more than once that Cordova is the "problem child" in terms of supported platforms.
Integrating with some third-party like Auth0 goes smoothly for our projects until we get to Cordova, at which point we start chasing absurd bugs and explaining to their support that we do actually need Cordova support. We've been told more than once that Cordova is the "problem child" in terms of supported platforms.
Agreed that we need to fix that and also make it easier for people to build/maintain plugins. A hard problem across the cross-platform mobile space that I hope we can help with.
Please, if possible, make it truly easy to integrate.
All of the others tools requiere multi-steps to integrate into android/ios projects. Even if "generating a already integrate project" is available, the ideal is just import with gradle or carthage/coccoapods and that is all.
All of the others tools requiere multi-steps to integrate into android/ios projects. Even if "generating a already integrate project" is available, the ideal is just import with gradle or carthage/coccoapods and that is all.