build disappears

Never mind. Building locally revealed the real problem.

Thanks for the post. Have you search the forums for this issue? Are you utilizing any other software besides Xcode? Are you using Objective-C with empty names in the metadata? To identify the binaries with those conditions, you can run the following Terminal command on each binary inside the app: ‘% xcrun dyld_info -objc Payload/YourApp.app/YourApp | grep (null)”’ Can you check the build log in Xcode and provide me with those messages including the warnings are really important and may give us a clue. Can you share those warnings? Additionally, could you please share the Xcode version, the minimum operating system requirements, and any relevant build settings that may be pertinent to this task? I eagerly anticipate your responses to guide you toward a comprehensive resolution for this matter, provided the script yields favorable outcomes. Otherwise if is not the issue I am thinking with Objective-C, please get it touch with App Store Connect support as they’ll have the reason the binary is i

Thanks for the post. Very interesting. My 5 cents if I may. It is crucial to prioritize user experience by ensuring consistency and stability in production environments. This is why feature flags, such as UIDesignRequiresCompatibility, are typically controlled by developers rather than end-users and are not exposed for arbitrary user-based toggling in production builds. This key allows developers to test the feature but does not provide a way to deploy it as it can be turned off, as explained in the documentation. Therefore, developers should refrain from rolling out new designs broadly before testing them thoroughly. Controlled feature flags enable developers to incrementally roll out new designs to ensure stability. By monitoring feedback and performance, developers can address issues before a full deployment. Apps submitted to the App Store should not contain hidden features or debugging options that alter the intended user experience for the general public. In development, set up different build

Hi @Umeki, To enable all the technologies and access all the signals Apple has made available to comply with regional age assurance requirements, starting with Texas, you must build your app against the iOS 26.2 and iPadOS 26.2 SDKs and later, with Xcode 26.2 (17C52) and later. To view the latest Xcode versions and SDKs, see here. As of iOS 26.2 and iPadOS 26.2, age assurance includes the following signals: Declared Age Range API — Determine whether a person using your app is in an applicable region that requires additional age-related obligations. When a child account, or their parent or guardian, chooses to share age information, the Declared Age Range API will return the age band or age category, depending on legal requirements in the region. The API will also provide information about the method used to confirm the age band or category, whether parental controls are enabled, and whether the user is eligible for age gated features. For more details, see the following documentation: AgeRangeService

Hi @skitudeiosdevelopers, You wrote: [...] What is the correct and Apple-approved approach for handling age verification and restricting access for minor users on iOS versions prior to 26, given that the Declared Age Range API is not available on those systems? To enable all the technologies and access all the signals Apple has made available to comply with regional age assurance requirements, starting with Texas, you must build your app against, you must build your app against iOS 26.2 and iPadOS 26.2 SDKs with Xcode 26.2 (17C52). View the latest Xcode versions and SDKs here. Existing adult accounts and child accounts for kids and teens will not be affected. To learn more, see Next steps for apps distributed in Texas. Cheers, Paris X Pinkney |  WWDR | DTS Engineer

What is not clear is what actually happens after that date. My understanding is that you will not be able to submit a new release, but they don't tell the app will be blocked. So I fear it is case B. That's how I interpreted, to be on the safe side. if you can't provide a new build yet In fact, there is no need to develop a new version. You can simply re-archive the former version of the app with incremented build and version numbers, complete age ratings information and then submit with this new build. In the what's new field of AppStoreConnect, simply say: minor bug fixes. Given the many times this question is raised on the forum and how much it worries developers, it would be great to have a comprehensive answer from Apple.

Thanks for the post and the details, the error is not about having the latest version of Xcode, looks like you do have it as Xcode Version 26.2 (17C52). The error message you're encountering, ITMS-90426: Invalid Swift Support - The SwiftSupport folder is missing., indicates that your app submission to App Store Connect is missing a required folder named SwiftSupport. So this is extremely interesting to me for sure. When archiving your app, ensure there are no build warnings about folders. Go to > , and then check the Organizer to ensure everything is correctly packaged. If your app uses Swift Package Manager, ensure that all packages are updated and correctly integrated. Sometimes issues arise from improperly configured packages? I believe this issue is always about packages you are using. Can you check that? read until the end where a post from an Apple engineer will give you more information. If you're manually managing your app bundle, ensure the folder is present in the archive's structure. It

Also the email gives the impression, that you could update the age ratings for existing Apps. But this is not possible. You can do this only for new builds. And if you can't provide a new build yet, you wonder what would happen. It should be also possible to update the age rating without submitting a new build. Some Apps (like games) just do not require an update.

UPDATE: the TestFlight build had expired. I have a second Mac, and before updating, I checked the application with the network system extension. The TestFlight build had expired. When I updated to macOS 26.2, networking was dead. (Again, deleting the app resolved the problem).

Thank you for your responses and comments. It appears after reading so many people getting that in Xcode 26.2 that there is an issue in the latest build released, as I understand from your feedback. I have not been able to reproduce the issue myself, but this indicates that I have more work to do today to determine the steps to reproduce the problem using the latest Xcode 26.2 release with the simulator. I appreciate your assistance in providing this information. I have the FB number and will provide the engineering team with all the details from this thread after I have summarized everyone’s input. Albert Pascual
  Worldwide Developer Relations.

Just checked new Xcode 26.2 with iOS 26.2 and the debug builds startup time indeed improved significantly. We still have ~7 seconds of initial sluggishness (difference between debug executable on/off), but it's way better than it was before! 👍 While I appreciate the movement in the right direction, this still represents a substantial regression from the prior baseline, ~1s in Xcode 16. A reduction in severity isn’t a resolution. If Xcode is to remain viable for professional workflows, startup and initial responsiveness need to return to the Xcode 16 baseline.