Why Monoculture

At some point, I don’t remember exactly when, I told my family that since I didn’t use Windows in a professional capacity and I didn’t use it personally, there was no way I was going to go to the effort of becoming and staying smart about Windows, and if they wanted me to do tech support, well, that was just too bad. I may even have been that much of a jerk in saying it, too. To my surprise, that was pretty well received. As a result, we mostly have Macintosh computers in the house.

For slightly different reasons, we had same-platform phones in the house for a long time. (Then, it was so that we could have consistent app availability so we could collaborate on our lives.) As app developers put their logic on remote servers and spent time developing their apps for iOS and Android, platform choice became less crucial. So it wasn’t a big deal when the household smartphone ecosystem went heterogeneous.

Now, however, I’m in the situation of building a tool because the off-the-shelf tools don’t actually solve my problem to my satisfaction, and that’s got me running up against the platform differences. If I want everyone in the house to use the tool (and I do) then I need to make it possible and pleasant, and I get to pay the cost. The cost is, I either get to write three applications (one iOS, one Android, and one cloud service) or I get to figure out how to write only two (one cloud service and one cross-platform thing).

Writing two applications is way better than writing three applications. No question. But cross-platform development sucks hard when you go beyond really basic self-contained applications. I’ve got my pantry app in late alpha at this point. User account creation/deletion, pantry create/share/delete, inventory item create/update/delete — all that stuff works, and already I’ve got lots of code branches (all UI at the moment) that look like:

if (Platform.isIOS) _getCupertinoWidget() else _getMaterialWidget();

Now I’ve hit the biggie: storing stuff on a remote server isn’t free. You have to pay for the server, you have to pay for the network, and you have to pay for the storage. I’m willing to foot that bill for my household, but if I distribute this tool publicly, I want to pass that cost along to the folks who incur it. The way to do that is with a recurring subscription, and both Google Play and the App Store support those, but it’s tricky. I could go native and write three apps. I could go cross-platform with Flutter, where the Google-written in-app-purchase plugin doesn’t work on iOS and only vaguely works on Android, while the community plugin is differently-documented. Oh, and there’s the problem of continuity: imagine you start out subscribing via the iOS app, but then your phone goes swimming and you replace it with some swell Android phone (or the other way round, whatever); your subscription isn’t for the app on the device, it’s for the data on the back end. It should still be active, and you shouldn’t suffer. Maybe you have to re-enter / re-purchase the subscription, at worst, but you shouldn’t have to pay twice! How am I gonna do that? Jeez.

This is why real app development takes more than one person, or more than one quarter. But, if everyone in the house had the same phone, I could just do it native and the app would work right, look right, and probably be smaller and less buggy, to boot.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.