The Decline of Mobile Development | Hacker News Reader

The Decline of Mobile Development

donnfelker.com

23 pointskarlicoss17 comments

This has not been my experience (Source: Apple native developer, since 1986).

It is a pain to deal with their App Store, but it isn't intolerable. I don't charge for my apps, but I understand that the Apple ecosystem is very lucrative for devs that do.

> causing codebases to become complicated and littered with if/then evaluations for various SDKs

I have found that I almost never have to do this, and when I do, it's usually a bad code smell. Part of the reason, is that I develop native, for one platform at a time. It might be another story, entirely, if I have to develop for multiple ones.

I just got contacted by a friend, wrt an ObjC app that has been deprecated for over a decade. He reports that it still works fine, on iOS18.

Many years ago, I spent a few months, learning Android. The thing that really put me off, was the Android Pizza of Death. That's the pie chart that describes the percentage of users, running various Android versions.

It was sobering.

Apple basically allows me to write support for the current OS, and support just one back. The app I'm in the process of releasing now, works in iOS 15, but I am declaring support starting at 16, and it works fine in 18.

I agree, I've been developing for iOS since 2011 and the only unpleasant change that has happened is the growth in number of screen resolution. Doing pixel-perfect UIs just for 640x960 and 1136x645 was much more comfortable.

Android, on the other hand, is a dumpster fire. The worst SDK I've worked in my life, building UIs there is incredibly frustrating.

The actual work of mobile development is much easier now than it used to be. The tooling and APIs have evolved and matured and the hardware is so much faster now that you have to spend a lot less time worrying about performance.

The issue with mobile development is that web apps and PWAs can cover a lot of the same ground now and getting people to install new native apps is really hard.

The shear number of apps that provided no value to the users, but were merely a data grab has resulted in a serious impediment in my circles.

I think the industry is going to need to find a new source of income or focus on customer value beyond dark patterns on mobile web to change that.

I don't envy mobile developers trying to regain that trust.

Sometimes I am wonder why an app is an app, and not a page that can be self hosted.

I know. Sometimes it makes sense. Sometimes it is easier. Sometimes it is for work, and it is a requirement. Often it could be a page, and is not just to have access to your device data.

For myself? Most of the programs I write are pages. Works on any device, Writing guis is not a problem, there are a ton of useful frameworks. There is no need for synchronizing data between devices, not need to install it on client devices etc. Etc.

Interesting there aren't any Android developers here. I develop for Flutter so I do both and Google is a pain to deal with. Once they kicked my app out of the app store because the month currency overflowed to the next line which was 'misleading'. Plus anything Gradle related is a pain to deal with. It's not quite as bad as what the author suggests though. Apple is OK, once your app gets accepted which may take a few tries.

Related on the Android tip:

Ask HN: Why is Android Development so difficult/complex? (compared to Web and Desktop)

https://news.ycombinator.com/item?id=40742719

Ask HN: Am I crazy or is Android development awful?

https://news.ycombinator.com/item?id=41062292

How much does developer happiness really play a role?

Probably significant in terms of speed of development, time spent maintenance projects, etc

Re: Happiness, my personal experience corroborates, for what it's worth - though inversely to the headline: I love iOS development and can produce reliable, complex UIs with react-ish state-view management in a day, with no 3rd party frameworks; when I do web (UI mostly), I'm miserable and unmotivated.

I've been lucky enough not to run into the things people often complain about with Apple. They don't mysteriously reject my apps; and when they deprecate/require something, the reason makes sense to me and it's easy to accommodate. The differences I experience are rather in the quality of languages and APIs/frameworks.

SwiftUI is the exception. If they deprecate UIKit/autolayout, I'll move to the backend in one weekend.

I was so frustrated by this that I quit Apple altogether. Bought a Windows laptop and an android phone.

WSL was good enough to keep me on Windows, but I am back on iPhone one generation later (android was not my jam).

If I had unlimited time, I’d be tinkering on PWAs (super glad to see rails pushing in that direction).

I currently only do web development. I figured if and when I needed to develop a mobile app, it would probably be easiest to use something like React Native. Most of my skills would transfer. And I wouldn't have to deal with majority of the issues the author of the article pointed out. This is likely not an option for games. But for non-games I thought it wouldn't be a massive challenge.

I have never developed a mobile app, so I may be oversimplifying it. Let me know if you have been down this path and agree/disagree.

Hybrid app developer here (Apache Cordova). The work that I do is pretty close to web development + some hooks into native code (which is done by plugins) -- so your skills should transfer pretty readily.

The only headache that Donn eludes to that I've experienced had to do with Android's scoped storage. It's taken them a few tries to get it right, and their documentation hasn't really provided good best practices, so I've had to roll with the punches a few times. But I really haven't had to deal too much with Donn's other points.

Building hybrid mobile apps for a long time. Capacitor, and earlier, Cordova, packages SPAs perfectly.

React Native also works but has it's own set of challenges.

I have a pretty simple game on the iOS app store. It is simple enough that I have probably written it about three times. One of the times I tried to do everything the "apple happy path", but the final iteration in the app store completely rejected it (and was written in C, primarily on Linux then ported to iOS as a final step). I know that familiarity plays a huge part, but the experience of just writing it in plain C (and using SDL2 as the platform abstraction) was so much simpler and nicer. The things I had to implement myself instead of "coming for free" (simple physics, app lifecycle stuff etc) were relatively easy to do.

I haven't ported it to android, but I expect it to be simple too.

What I don't understand from the article is the moving goalposts. I had one threat of store removal because of a lack of sales and updates, so I found some stuff I didn't need to ship and removed it and pushed that as an update. Not so. I think it has been in the store 4 years or so now, so this doesn't seem too much work. I guess it could be churn in the areas that I deliberately avoid (e.g. I have no networking and only use the screen and audio out)

There is the target API level policy: https://support.google.com/googleplay/android-developer/answ...

So if your app was for Android, it would not be installable on new devices.

For iOS I am not sure, I think they are better about leaving old apps alone.

The de-facto apps should have been PWA, free, open, accessible, cross platform.

Was that not the idea with the early iOS releases? There used to be no app store and all things were done via web app.

Reply on news.ycombinator.com