It's not that games from 2009 don't run, only games that haven't been updated since 2009 don't run. All a developer needs to do is recompile and push an update.
* Ensuring your code still works now that CGFloat and ints change size (can easily trip up code, I've seen things fail subtly and then grow into huge errors with combinations of NSInteger and "-1" etc)
* Updating all UI to handle new behavior (yes, just linking with a new compiler will automatically opt-in to new behavior that might totally break interactions and taps)
* If your app is really old, rewrite all UI to not assume a 320px wide screen (this can be brutal)
* Handling new restrictions and requirements such as supporting IPv6-only network (fun if your app is used to configure an IoT device over IPv4 LAN), and Transport Security (fun if your app allows users to connect to random servers around the world)
* Handling new permission models for camera/gps/contacts/photo library/audio library access, including refactoring your code to deal with asynchronous results
* Updating all your graphic assets for @2x and @3x resolution as well as new app icon sizes (hope you still have those .PSD files, and hope your designer wasn't doing pixel-perfect painting for your bitmaps!)
* The original developer must still be in business, still pay the $100/year developer fee, and still have the source code and the talent to fix it.
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.
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.
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.
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.
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.
I had to keep giving Apple £100/year just to let people keep downloading the game for free. At some point I tried recompiling it for a newer iOS, and I get hundreds of message about depricated APIs that I had to change to get it accepted by Apple. Instead I let it drop.
I can't even put a copy online for people to download, the game is just dead and gone thanks to Apple. I can still run Windows games from 20 year ago and with DOSbox, DOS games from 30 years ago. My own iOS game on the other hand is dead, never to be revived.
On the other hand, thanks to this kind of "burning bridges" users are not tied to 20 year old compatibility kludges and legacy BS in the OS and libs.
>My own iOS game on the other hand is dead, never to be revived.
Which, App Store or not is the fate of tons of games -- most 8bit/16bit era games we have, we just have thanks to emulators.
I play board games and there are games nowadays that require an app to play (see for example Alchemists). I've argued that this is a bad idea since at some point the apps will probably stop working as we see happening in iOS 11. But people always argue back that someone will be sure to create a version of the app to keep it going. I may be a cynic, but I think that is incredibly naive to believe that will happen.
Sure you can.
Put the source code up on Github and anyone can download and sideload it on their device. Don't even need a developer account to do that these days.
>At some point I tried recompiling it for a newer iOS, and I get hundreds of message about depricated APIs that I had to change to get it accepted by Apple.
Games are generally funded by a publisher who retains all rights to the game, the developer is contracted for some time, then goes on to work on something else. A publisher is not going to pay for the update of a paid-upfront game from 5+ years ago, there's no ROI in that. Without a continuous revenue stream, publishers don't keep updating games.
Furthermore, both publisher and original developer can fold, leaving the game orphaned.
- apps which were abandoned
- apps which were replaced by a successor. In the absence of update fees, this is the easiest way to generate new revenue for continuous updates. I am happy to pay for app maintenance, but this scheme means, that there is no automatic data migration from the old to the new apps.
Hello, Omnigraffle. I bought this on iPad, used this something like, three times before having a need to use it over a year later and "Sorry! There is a new version to buy and your version is no longer supported, or runs!". It wasn't cheap, as apps go.
Never, ever buying anything from Omni, ever again.
Edit: To add details, I bought this for £35 on iOS 7. When iOS 8 came around, it was discontinued, left to crash on open, and you had the "opportunity" to buy version 2 all over again.
It's one of the most polished apps around. You don't owe the Developer's time indefinitely from one $5 purchase, and you're free to move to an alternative. I'm happy to continue to support the apps I love -- they generally aren't asking a whole lot.
Additionally, in the case of Twitter clients, they also can't add a lot of new customers b/c Twitter has capped their allowed clients. If they didn't charge customers again, they wouldn't be able to sustain the work with new ones.
Which part of the guidelines, specifically?