Someone replied to the original tweet with an example of their iOS dev experience:
Boss wants to change our iOS game icon. Changing icon requires a new build. A new build requires iPhone X support. iPhone X build target requires Xcode 9. Xcode 9 requires macOS 10.12. OS update breaks old Unity3D. Upgrading Unity breaks build.
Systems improve over time. Apple's privacy in iOS improved a lot. Not updating your apps makes it hard to keep up with API changes. Its normal you have todo some work to ensure it still works. Sometimes you're out of luck. But not all dependencies stay with us forever. Software is sadly enough not immutable, environment impacts how software runs... My old android game stopped working on newer devices 3 years ago due to a OpenGL bug that was fixed, i depended on the bug in order to make my app work.
While I loathe apple's moves lately, including this one, I have to agree with this comments sentiment.
Software is not free once written. You need to expend resources to keep it up to date and secure.
If you aren't keeping things up to date, you are neglecting the maintenance of your application. You wouldn't be surprised if your car stopped working if you never change the oil. Apple is taking proactive actions here, presumably to protect the end user experience. Wether or not I agree with the manner of proactive action is a different issue. We know apple loves to exert tons of control over things like this.
Apple is difficult to work with. It takes maintenance to keep apps up to date. Yes, the two year thing seems a bit over the top but remember the real issue is that this guy can't submit a new build because he hasn't added support for the last two OS versions.
The app store is hard to work with, but they payoff is immense also.
Immense - 30% they take to give you more trouble and kick you out whenever they deem it "necessary"... you know 'cuz you, their customer is the biggest threat to them and the users (Google/Apple)... honestly at this point I am all down to just go to another app store... once they let you do that without restrictions on the device Yyou paid for....
Listen, I totally agree with you. It's total BS and should be better.
That being said, I also think your frustrated and typed word salad into the reply box.
I'm not apple. I don't like apple's practices. I don't own any apple devices (beyond what's required to support an iOS app) because I take an issue with the same things you do.
The reality is, if you want to support apple devices, you have to play their game, and that means updating your apps regularly. Sorry if you don't like it. I don't either.
This is ridiculous. A game that has no online component has roughly zero maintenance burden. This is why, for example, the original Deus Ex is still one of the better ways to spend your time playing games on PC.
Network connectivity has brought along with it a certain level of toxicity around updates and maintenance and such. At the very least Apple could be shipping older runtimes, downloaded on demand similar to Steam Proton runtimes.
The more reasoned part of me says that you're totally wrong and you can boot up Windows and run software from two decades ago and the only real issue will be high dpi support which can be worked around.
There's nothing actually necessary about what Apple is doing in the least. They could even take a soft approach and simply slap a "vintage" tag on old unpatched software and call it a day. There is something profoundly stupid about automatically banning any software more than 2 years old from all Apple devices without even giving users the choice to use that old software. I'm not even saying it's morally wrong, or it's bad for consumers, I'm saying it an incredibly dumb decision.
There is SO MUCH niche software out there designed for a tiny audience which nobody will ever be able to afford regularly updating so long as it's still basically working. Trying to maintain this ideal where only well patched up to date software appears on the app store is just dumb.
Sometimes they just force you to implement feature for them, like “Sign in with Apple”
> We’ve updated the App Store Review Guidelines to provide criteria for when apps are required to use Sign in with Apple. Starting today, new apps submitted to the App Store must follow these guidelines. Existing apps and app updates must follow them by April 2020. We’ve also provided new guidelines for using Sign in with Apple on the web and other platforms.
> 4.8 Sign in with Apple
Apps that use a third-party or social login service (such as Facebook Login, Google Sign-In, Sign in with Twitter, Sign In with LinkedIn, Login with Amazon, or WeChat Login) to set up or authenticate the user’s primary account with the app must also offer Sign in with Apple as an equivalent option.
And implementing Sign in with Apple in Unity is one of the worst experience in my career that I dedicated a blog post talking about:
- Native Sign in with Apple button not working in Unity
- Official Sign in with Apple plugin provided by Unity also not working
- Hooked up API with help from GitHub and created Sign in with Apple button by myself ended up getting `4.0 Design` rejection without explanation
- Trying crazily to contact Apple reviewer for weeks only to find out you have to use system font on that button
- Unity cannot support new Thai system font after iOS 13 and they mark it won’t fix
- Ended up building a native sample app and screenshot Sign in with Apple button from it in 12 different languages into PNGs and ask the my designer co-worker to remove background for me to import them into Unity
- After all these the update is finally accepted by App Store
- Casually downloaded games by other companies a week later, saw a totally malformed Sign in with Apple button not being nitpicked by reviewer and just went live like that
While Apple could do a Microsoft and try to keep third-party software working for decades, they've realised they can offload that work to the third parties for free.
I can easily run old x86 Linux binaries on ARM, and vice versa, automatically with binfmt_misc. User-mode emulation allows you to run x86 Windows binaries on ARM WINE, as well.
And Microsoft fully supports running x86 applications on ARM Windows[1], as well.
My raspberry pi boots Windows 3.1 just fine (through dosbox). It's more likely to run a random dos / win 3.1 program than my iPhone is to run a random piece of old iOS software.
Put another way, the raspberry pi runs all but two of the games I played in that era. I can think of 6 iOS games that no longer run, and I played at least 10x as many games on DOS as iOS.
My experience with productivity software has been similar.
Totally, but that’s not what I’m talking about. We did the move from OpenGL to Metal, for example. It was tough, but it is a huge improvement and we were glad to do it to avoid code rot. I’m talking about how something that we wrote and compiled with the last fully updated IDE a few months ago suddenly stops working in the next release and requires tweaking. This isn’t 20 year old code that we haven’t touched. It’s 20 year old code we’ve been religiously updating the entire time.
Technical debt has a cost. Raymond Chen has countless blog posts about what it takes keeping backwards compatibility working. For example, an update to some part that should not break anything actually ends up breaking an app because the developers decided to monkey patch based on a match of a byte string or whatever that ended up changed.
The only reason WINE works is because of a massive community effort to reimplement those bugs that Windows is forced to keep.
there is no reason to assume a priori that systems improve over time. if anything, the opposite is the case. the overall computing experience has been steadily declining for many years, due to the web, javascript, electron, etc
Working on games with Unity for nearly a decade, the standard approach is to defer upgrading Unity as long as possible. Generally we stay on the old LTS (Long-term support) version until it’s no longer supported. Latest version and new LTS are very unstable with game crashing bugs on certain platforms that I had to spend weeks to track down and spend weeks to convince Unity QA there is actually a problem then wait for months to get it fixed. It’s better to just stay away from the latest and greatest, having other people do the demining.
Games aren't like other software. People are still playing Psychonauts even though it hasn't been updated in a decade. Double Fine doesn't have the resources to go in and update the game engine every year.
(I'd argue there's more room for this in non-game software as well, but certainly for games...)
It is already very time consuming to stay up to date with Apples ecosystem. Swift evolves. Xcode changes. The runtime. The App Store. The APIs evolve. SwiftUI is radically different every year.
Throw something like Unity in the mix and now you have even more things to keep up to date.
You can say well that is just nonsense. My app is finished. But is it really? what if you actually need to do a critical bug fix. Or something to be compatible with new hardware?
There is no simple answer here. But one thing I’ve learned is that staying as “standard” as possible is a huge huge advantage. Apples upward path is mostly manageable.
I wonder for how many people Mojave is the last Mac OS they can use simply because Adobe stopped selling software for anything later (you can only rent), and other various 32-bit reasons.
Adobe products are sadly required for industry work.
Imagine if the tools in your shed turned to dust after 5 years. And these are analogue, physical objects. Digital objects if stored in a properly error-correcting medium, can last indefinitely. No excuse for this.
Imagine a library of books where every book over 5 years old is burned.
You deserve more upvotes, because your analogies are not far from the truth. We are living through a black hole of history, where valuable information is being destroyed at unbelievable rates by virtue of it becoming completely inaccessible through the planned obsolescence of incessant upgrades.
That's not a reasonable comparison. A more accurate one would be something like having a 25 year old 12V battery drill and expecting the manufacturer to still make and sell the NiCad battery pack it used. Sure they could do it but it doesn't make any sense. Technology has moved on and there's no consumer demand for it.
I agree that Apple and other companies are too aggressive about breaking compatibility but it's not the same thing as tried and true physical objects.
This is not a good comparison. Nobody is trying to use a new battery. They just want old battery to continue working as it has. Code does not rot like batteries wear out. Companies deliberately break compatibility, and then they blame arising problems on “code rot”.
Changing icon should not require a new build. A new build should not require iPhone X support. iPhone X build target should not require Xcode 9. Xcode 9 should not require macOS 10.12. OS update should not break old Unity3D. Upgrading Unity should not break builds.
These are all examples of shitty engineering decisions that throw backwards compatibility under the bus for shaky (expedience, mostly) reasons.
Here's the thing though—if I want one of those books that the library removed from their collection, I can do some research and track down a copy from another source.
On iOS, there is no other source. Once Apple removes an app from their store, that's it—unless you bought it already, it's gone forever, no recourse.
> Boss wants to change our iOS game icon. Changing icon requires a new build. A new build requires iPhone X support. iPhone X build target requires Xcode 9. Xcode 9 requires macOS 10.12. OS update breaks old Unity3D. Upgrading Unity breaks build.
* The iPhone X was released on 2018.
* Xcode 9.0 was released on 2017, and 9.4.1 (last release) on 2018.
* macOS 10.12 was released on 2016.
I'm sorry to say, but this sort of setup does not reflect well on anyone working on the project. Apple's call out should be considered a wakeup call.
Also, doesn't Xcode 9 only support iOS releases up to iOS 11? The global market of all iOS versions lower than iOS 11 should lie in the lower single digits.
The problem here is unity (which, by the way is one of the most popular game engines, and is often sold as the indie friendly, mobile friendly engine). Standard operating procedure for Unity games is pick the latest LTS engine version as the base for your project, and don't ever update, because the updates are _so_ much work it's untenable to keep up with them. (This was official advice given to us by a unity sales rep at one point in the last 2 years).
These aren't like node updates, these are closer to Firefox removing legacy extensions, except happening quarterly. There's no guarantee that something that is "stable" in your version will work the same way in a newer version. Unfortunately, the engine is tied to specific iOS SDK versions, so in order to use a more recent iOS SDK you're forced to upgrade your unity version alongside it...
The idea that Unity (market cap $22 billion) should put in the work to stay compatible while Apple (market cap $2.64 trillion) should not is deplorable.
I'm certainly not making the claim you accuse me of, however Apple's compatibility is substantially better than Unity's. Apple's reasoning for breaking backwards compatibility is often sound; reducing the attack surface of misused APIs. The alternative is what you have on Android right now, a bunch of applications that still ask for the sun and moon and stars for permissions because they can. Unity's path is more of a scorched earth policy in my experience.
Boss wants to change our iOS game icon. Changing icon requires a new build. A new build requires iPhone X support. iPhone X build target requires Xcode 9. Xcode 9 requires macOS 10.12. OS update breaks old Unity3D. Upgrading Unity breaks build.
https://twitter.com/aaefiikmnnnr/status/931222777301835782?s...