The Regrettable State of Mobile Development

By some metrics some could say I am productive enough, but to my own bars it’s much about faltering through each todo list entry. One such entry, lingering over for a half-year, would be to create some mobile apps for profit.

Compared to web development, mobile development feels strangely antique. Looking through some architecture recommendations or the programming languages required and the amount of ceremony needed to display text on the screen is formidable. It’s like how Mario64 or Rollercoaster Tycoon was written up in assembly — one can only respect the grit, maybe.

Nevertheless, here’s our end of 2024, and I flirt around with the idea again. The reason why it isn’t necessarily required is because you could technically use PWAs now, depending the site. If you navigate through the settings there’s a “Add to home screen” and if you serve the right .manifest or something else — sometimes shipped with the framework you’re using — there’ll be an “app” to use without the bulk UI of the web browser.

But it is an attractive idea that someone could search through either mobile App Store and it’s there waiting for them. Thus I dive into hours of research on the best foot forward, because, unfortunately, though the grit is respectable, my endurance is negligible. If it’s an assembly-equivalent effort to get mostly a duplicated experience then I’d rather not.

Surely this shouldn’t take up hours of my life, researching this, but nothing is straightforward. Even if there are only three options: React Native, Flutter, or Native.

The reason why you’d choose the first two is an attempt to skid past all of the ceremony. In addition, you get Android and iOS “for free” with “the same codebase” even if it’s littered with macros to compile for each platform. Cross-platform, surely this should save some hours.

The reason why you’d choose the latter is because of performance concerns, API access, and avoiding the inevitable breakage to ensue when going cross-platform.

So you can either lean toward some potentially naive business practicality or right-way engineering idealism to burn out in. The amount of suffering I’ve accrued from this simple decision can’t be emphasized enough.

It doesn’t help that Swift had a major upgrade which comes with an assumed concurrency model that breaks your code on first step in, requiring you to learn all the sugar before your first line. And it doesn’t help that there’s a leftover nausea dealing with anything Java, no matter how Kotlin could promise better pastures. Seeing the folders pile up and the XML configs autogenerated in the Android editor engenders the same emotion you’d find halfway through a hike: are you sure you understand what you’re signing up for?

Ultimately, no matter what language it is, no matter what mobile platform it is, I feel an exhaustion reading through the sample codebases and wonder why does everything have to be so complicated. You could petition that it really isn’t that complex, maybe I would agree, but the horror stories about getting things to just compile on React Native updates makes it a no-go, and the opaqueness of Flutter’s future with recent forks or other things makes it a no-go, so I am actually signing up for rewriting my app twice in two languages to both platforms.

It may not be the right choice. But perhaps there’s something to be had in wrong choices; perhaps all of this wasting would go away with the first step in the wrong direction.