Comment by MrDresden | Hacker News Reader

Comment by MrDresden | Hacker News Reader

Parent Full thread

I do native (Java/Kotlin) and Flutter development, for 10 and 2 years respectively. Just this year moving into the Jetpack Compose territory, and enjoying it immensly.

Regarding the question about what you should choose, well that really depends on the problem space and the end goal you have in mind.

If the application is generic, will not really leverage platform specific capabilities and will be made for both Android & iOS I'd say go for Flutter. Here I mean that specific sensors and OS capabilities will not be used, as well as sharing of code for different platforms such as TV, car and wearables.

If the application is ever going to be Android only, I'd say go for the native UI toolchain, which would be Jetpack Compose. The ramp up from 0 to 100 is quick given how much good material is out there to get started (for instance go to and use the Android/Kotlin community slack channels). This route would require you to use Kotlin.

Skip looking into the old view system. Any relevant information from that space will come in time, and the rest wont be relevant anymore.

If you want to create a code base that can be leveraged with web, then go for some of the JS frameworks.

If you do have some piece of framework in mind you want to learn, then use that.

It all depends. Just keep Voltaire's words in mind:

"..best is the enemy of the good"

edit; formatting

Thank you. Follow up question if you have time. For these native Android apps, I'm interested in building apps that have good backward compatibility and thus low maintenance costs. Is backward compatibility easy to achieve with Android apps? If not, what tips can you provide?

Again that depends on how far back you are thinking to be backwards compatible.

Every year the number of users on older apis reduces, and these older users then either jump forward almost to the front (new phones, many low cost versions available today) or at least somewhat to the front (buy newer used or refurbished devices).

As Google has done quite a bit of work to try to solve some of the issues with core OS updates on third party decices (Project Treble for instance), over time the fracturing is getting better (for instance the latest API releases are bringing with them changes to how 3rd party OEMs can bundle their own Linux kernel modules so that the process is simpler and so could extend the possible software update cycles).

But there will always be some fracturing in some respects.

With that out of the way, I have not made apps with lower API requirements than 21 in the last 4 years and starting on one now I set the limit to 23.

This does not bring with it as many headaches as say when I was supporting API 15 onwards.

Google has put a lot of effort into creating tools that take care of much of the biggest headaches (for instance WorkerManager for background task execution and scheduling).

It also really depends on what parts of the platform you are going to use. If you do netwark calls, local data caching and display only then you wont have any problems that need handling.

There is sadly still this lingering sense in the dev community that Android developers need to deal with massive amounts of fragmentation. I would say it is no way as bad as it used to be, and only ever becomes apparent at the edges.

Just follow the guides that Google supplies. They are excellent and take care of explaining each possible pitfall and nuance you might need to take care of.

Reply on news.ycombinator.com