thojanssens1
Exadra37
The first lines says it all:
In this lab, you’ll take an existing Progressive Web App that you have deployed and wrap it in an app for distribution in Google’s Play store.
See the bold part, the PWA will be wrapped by a native app, usually this is done by wrapping any web app in a native web view.
thojanssens1
So still one’s PWA can be added in the Play store. You seemed to say if we make a PWA, then no Play store.
However I thought a PWA would have more possibilities than a non-PWA web app wrapped in native web view. I didn’t have the opportunity yet to experience with it.
Exadra37
Yes, and no.
NO
As I said a PWA on itself cannot be added to the PLAY Store, as you can’t with any web app, or if you prefer website. So, technically isn’t correct to say you can add a website, web app, PWA to the Play store, but you can work around it.
YES
What you can do is to workaround the fact that a website, web app, PWA cannot be compiled to a mobile app binary accepted by the Play store, which means you need to create a native mobile app that loads the website inside a web view (a browser inside the mobile app). Bear in mind that this approach doesn’t feel native and may disappoint users that expect a native feel. On the other side if the user adds the mobile app to its home screen that he clearly knows he is using a website, not a mobile app, despite some resemblance.
D4no0
I am not sure that uploading an application with a web view inside will cope well with google play policies. Their rhetoric behind this is that an application uploaded to play should be immutable in terms of code it has, from witch delivery of assets and especially JS that make the web application is a complete opposite to that, for example after API 28 you can no longer use any additional kind of embedded binaries after the application has been installed.
Generally speaking don’t be astonished when they will decline publishing the application.
Exadra37
Some cross native frameworks or no code/ low code frameworks allow remote code to be uploaded, thus allowing devs to update their mobile apps without releasing a new one. They seem to get away with it, no idea if they masquerade it or not to not trigger Play store and Apple store policies violations.
D4no0
I don’t think they have the capacity to check every application, most probably once the application gets more popular you get on their radar. As for what you are saying it makes perfect sense, a simple example would be to add erlang VM to an android application and then feed it compiled BEAM files.
AndyL
I’ve built a couple of MVPs using React Native > Expo > Hyperview tooling. Painful but workable. If you tuned up your Hyperview game IMO you could knock out simple apps quickly. (Hyperview/HXML can be served dynamically from a Phoenix backend). Not sure how all this works with app stores…
Hoping someday to bypass all this and use LiveView Native.
D4no0
Yeah, but isn’t this outputing native components? From what I remember react native generates native components, opposite to what rendering a webview in the app does, a concept more similar to how wxwidgets works.
AndyL
I believe Hyperview generates an installation package containing an off-the-shelf Reactive Native/Expo client and a config file with a reference to a HXML server. HXML is a hypermedia language optimized for mobile interfaces, can be served from a Phoenix backend, can be updated dynamically, is probably cached in the client for offline use.