“xcode github”

For reference, I’m attaching screenshots of: the App Review message that says these entitlements must be boolean and true, and the Xcode 26.4 release note section that says to use the new -string variants with values 1 and 2. These are the two pieces of guidance I’m trying to reconcile.

Could you download Xcode from the https://developer.apple.com/download/applications/ outside of the VM and then transfer it to the VM?

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

Has anyone experienced a similar situation where IAP works on device but fails during App Review? Any suggestions on what might be different in the review environment? Apple reviews your In-App Purchases in the sandbox environment, the same environment you use to test your products. In the sandbox, StoreKit uses data you configured for your app in App Store Connect when the app calls StoreKit APIs in the environment. Be sure to test your products in the sandbox before submitting them for review. If your app uses a StoreKit configuration file, be sure to disable StoreKit Testing in Xcode before starting to test in the sandbox. For more information, see Setting up StoreKit Testing in Xcode. After you successfully test your products in the sandbox, be sure to submit them for review in App Store Connect. For more information, see Submit an In-App Purchase.

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.

Can a first subscription be fetched in the sandbox before submitting an app version for review? Does the “Finalize before submission” state prevent StoreKit visibility, even in sandbox? Testing In-App Purchase in the Apple sandbox environment doesn’t require you submit your In-App Purchases for review. Additional information: the same subscription works correctly with StoreKit local testing in Xcode (StoreKit configuration file). The product is returned and the purchase flow behaves as expected. When you enable a configuration file in your Xcode project, this file becomes active. StoreKit uses data saved in the active configuration file when your app calls StoreKit APIs in the test environment. For more information, see Setting up StoreKit Testing in Xcode. To test in the sandbox, you must disable StoreKit Testing in Xcode in your Xcode project. This enables StoreKit to use data you configured for your app in App Store Connect when the app calls StoreKit APIs in th

Would be useful if this worked. Without the xcode stuff the VM would be useless for me.

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 version ava

Distribution through the App Store requires a minimum deployment target of iOS 15. For future reference, you can find this information listed on the Xcode Support webpage.