Use react native with some way to share code between JS runtime and backend.
Because personally I think JS and TS are solid as shredded salad I did some research on typed languages that compile to JS but provide strong guarantees of error free code.
I looked at Haskell + Purescript, Ocaml + Reason/Rescript but in the end I decided to give Gleam a go. It is less obscure than Haskell and in better community shape then Reason/Rescript. Aaand I could share gleam code with an elixir backend.
I only started, and now have a react native app with main engine written in gleam and compiled to JS. The views are written in JSX and have minimum logic (I try to put it in custom hooks)
I hope to post a longer write up on how it’s going, so far I have hit two issues:
gleam allows only lowercase function names and stupid react rules require hook names to follow useSomeHoook convention. A workaround is to ‘export {use_foo as useFoo} from …’
gleam list is hard to use on JS side; requires converting. Array is not a first class citizen on gleam side- not sure yet how to deal with this and which types should be used in gleam app engine interface.
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.
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.
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.
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.
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.
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…
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.
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.
Wow nice to know! Then it seems this is out of their control, if they decline there will be war. I like that it does solve huge headaches that things like play store have when having to update the application, I was thinking for some time now to develop a self-updater for native android apps, because having to deal with the versioning system of google play is just a general waste of time.
The main point of a PWA is to bypass the gate keeping of the app store. Wrapping an PWA in a Webview then publish in the app store seems like the worse of both worlds to me: Not native enough and draconian gate keeping.
Apologies for tangential question, but what are people developing native apps for? I’ve managed to avoid them for my entire career and also don’t use many apps beyond what came with my phone. Like, are random smallish ecomm stores still making native versions of their sites or has that generally died down? I’m just curious, mostly because I’m still hoping to avoid it.
I am currently working on a native android application for a bank.
Here is a pretty big difference between a web application and native one, we are talking about native pin encryption of all sensitive data, location fraud detection on all transactions and more things. Of course the interface is simple and could be accomplished by web.
I work as a Developer Advocate for Mobile App Security and Mobile API Security and I see often that businesses and devs believe that because a mobile app is shipped in a binary is more secure and sensitive data on it its safe, but that is far from the truth. Not saying that is your case, but I like to highlight this each time I see the opportunity.
Now, let’s not discuss it in this topic, but I am happy to discuss it in another topic
Ah yes, I do have my bank’s app on my phone and happy to have it in an app. I was wondering more about the general idea of everything having to have an app version since reading rebuttles of LiveView/HTMx/etc on HN would lead me to believe that the vast majority of devs are concerned about having a native version of their app which feels a little overblown to me.
Sorry, though, I shouldn’t have derailed the main thread.
Monetizing. You don’t need to write a single line of code with questionable intent; all you need to do is to include the library provided by the big Ad networks.
Ha, that I was aware of. I once worked with a guy who had some pretty useless apps back in the day that would just do some stupid crap like tell you a quote every day along with an ad.
