Having to use the latest Xcode to build and submit the app is often already a big enough headache, due to how many things Apple changes between versions.

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."

https://twitter.com/aaefiikmnnnr/status/931222777301835782

> A new build requires iPhone X support

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?

Reason? Maybe. A good one? I don't think so.

For a company who sells phones, it's a pretty good one.

This line of explanation is an excellent example of when C-suite types walk in and ask, "Why can't you do {simple thing X}"?

Reading this increased my heart rate.

This is of Apple madness has been my life for 6mo now. I've become the "deal with Xcode BS" guy for our cross-platform React Native app. It doesn't bother me but Apple really does create a lot of unnecessary pain.

Especially for people who can't be bothered to develop native applications.

I remember this sort of madness constantly. At that time, the Unity to iOS build process involved exporting projects to Xcode including C OpenGL code, which I would sometimes have to fix as it their compatibility would drift.

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's not really about Apple but about Unity. I've recently written about what a nightmare it was to be a Unity developer: https://news.ycombinator.com/item?id=31065208

Unity sucks, but:

> "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.

1, 2, and 3 are actually all Apple policies.

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.

> 1, 2, and 3 are actually all Apple policies.

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.

I'm not familiar with iOS devices, but..

> * 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?

> 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.

> A new build requires iPhone X support.

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.

Just to clarify, the tweet was a couple of months after the iPhone X came out.

This tweet seems to be dated yesterday (4/22/22)

The tweet is dated they're talking about/ linked up the thread, is dated: 10:09 AM · Nov 16, 2017

https://twitter.com/aaefiikmnnnr/status/931222777301835782

When Apple launches a new phone, they manage to keep “old” apps compatible with the new hardware/OS. After that, developers are no longer allowed to upload such apps, even though they would work perfectly fine. It would not be a big harm for apple or end users if developers were allowed to lag behind for a year or two.

Jeez - this was stressful to read.