Phone App Developers Forget About 95% of the API's

Apple is at it again, deliberately screwing with developers and users alike in a defiant act of malicious compliance (screw you Apple for making me link to Wikipedia for a rare accurate description of a concept) of an order from the European Union.

Developers are understandably upset because the upcoming change will apparently break a good number of phone applications on iOS, and Apple is obviously lying through its teeth about why it's making the change, but I find myself scratching my head about one aspect of the complaints.

What is Apple Actually Changing?

According to the very angry article I linked above (I've abandoned my attempts to find any kind of neutral-sounding writeup about this – it's all Apple fanboys and Apple haters with no middle ground ... I'm getting so tired of polarization in modern culture):

But Cupertino can't delay the DMA's other mandate: real browsers, downloaded from Apple's own app store. Since it can't bar them outright, it's trying to raise costs on competitors and lower their potential to disrupt Apple's cozy monopoly. How? By geofencing browser choice and kneecapping web apps, all while gaslighting users about who is breaking their web apps.

What this translates to is Apple is effectively breaking "Progressive Web Apps" – a kind of application that amounts to little more than a tiny web browser bundle and an HTML/Javascript-powered "web page in a box." They're doing this because they're really angry at the EU for bossing them around and they're petty enough to punish users and developers since they can't do much else besides stomp their feet.

Because so many developers have been leaning on the crutch of "just shove it in a browser!" for years now to create their phone "apps," this change is going to break a large number of apps on iPhones and iPads. That'll show the EU bureaucrats!

How Can This Be Fixed?

I have a few ideas, which I'm listing here in decreasing order of "radical"-ness.

1. Stop developing for iOS, encourage users to migrate and discourage new users from adopting the garbage walled garden concentration camp-style "ecosphere" Apple foists upon everyone who touches their stuff.
2. Yell at and/or sue Apple to make them stop this crap. I call this "controversial" because for one thing, it's pointless (they have lots of expensive lawyers), and for another, it's stupid (winning won't change much). They're doing this to be spiteful, and no amount of protests from the peanut gallery is going to change their minds.
3. Develop actual phone applications, not "Progressive Web Apps."

I raise the third option because this whole thing made me sit back and sigh a bit as I realized something. Phone apps aren't even actual applications anymore; they're just web pages running on small screens. It's no wonder so many applications run like hot garbage on phones. They're not even using native APIs!

SDK? What's That?

It's that big pile of tools, libraries, source code and documentation that Apple and Google both provide (for a fee in Apple's case, and free in Google's) for their respective operating systems that let you develop actual, "first-class" applications that can run on them at a decent speed.

These SDKs grant access to an incredible wealth of features that a developer might find useful, such as "user interface elements" (like buttons, sliders, drop-downs, text entry fields, etc.), "data storage" (optimized built-in database systems, secure access to hardware and the filesystem) and remote access (network calls of all kinds, including native support for many protocols like HTTP(S), FTP, Websockets and more).

It's almost as if you can develop software for phones that are nearly as functional and performance as a desktop application written in a native language like C/C++! In fact Android allows direct development in C/C++ now in addition to its Java clone. Apple's iOS has always used Objective-C, so you've got C-like functionality there too.

This ties back to why this change by Apple has a silver lining. Let them do it. Let them hose their users and developers. It'll encourage migrations away from Apple's walled garden and it'll both spur improvements in developer skills and flush out the crappy developers who can't produce anything besides slow, bloated web apps.

Why in God's name are the freemium gacha shovelware game developers leading the pack here in terms of native performance on their shipping products?

I assume part of the reason so many phone app developers stick to the broken web-app-in-a-box design is they think they can use one codebase to produce apps on every platform (including web browsers on desktops). This never actually works. Every platform has its quirks (each phone OS has different requirements to actually get that browser working in each app, and desktops come with the worst possible quirk: users who expect functional, feature-rich systems), and you wind up keeping separate branches (or repos) for each "flavor" you have to work on.

Rip Off the Band-Aid™️!

Note: The jerks at whatever company owns the trademark for brand-named adhesive bandages don't endorse this post or its opinions or its jerkwad author. So there.

One way to immunize yourself as a developer from the stupidity and immaturity of these companies who think they know better than you (or just want to use you and your users as pawns for their political crap) is to minimize your exposure to their ability to wreck your workflow and your output.

Paradoxically, using their own SDKs instead of relying on a browser-in-a-box actually reduces the risk of having your applications suddenly break because of some idiotic spat with a government bureaucrat or the utterly volatile court systems around the world. Yes, SDKs change and features get deprecated and removed, and I don't deny that companies still break SDKs very suddenly on occasion, but it's far less frequent than they seem to mess around with web browsers.

Generally speaking, SDKs are harder to "break" on a whim, because doing so causes major disruptions. As much as Apple hates Epic over their Fortnite silliness, they begrudgingly realize it's stupid to break their APIs intentionally to screw over every Unreal engine-powered game on the App Store. The knock-on effects aren't worth it. That and the dev tools (i.e. the SDKs) tend to be developed by a different team than the iOS and internal apps teams, and the keepers of the tools tend to be very protective of their projects. Telling a senior engineer to intentionally break something he spent a year painstakingly building and perfecting is going to be a bad time.

Companies are absolutely insane about web browsers and their uses, and it's almost always profit-driven. Apple in particular is worse than a psycho ex-girlfriend when it comes to any attempts (perceived or real) to skirt around their 30% cut of all revenues involving iOS. Beyond their 30% cut of sales, they (rather famously) battled with lunacy dispenser Tim Sweeney about their claim to a 30% slice of all in-app transactions.

The best way to try to sidestep Apple's greed is to use – you guessed it – a browser-in-a-box, shipping your paying customers (and their wallets) off to a website you control where Apple can't see the transactions or take their cut. Because of that, they're constantly screwing with web browser functionality and restrictions. You can't rely on a web browser on a mobile device to be stable or reliable.

Desktop browsers aren't immune either – just witness Google's endless war against ad blockers (you're using an alternative like Brave or Vivaldi, right?) – but so far they haven't been tampered with too much in terms of straight-up controlling third-party "web applications" like they have on mobile devices.

Write Real Applications

You simply cannot trust browser-based application designs on mobile devices. If you try to use the baked-in browser, you're subject to the whims of either Apple or whoever made whatever Android-based phone you're trying to run on. If you try to ship your own browser, you'll meet varying degrees of resistance.

Apple will sometimes refuse to approve your app so it can't even be distributed (free or not) if it thinks you're sidestepping their payment system or doing something else that's not profitable to them. Even if they allow it to publish, their exclusive control of iOS means they are free to screw with your application's functionality in an unlimited, untraceable fashion.

Android is somewhat better, but still not immune to unexpected interference in the name of "security" or whatever garbage excuse they come up with to prevent your custom web browser-based "app" to talk to unapproved remote systems.

The only reasonable way around this is to just built real, native applications for each platform you want to target. You can take advantage of features each platform SDK provides, and the end result is a faster, more reliable application that's not nearly as vulnerable to the whims of whatever grumpy executive decides to target another browser end-run-around the walled garden that morning.

I know this is a scary prospect to a lot of developers because it means stepping outside the "comfort zone" of Javascript. Don't be scared though – there's tons of libraries and frameworks out there for other languages, and you'd be surprised how featureful and powerful they can be.

Qt is a good example of a toolchain that can build native applications for Windows, MacOS, Linux, iOS and Android. It has an unfortunate licensing situation (it's "free as in beer" and you can have its source code, but they try really hard to get money out of you), and it's got some warts in terms of how a few of its features are implemented (looooots of macros), but it's still a superb toolkit.

As a sidenote, if you're just writing a desktop application and don't care about mobile platforms, you can use the free/OSS CopperSpice instead to get a significant portion of Qt's functionality without the licensing nonsense and without the macro soup (they mandated a minimum of C++17 and used its new features to implement signals and slots natively, which is a really cool piece of engineering).

If you're desperate to stick to Javascript you still have some options that don't involve using a web browser. React Native comes to mind.

Just please, please climb out of the web browser sandbox. You've got an entire operating system custom-built for mobile devices at your disposal. There's no point in walling yourself off from more of it than you have to.