Xcode

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

Thanks for those bug reports. Using them I was able to track down the lead bug for this (r. 162628085). AFAICT this isn’t fixed in any shipping or seeded version of Xcode, up to and including the current Xcode 26.2b2 (17C5038g). However, as always, I encourage you to re-test with new seeds as they’re released. In the meantime, it’s possible that you might be able to work around this crash by pass absolute paths, rather than relative paths, to xcresulttool. Please try this and lemme know how you get along. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

@SkiDev81 Hello, have you found a solution to your SSH connection issue with Azure in Xcode ? have you tried using Azure Git Credentials for the https solution ?

I tried this here in my office and didn’t see any leaks or unbounded memory growth. Here’s what I did: Using Xcode 26.1 on macOS 15.7.1 [1], I created a new project from the macOS > Command Line Tool template. I then added a dynamic library target to that. I populated them with the code shown at the end of this post. I build both targets using Xcode. I then ran the tool from Terminal: % ./Test806035 will run will open and close, iteration: 0 did close and close … will open and close, iteration: 999 did close and close did run, press return to loop, pid: 47371 In other Terminal window, I rans leaks against the process. It showed no leaks. I ran heap against the process: % heap Test806035 … COUNT BYTES AVG CLASS_NAME TYPE BINARY ===== ===== === ========== ==== ====== 134 4288 32.0 Class.data (class_rw_t) C libobjc.A.dylib 27 11360 420.7 non-object 5 512 102.4 xpc_string_t (Storage) C libxpc.dylib 5 256 51.2 xpc_dictionary_t (Storage) C libxpc.dylib 5 240 48.0 xpc_string_t ObjC libxpc.dylib

DTS Engineer Apple Use isEligibleForAgeFeatures to determine whether a person using your app is in an applicable region ... Hi, thank you for information. Could you please share where isEligibleForAgeFeatures is placed in - there is no such property in AgeRangeService.shared in Xcode 26.2.0-Beta. Google doesn't know anything at all about it. Thank you.

This works if you’re using a macOS 15 (or later) guest on a macOS 15 (or later) host [1]. It won’t work for a macOS 14 guest, regardless of the host. In Virtualization Resources you’ll find a bunch of links to resources related to virtualisation for developers, including links to: The Apple Support article that describes the limitations of Apple Account support in the guest. A forums thread that talks about the same. And another forums thread about getting Xcode working in the guest. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] To be clear, the guest must have been created on a macOS 15 host. It won’t work if you: Create the guest on a macOS 14 host and then move it a macOS 15 host Or create the guest on a macOS 14 host and then upgrade your host to macOS 15

[quote='807924021, SoumyaMahunt, /thread/807924, /profile/SoumyaMahunt'] Is this approach reliable? [/quote] No. You can disable preview support using a build settings, even in the Debug build configuration. Indeed, that’s something I do all the time. Lemme confirm I understand your requirements: You’re working on a framework. You want to create an XCFramemwork from that. And give that XCFramework to other developers. And then inside that framework you want to check whether the host app was built with the Debug build configuration. Is that right? If so, to what end? And are you sure that you want to check the build configuration? 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). And those questions have different answers. Is this iOS? Or macOS? Or both? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com