[wilg]

It's honestly just sad how complicated the engineering is to make a modern CRUD app that works on the various platforms users expect and behaves normally. It doesn't seem tenable long-term to have to build your app three or four times, or use weird glue projects like this. This seems like a decent solution, to be sure, but still.

[mleonhard]

I built a thing that makes it much simpler to make apps: https://www.applin.dev

You make a web server that returns JSON defining your UI. Then you make a native iOS app by copy/pasting the provided Main.swift file and adding the URL of your server. The app uses an iOS client library, fetches the JSON page definition, and builds/updates the page with native widgets. I'm planning to eventually build Android, web, and desktop clients.

[wingerlang]

What sort of customers does this bring in? Looks very interesting, are there any public apps made with this or is it more of a internal-data-entry type of people who use it?

[mleonhard]

Applin is a brand new product. I plan to use it to build and finally launch https://www.cozydate.com/ .

[gjsman-1000]

Right now I'm building a web app, but I'm at the point where when it comes to phones, it's either fully native apps - or nothing. I take some relief knowing that only the "R" and a subset of "U" really needs to be in the app to satisfy almost everyone but staff in my case.

[holoduke]

We migrated all our native apps to webapps. No fancy 3d apps. But mostly news apps. Lists, detail screens. Our approach shows no decrease in performance. But development becomes 10 times easier. Its a pita to work with iOS, but specially Android SDK is such a crap framework. You still need a bit of native code. But at least all the UI related stuff can be created with css.

[travisgriggs]

I developed and maintain two apps, both in native versions. We do quite a bit of custom graphics, prefer animation, lots of BLE (we push it in interesting ways, both characteristic counts and throughput) as well as have a mapping component that includes custom overlays which are user editable through direct drawing/dragging on top of the map. Oh, and some on device persistence, basic http fetching, and mqtt as well.

I agree with the sentiment that Android is just such a years long train wreck. I am currently rewriting one of the Android apps in 100% (as much as possible) "modern" and @Compose Android. So far... it seems better. But maybe the newness will eventually wear off. Some will the credit the "paradigm", but UIKit demonstrated to me that you could be a solidish "OO" ADK. I attribute @Compose to just being better engineered as a quasi functional approach than Android original stuff ever was as a Java implementation.

I am so worn out with the overall approach though. It is a ton of duplicate work. But I despair that the alternative would be no better? It seems that while today, I duplicate a lot of work, I get to choose how complex and coupled the various layers are. I do my best to just use stock stuff and not mash a bunch of stuff in. With a "web tech" solution, it seems the duplicity just rotates, so that the duplicity is just replaced by the complexity of trying to coordinate lots of disparate technologies, having to grow versed in even more domains, so that intelligent assesments can be made when things don't work as expected, and in which bucket/layer to focus ones efforts for each feature.

All that said, would you still encourage me to do as as you've done? I am honestly open.

[chris24680]

A nice benefit to the Turbo/Strada approach is that you can progressively enhance the apps over time. So you can start off with full functionality facilitated by the web app and overtime if it makes sense for the app you implement particular screens fully natively.