xcode github

Ok, I found this in dmesg/syslog: [46147.634755]: DriverKitSampleA[6170] triggered unnest of range 0x1fc000000->0x1fe000000 of DYLD shared region in VM map 0x853f7106fc70fc7d. While not abnormal for debuggers, this increases system memory footprint until the target exits. [46147.634762]: DriverKitSampleA[6170] triggered unnest of range 0x1fe000000->0x200000000 of DYLD shared region in VM map 0x853f7106fc70fc7d. While not abnormal for debuggers, this increases system memory footprint until the target exits. [46148.219526]: Sandbox: ContextStoreAgent(448) allow file-read-data /Users/daniel/Library/Developer/Xcode/DerivedData/DriverKitUserClientSample-haxyygamobxzqybcidlsjqhbccev/Build/Products/Debug/DriverKitSampleApp.appSandbox: ContextStoreAgent(448) allow file-read-data /Users/daniel/Library/Developer/Xcode/DerivedData/DriverKitUserClientSample-haxyygamobxzqybcidlsjqhbccev/Build/Products/Debug/DriverKitSampleApp.app/ContentsSandbox: ContextStoreAgent(448) allow file-read-data /Users/d

Thank you for sharing the post. This appears to be a coredevice issue to me. Have you filed a bug report? You should update your Xcode version to the latest version as well as you macOS. If still happening on the latest version, please file a bug: Once you open the bug report, please post the FB number here for my reference. If you have any questions about filing a bug report, take a look at Bug Reporting: How and Why? Albert Pascual
  Worldwide Developer Relations.

This is good news, but why is an update of iOS required ? Does this mean that the debugging experience on all iOS versions below 26.2 will not be fixed ? It was working fine with Xcode 16 on all iOS versions, so this is not an iOS bug.

Hi, we need some more diagnostics to be able to help you with this. Could you please file a feedback request and post the number here so we can examine the logs? Be sure to include your team ID and the link to the build also. You can file Xcode Cloud specific feedback using these steps.

Could you please share where isEligibleForAgeFeatures is placed in - there is no such property in AgeRangeService.shared in Xcode 26.2.0-Beta. The isEligibleForAgeFeatures is available when using Xcode 26.2 beta 2 (17C5038g). To view the version of Xcode, select Xcode > About Xcode. do { let response = try await AgeRangeService.shared.isEligibleForAgeFeatures // Handle response if response { logger.info(Eligible for age features.) } else { logger.info( Not eligible for age features.) } } catch { logger.error(Fail to check eligibility for age features.) }

To update an old issue - without any project changes on my end, but with several Xcode upgrades, this stopped happening. I don't know the exact Xcode version when it stopped.

Hello, you could build an app with a min target deployment of iOS 12 in Xcode 26, but that’s not recommended. As you correctly noted, you won’t be able to test your app in the simulator or on a device with Xcode. Is there a specific reason you want to target iOS 12? According to https://developer.apple.com/support/app-store/ , the vast majority of users are running a more recent version of iOS.

A quick update. Based on the work so far in FB20939056 it seems that my analysis of the issue was pretty solid. iOS 26 was specifically changed to allow the type mismatch between the entitlement claim and the provisioning profile authorisation (r. 152513118). That fix is not in iOS 18, and hence the app doesn’t run. Curiously, if you deploy this to the App Store it should run on iOS 18, because App Store apps are re-signed by Apple and thus don’t need a provisioning profile to authorise their entitlement claims. Of course that’s a risky option. The standard way to mitigate such risks is with TestFlight. I haven’t tried this there. My best guess is that it’ll fail in the same way, but I wouldn’t be surprised if it worked. My understanding of the provisioning machinery for TestFlight is not as good on iOS and it is on macOS. If you try this, please reply here to let me know if it worked or not. On obvious, albeit clunky, workaround is to remove the capability when running on iOS 18 devices and add it back when

Thanks for the replay @DTS Engineer. You are right on my requirement, currently I am looking for iOS but I would be happy with a solution that works across apple platforms as well. If so, to what end? To answer your query on why I want to detect debug build I won't be able to share my exact use-case but I will share a parallel use-case that currently Apple uses: Currently Apple allows developers to send push notifications to iOS with APNS. From what I understand, APNS exposes sandbox and production environments which are controlled with aps-environment entitlement. Since, Apple controls the tooling side of iOS development, they can inject entitlement based on the provisioning profile. I want to achieve something similar to this where the REST API domain used by my framework is decided based on either provisioning profile or build type. A lot of the time it’s not the build configuration that matters, it’s the way that the app was signed. Or the way that’s it’s run (from Xcode or like a user would).