And this is the relatively easy case of an app built using Apple technologies.

It can be much more difficult if you built a game using a cross platform game engine filled with binary 32bit libraries. If the engine is still around, you might be able to pay for a license for a newer version of the engine, but then you likely also need to deal with the SDK and format changes in the new engine as well as any iOS specific things you have.

Still, if software is your business and this software in particular makes you money, it's really not _that_ expensive to do.

On top of all the technical details, you also have to abide by all the new AppStore policies to even get approved.

As someone who has been developing iOS apps for 8 years, it’s preetty easy. If you wrote code that depended upon sizes of fundamental types, you didn’t write good code. if you weren’t using resources to lay out UI, you didn’t think ahead. 2x and 3x graphics can be created from your originals with OSX preview.

It’s far easier to rewrite old apps today than ever. The tools are far better. The APIs are far better. Asynchronous code is trivial to implement with GCD nowadays.

The real truth is you won’t pay the developer for their time, so they won’t give it to you. It has nothing to do with Apple.

I didn’t say it was impossible, I was just argung that updating legacy apps is a lot more work than clicking a recompile button and uploading the result. The loser here is the end-user, who can’t access their files inside legacy apps or control devices that depend on legacy apps or even just enjoy a paid-for game. And that’s all on Apple, who surely could have offered 32bit support for several more years, even if they froze the api level on 32bit uikit/corefoundation to iOS10, and as an optional on-first-use download, for existing app-owners only (so obviously they get to hold their app store storefront clean).

No the winner is the user who doesn't have to host hundreds of megabytes of 32 bit libraries in memory on their device.

That could easily be solved by offering 32bit support as an optional download, just like how 32bit windows10 prompts to install the 16bit ntvdm support libraries on first use. Or just like how iOS itself mounts a developer disk image provided on-demand by xcode during the first debug session, adding more items to the general ios settings menu in the process

A few hundred megabytes is certainly a small price to pay for users who need those legacy apps to unlock files/documents stored inside or the features the app might to provide to interface with legacy IoT devices or even a car.

It's a huge price to pay for a user who doesn't understand that their decrepit app is the reason the rest of their phone doesn't work as well as it used to.

The simple solution is for developers to recompile the apps. The developers of any apps that are truly still needed by customers, can easily convince those customers to pay for the update.

But the phone worked "as well as it used to" on iOS10 with support for 32bit apps. So why would it not work as well as that? I think what will happen is the user don't understand why their precious legacy app doesn't launch at all.

Also, they could just continue to pop up an alert saying "this app may slow down your phone" like they already did in iOS10.

Also, I doubt there is much of a performance hit anyways. For example, the current facebook app is 64bit and it is a slouch to start.

Exactly. I had a legacy app like this that was generating next to nothing in revenue. I lol'd at all the work I would have had to do to bring it up two versions of iOS, and left it alone.