Don’t take me wrong, I am not a supporter of this and I never had a word in this. I think that mobile OSes are the opposite of security, when I heard the first launch of the apple pay and google pay, bringing guarantees of local device storage security, it is still a joke nowadays.
I just said a place where native functionality comes in handy, nothing more nothing less, if you were to look at the banking api I work with, you would put your hands on the head…
This project is far from completion on mobile, at least on android, there are some important things that need to be addressed that still are in the air in that project, shortly said that project is far from production applications.
For me I was thinking of going mobile app approach for a smoother experience than on browser and also that since it’s B2C I’m pretty sure people would want downloadable apps rather than for advertising.
You seem to have a lot of experience regarding mobile dev, at least much more than me which tends to 0
Can I ask for advice? Im building productivity apps on the web and was planning on making PWAs which is almost free as I just need to make it work a minimum offline with service workers.
If PWA are suboptimal compared to native apps on the store, why are PWAs still relevant and popular?
Most importantly: what is the best way for me to offer the PWA to my customers? How to distribute them?
You confused me when I read that you are fan of PWA but on the other hand you say they are not even that worth to be distributed through the Google store, because they are just wrapped web apps.
Overall, it’s not clear your stance regarding PWAs and for which apps/audience those are acceptable, and how to distribute them.
Ty for any advice!
I don’t see them as popular at all, I see them as niche, a really very focus niche. In the web world they may be popular or not, it all depends on the bubble you are in. Due to work I am in the mobile bubble, and here native apps are kind of the kings, despite cross-native platforms keep trying to overthrow them from the ranking.
First, know your customer. Is it a an heavy mobile user? Are they from the younger generations?
If yes, then they may dislike to download an app from the mobile app store to realise that it’s not native, it lacks all the gestures and behaviours they are used in a native mobile app, thus they may uninstall it immediately, and you loose a customer, and/or you get bad reviews on the store.
The only way to put a PWA in the store is to wrap it in a webview. I don’t know other way, but I am not a mobile developer, just work on the security side.
When a user visits a web app in a mobile browser and the browser detetects the manifes.json file it may prompt the user to add the PWA to the home screen after the algorithm decides the user as interest on the PWA app. Another alternative is for you to detect the user is on mobile and show a popup with a button to add it to the home screen (not sure if his possible). The browser also as an option in the top menu to add the PWA to the home screen.
I didn’t say that they aren’t worth to distribute, I just say they are wrapped in web views and that may fireback against you. For example, you can buy fake iPhones, that are hard to distinguish by just looking to them, but easy once you get your hands on it, how would you feel by buying a fake one when what you wanted was a really iPhone? That feeling may be the one your mobile users will experience when they install an app from the store that turns out to not be a mobile app, just a website wrapped in a webview.
It depends on your use case and resources.
Most important, if you are competing with others that have a native mobile app then you may already be in the loosing side from day one.
I think what ends up always is someone who is either familiar with PWA or native, implements the first prototype, then at some point that prototype is running in production and of course nobody in their sane mind will rewrite the application from the ground up in another technology from scratch.
One of the options you may want to explore for your use case is Nativescript. This framework officially supports Svelte - noting that you’ve done a previous iteration in Svelte. My understanding is that Nativescript is different as it does not use web views like Ionic but compiles to native. So, theoretically, with a single Javascript (or Typescript) codebase you can have an app for IOS and Android with their respective ‘touch and feel’ and distribute them on Google and Apple just like normal apps.
Not to the point of launching a product. I did go through a couple of the video courses by Alex Ziskind too and the whole concept was interesting. Whether it is ready for prime time I’m not sure. I will say that when I was considering your issue for my personal project, I came to the conclusion that it is probably better to start with a simple mobile responsive web app and that is the route I’ve gone down. When I looked at the data around apps and new app downloads by users - it wasn’t particularly encouraging and I decided the former approach to get a MVP done was much quicker and simpler.
The biggest downside to these technologies is the fact that it can add a lot of complexity once something goes wrong. For example on android, some small things like how your UI container resizes when you open keyboard has changed on newer versions compared to old ones, and if you implement it incorrectly, it will not show correctly on older devices.
Since such frameworks abstract this level, you will either need to be sure that the maintainers implemented this correctly, or do it yourself, witch includes you writing code in android/js at the same time.