Another example from someone else:
"That literally happened to us. 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."
so the existing build doesn't support iphone X? Isn't this a good reason for apple to push your app out because they want all their apps to support their latest phones?
Even currently I don’t allow Visual Studio Mac to update after I learned the hard way that the new version needs new Xcode, which needs new macOS which isn’t even available on my computer.
(I only recovered a working setup using Time Machine.)
> "That literally happened to us. 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."
* Apple requires you add support to new devices to push a new build. (this is the principal policy decision).
* This new support requires you build with new tools (Xcode 9)
* New tools require newer MacOS.
* Newer MacOS doesn't compile old Unity3D code.
* New Unity doesn't work with their codebase.
#1 is a policy decision, and solely Apple's choice. #2, #3 are (reasonable) technical pain owned by Apple's ecosystem. #4 is an annoyance that's mostly Apple's fault but is shared somewhat by Unity. #5 is "Unity's fault" for imperfect backward compatibility.
> * Apple requires you add support to new devices to push a new build. (this is the principal policy decision).
Doesn't the original, old app run unmodified on new devices anyway?
Only in an ugly fashion because of different aspect ratio & notch.
Apple required you to at least nominally support the iPhone X to push a new update to an app.
1: Native appearance on new devices is solely to prevent them from looking bad on a user's new device. Presumably the user would rather have their apps work, but Apple wants the appearance.
2: Apple only ships new SDKs with new Xcodes and new Xcodes can't run old SDKs. This is strictly a technical policy to limit Apple's development effort. People have been able to extract old SDKs from old Xcodes to run in the new version but that's become harder and harder over the years.
3. Another technical policy, this time with many parts. Apple starts a new Xcode version's life supporting the current and future macOS versions, but then removes support for what is then the previous version at some point. This lets them remove compatibility code but cuts OS support in the middle of a major version cycle. Additionally, Apple seems to be dropping arbitrary hardware support in macOS over the last few years, so many developers can't upgrade to the latest OS at all.
I basically said that.
You echo the way I distinguished things: #2 and #3 are limitations on what Apple chooses to support (for somewhat reasonable technical reasons). I suppose you could call them "technical policy". #1 is a deliberate marketing choice to leverage the App Store to make developers improve support for new devices.
That sounds like a valid reason to require you to submit a new build. it came out in 2017 and most iPhones follow that build style now.