iOS 11 drops 32-bit app support – do we care?

In the upcoming months and until a short while after Apple’s inevitable autumn event where they’ll publicly release their new operating systems, computer magazines and news sites will try to create headlines about how Apple is killing off tens or hundreds of thousands of apps. What’s true and what’s not about this?

Well, yes: iOS 11 kills the support for 32-bit apps. Any such apps on your iPhone or iPad will stop working the day you upgrade to the upcoming operating system. I had a discussion with a friend the other day, regarding Apple’s decision to drop 32-bit OS and app support. He didn’t really like that decision, but I would like to put it in perspective with this beautiful table:

What I’m trying to indicate is that we have two conflicting ways of approaching the problem of legacy software:
One way would be to try to avoid rocking the boat, keeping backwards compatibility even at cost. The good thing about this is what we see in the Windows ecosystem: As long as the computer’s CPU is capable of running in emulation mode for the bitness required1, software just keeps on working. Particularly in business applications, not breaking backwards compatibility may be worth significant sums of money.
The bad thing is a lack of incentive on the part of software manufacturers to update their programs. A “Change is Bad” attitude easily develops when changes are few and far between: people don’t get enough practice in performing change in a safe way, and change management and reliability suffers as a result.

The other way to approach legacy software is to enforce changes for users who want to stay up-to-date. This is the approach Apple has chosen in many areas, for good and for bad. Since they control both their software and their hardware platforms, Apple are in a very good position to simply stop supporting old ways of doing things, and provided they wait a reasonable amount of time this shouldn’t cause a lot of problems. As evident of my table earlier in this post, the last iPhone unable to run a 64-bit environment will turn 5 this year. Considering the evolution of mobile hardware, I’d say anybody who still uses their iPhone 5 has gotten pretty decent mileage out of them – remember that every new software update up until this fall will have worked on that device.

But suppose you actually are heavily invested in some older app; how can you know whether it supports 64-bit iOS versions?
Look at the Version history field in the App Store. If an app was first published in January 2015 or later, or if it was last updated later than June 1 2015, it had to be able to run in a 64-bit environment.

There’s no stopping the wheels of time – iOS and Apple hardware will move on. I could recommend freezing a device, not upgrading it beyond a certain OS version. I won’t, because I consider that a terrible idea, at least for any device connected to the Internet, and for any device used for production work.

Luckily, we won’t see another bitness update in the foreseeable future. The two latest ones were exciting enough.


1 An x86 compatible CPU can by design not run 16-, 32-, and 64-bit code simultaneously, but can switch between 32/16 and 64/32 modes after a hard reset.

SFTP revelations

I got myself into a situation where I had to copy some files from my computer to a server that presented sftp but not scp. Since I’ve never needed to use the sftp protocol from a cli-only machine, I haven’t really thought about how it works in non-interactive mode. Batch mode allows you to create a batch file of sftp commands to execute on the server, but what if you just want to do a single operation?

Pipes to the rescue:

Putting a dash after the -b option causes the command to take batch input from stdin. Piping text to the command, then, means that text is swallowed by the sftp client. Nice and simple.