Using live site as an alternative on Capacitor

webuniverseio commented 2 years ago

While this is not directly what we're trying to solve - replace existing codepush support from AppCenter with another 1 to 1 service, I think it make sense to consider loading live site as an alternative. You can find more about it here https://github.com/ionic-team/capacitor/discussions/5075 & if you follow links in discussion you'll get even more context.

Those may be not be problems which you experience, but I run into following problems with "standard" way of bundling apps which requires codepush:

if you need to release a feature on older versions of the app you need to do multiple backport releases
if you have a website in addition to the app, you need to do multiple releases & in some companies that may be adding complexity
if you're using capacitor
- you'll be dealing with custom protocol issues in various 3rd party scripts
- cookies are not supported on iOS when you serve bundled files

This is why I'm thinking in a direction of using live site which removes a need for codepush completely

dylanvdmerwe commented 2 years ago

AFAIK Apple does not like this on the app stores. Wrapping a website as an app is normally frowned upon. However I would really like to be proven wrong as this is a very intriguing approach.

Also what about offline use? If there is no connectivity, then the entire app won't render.

I would love more clarity around this approach and to hear how people have used it / approached it.

webuniverseio commented 2 years ago

Offline is working, you can try app.ft.com which supports service workers as server.url. For Android it works out of the box, for iOS you need to set one config value to true & update Info.plist to include domain - https://github.com/ionic-team/capacitor/issues/4122

As for Apple, their main point is that app should not be just a wrapped website. However when you start adding native features for example from Capacitor plugins, I believe restriction no longer applies (and it should matter if it is a live webview or local server that serves initial markup). I personally worked in a company which has live webview (custom code) + native UI working together via simple javascript bridge and there were no problems with releasing it to AppStore. So I'm surprised this "Apple don't like" is being repeated in different places, but I'll be honest I don't have extensive experience with AppStore releases.

dylanvdmerwe commented 2 years ago

I'm doing some testing with setting the url to point to a website.

However it does not appear that the website is able to access plugins such as SplashScreen when on a service worker on Android. iOS still to be tested.

I have added the @capacitor\splash-screen plugin to a project. Capacitor config looks as follows:

Then in the app I call: await SplashScreen.hide();

When running the app on Android it does indeed point to the hosted website. However the site does not seem to be able to access the splash screen plugin and throws an error:

I was hoping all native plugins such as this would be accessible - could be a bit of a blocker.

Edit: See my issue raised here.

dylanvdmerwe commented 2 years ago

Unless I am doing something wrong, whenever the site is served from a service worker (cached), the plugins don't work on Android. Still to test iOS.

dylanvdmerwe commented 2 years ago

Some testing on IOS:

Can point to a server.url and it works nicely. Plugins work.
However I cannot get a service worker to run properly. This means I don't get caching for offline or update notifications.
- Add domains to WKAppBoundDomains in Info.plist
```
<key>WKAppBoundDomains</key>
<array>
<string>domain.com</string>
</array>
```
- Set limitsNavigationsToAppBoundDomains to true in capacitor.config.ts
```
ios: {
limitsNavigationsToAppBoundDomains: true
}
```

Again, perhaps I have missed something? Anyone managed to get a service worker working on iOS 14+?

Ultimately I am trying to evaluate what is possible with this method to have an alternative to codepush.

webuniverseio commented 2 years ago

@dylanvdmerwe sorry for a bit of misleading info, as you discovered a problem on Android, I didn't run into it myself as I'm not as far as you in my tests, but I wonder if a workaround can be to inject capacitor script manually, maybe something like following can work just to test the idea:

<script>
if (!window.Capacitor) {
  document.write('<script src="path-to-capacitor-script"></' + 'script>')
}
</script>

For iOS when I used app.ft.com with configuration you list above I got offline working, however what is important to note is that I first had to load app in online mode, so SW will register, then when I switched to offline and reloaded the app, I got app loading the site from cache and I could interact with it. I tested that on iOS 14.8. I just double checked that on my iPhone and it works as expected. I also checked if window.Capacitor is there on iOS and it is not, so likely same problem as with Android and hopefully same solution 🙏

dylanvdmerwe commented 2 years ago

Please see a repo here: https://github.com/happendev/TestCapacitor

The PWA site is hosted on https://testapp.happen.zone.

Android: 1) When site loaded through the Android app without a service worker, native plugins work, capacitor works. 2) When site is loaded through a service worker, native plugins and capacitor do not work. Raised an issue.

iOS: 1) When site loaded through the iOS app without a service worker, native plugins work, capacitor works. 2) I cannot get the service worker working on iOS. Can someone assist maybe I have not setup something properly? I would love to do some further testing when a SW is working on iOS.

Service workers are important to cache the files locally. Even if its not an offline app, having the files cached locally dramatically speeds up the app. Also a SW can perform the check for updates logic to reload the app if there are changes deployed.

dylanvdmerwe commented 2 years ago

Has anyone managed to get this working? I am struggling with this repo https://github.com/happendev/TestCapacitor

It would be SUCH a great option to codepush that would work for some people.

riderx commented 2 years ago

Hey guys just in case you didn't see my issue here : https://github.com/IllusionVK/ReplaceAppCenter/issues/7#issue-1175870240 i made an alternative plugin fully open source in December.

@dylanvdmerwe i see your test and it seems promising i will even try to include it in the plugin at one point. But for now Capgo do the same job on the native level, and it's fully based on Capacitor architecture so maybe better to go this way for now

IllusionVK commented 2 years ago

Hey @dylanvdmerwe I guess it depends what type of apps people need to make. For us we focus on building apps that work offline and use around 35-40 Cordova plugins to allow us to access native platform capabilities. We also have one customer who has 800,000 records downloaded offline, and has the option to download up to 3.5gb of offline maps.

So whilst i'm keen for PWAs, it unfortunately doesn't fit most of our customers needs.

But were you able to make any progress on it ? I know there has been some great strides by ionic to getting PWAs to work well and be easy for the developer, so keen to hear your experience

IllusionVK / ReplaceAppCenter

Using live site as an alternative on Capacitor #4