“build disappears”

I have tried to build the app store bundle and test on a local device via dropping the .ipa Apple Configurator. I still have the same issue. Would this be fixed once it is submitted and deployed with App Store version for iOS 12 devices?

@diniska , does your remedy survive a reboot of the machine? When I tried my cleaning (I did the whole CoreSimulator directory, but now I see that I probably only needed to do the images.plist file), my simulators downloaded fine, but then they disappeared again after I rebooted my machine.

@Manuel_Apps I am in the same situation... the current version of my app on the App Store is defunct for iOS 12 people. I am now working on a build with target iOS 15. As soon as it’s submitted and released I am planning on making the broken release unavailable. This way iOS 12 users have to uninstall the broken version so they can reinstall the (still working) version before that. I totally agree with you. I wish Xcode 16 (the first Xcode that did not support iOS 12 anymore) would have prevented me from building the app with the unsupported target. Instead it was waved through without warning. Yes, the Xcode support page said it didn’t support iOS 12, yet there was no hard stop. I was not aware I was sitting on a time bomb for at least 1 year. I thought only debugging was not supported but building was -- because it worked. The broken app happened a few days ago when my customer was holding an event in front of an audience, some of which had iOS 12 on their iPads. One can imagine t

Thanks @Manuel_Apps and @BioDranik for your metoo’s. In the meantime I have received a response from dev support. They gave me the same answer that is found in the thread pointed to by @DTS Engineer . This is the tech part of the answer: When you submit to the App Store, Apple modifies your binary. They strip your signature, encrypt the binary and re-sign it. This encryption alters the Mach-O file's page alignments and load commands. Nothing I can do about that. I’m fine with progress but I wish Xcode would have somehow prevented me from using the unsupported deployment target. Ever since Xcode 16 (which also does not support iOS 12) I thought my target was ok. So I will bump the target to iOS 15 (for now, in the future possibly higher). Since my app in the App Store is defunct for iOS 12 users I will upload a build with target iOS 15 and then mark the broken build as unavailable (App Connect > Pricing and Availability). This way the legacy users will get the last working version.

I would like to kindly ask for your assistance regarding our TestFlight external testing review. We submitted 1.0.1(1) build for external testing on March 17, and it has now been over two weeks, but the review has still not started. This delay is affecting our testing schedule. Could you please help check the status of this submission and assist in moving the review forward if possible? We would greatly appreciate your support.

We used Xcode 26.2 to successfully build iOS 12 apps before March 25. After that, the same code crashes on iOS 12 at startup. It would be great if Apple officially confirms if it drops iOS 12 support in such a weird way, or if it was an issue that can be resolved.

The same for Organic Maps: internal CI TestFlight build on March 25 works on iOS 12 device, the same binary with a few string resource changes, built on March 26 does not work. Built with the frozen version of Xcode 26.2. That implies some kind of Apple involvement when builds are uploaded.

Thanks for the clarification. However, this is quite concerning from a developer and user-impact perspective. This app version was: • successfully built and uploaded with Xcode 16.4 • accepted in App Review • distributed through the App Store Despite having a deployment target of iOS 12, the build is now crashing on launch for all iOS 12 users, without any prior warning during submission or review. As a result, a previously working user base on iOS 12 has effectively lost access to the app overnight after updating, which is a significant regression in functionality. If iOS 15 is now a strict requirement for App Store distribution, it would be much safer for developers if: • the upload was rejected at submission time, or • a clear warning was shown before release rather than allowing distribution of a build that cannot run on supported devices declared in the app’s deployment target. Is there any recommended way to: Restore functionality for existing iOS 12 users (e.g. keep last compatible ve

still hasn't even been fixed in iOS 26.4 which is absolutely insane to me. Only workaround I've implemented was to force the source grid to rebuild after the detail view actually disappears and it fixes the swipe to dismiss getting stuck behavior but then causes the source to flash once it's settled.

I'm seeing exactly the same crash, same source code, same Xcode version two weeks ago did not have the issue. I've pushed a new build 2 days ago and users with iOS 12 are getting a crash on launch.

Here is more concrete context. Platform / tools Target: macOS app Language / frameworks: Swift, SwiftUI, SwiftData Cloud sync: SwiftData with CloudKit mirroring in the production configuration Xcode: 26.4 (17E192) Test OS: macOS 26.4 (25E246) What I’m seeing In the macOS app, issue board scrolling can become inconsistent or very slow. Changing an issue status from detail view can be very slow. Scrolling the status menu itself can be slow. Typing in issue description/notes fields can become sluggish. The problem is much more noticeable with my full production-sized dataset than with a small dev dataset. What I’ve tested so far I compared a small dev dataset vs a much larger production-sized dataset. With a small dataset, the same UI feels fast and smooth. With the large dataset, the same UI becomes noticeably slower. I also tested a local-only copy of the production dataset with CloudKit disabled. That improved some behavior, but it did not remove the lag entirely. When I reduced the local test dataset from ~1