Xcode 26 still silently supports 12.0 builds, you just have to manually enter it. The problem is that upload servers won’t accept it anymore already now, even though it was communicated (in the link you gave) this would happen only in spring 2027.

Suggestion: Why not make servers accept 12.0 until spring 2027, as the error message says. Xcode 27 already prevents building for 12.0 so we can still use Xcode 26 to submit final builds for 12.0-users. This could be a pattern for future minimum version bumps, too. First Xcode blocks the build, servers follow a while later.

For example, in my case, we’d like to revert a function that we have received criticism for. Not possible because servers are rejecting 12.0 even though the error message says the minimum of 15.0 is only from spring 2027 ...

Until Xcode 26, iOS 12 was still ”soft” supported, by which I mean that you could enter ”12.0” and it would silently be ok with that. Only Xcode 27 rejects it at build time. Error message says ”Starting in spring 2027...” but surprisingly the minimum version 15 starts already now. As of now, with servers rejecting 12.0, we cannot send a bugfix update we’ve been preparing. I understand what you say about baseline. I’d appreciate a mechanism that forces us to upgrade ”less suddenly”.

Check out the comments of @App Store Connect Engineer’s reply above. They installed a fix so new uploaded builds will work. Others and I can confirm it does. For me deployment target 12.0 works on my iPhone 5s with App Store Release build (didn’t test builds for internal or development testing). Note it does not work if you install an .ipa locally, you need to upload the build for the fix to work.

Thanks a lot App Store Connect team. We will increase the target in the near future to avoid such issues.

I recommend not to go back to using UIKit. There is an interesting approach here. The solution is to use a model class that conforms to ObservableObject, and use @Published variables in the NavigationLink selection. Add willSet/didSet to these variables, and you will know when a selection was made. willSet/didSet do not work on @State variables so using @Published variables does the trick. A similar approach is also taken on this sample code by Apple.

But what if we want a column-style navigationView?