In the last three betas of Xcode 26, opening XIB files that rely on the older struts-and-springs setup (rather than Auto Layout) has exposed a new problem: Xcode 26 ignore the difference between a view’s frame and alignment rectangle. If you had arranged views using their frame rectangle (the default for the old method) this causes two problems: All UI widgets are both larger and no longer aligned. Switching between frame and alignment rectangles while configuring any NSView (through the inspector setting) has no effect. Is anyone else seeing this? It’s one thing to convert a few smaller views to Auto-layout (its reliance on alignment rectangles makes it immune to the "death" of frame rectangle-based layout) it is a rather different task to re-layout thousands of UI widgets as a result of this one bug. Filed as FB18835363

Xcode 16 insists on showing deprecations of this type: Some.xib SF Symbol 'doc.on.doc' is deprecated, use 'document.on.document' instead. The problem is that the XIBs in question are set with a Deployment Target of macOS 12, where "document.on.document" actually isn't available and produces a missing image. So the warnings are wrong, as they ignore the deployment target set on the XIB. I filed a bug against this long ago and it was ignored. Having given up... does anyone know how to disable this particular warning?

FxPlug is one of Apple’s official SDKs, recently updated to version 4.3.2. In theory the SDK should guarantee third-parties can build plug-ins that are backward compatible with older versions of Final Cut Pro, Motion and Compressor. FxPlug SDK includes two frameworks that third-party developers like me end up bundling inside our third-party plugins: FxPlug.framework and PlugInManager.framework. Behind the scenes, the SDK relies on PlugInKit, but the FxPlug.framework provides abstractions so that third-parties don't have to handle the intricacies of XPC directly. The most recent version of FxPlug.framework included with the SDK was possibly built with an error: the Info.plist shows a LSMinimumSystemVersion entry of 14.6, suggesting the binary may have been compiled and linked with MACOSX_DEPLOYMENT_TARGET set to 14.6 by accident. The problem: when older versions of Final Cut Pro or Motion load a third-party plugin (itself built with the appropriate deployment target, macOS 11 or 12, for example) on pre-macOS 14.6, the dynamic linker immediately loads Apple’s own FxPlug.framework, but this causes the process to crash immediately: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x7ff81e065955 map_images_nolock + 5399 1 libobjc.A.dylib 0x7ff81e0643d6 map_images + 67 2 dyld 0x10bd551fb invocation function for block in dyld4::RuntimeState::setObjCNotifiers(void (*)(unsigned int, char const* const*, mach_header const* const*), void (*)(char const*, mach_header const*), void (*)(char const*, mach_header const*)) + 275 3 dyld 0x10bd506c9 dyld4::RuntimeState::withLoadersReadLock(void () block_pointer) + 41 4 dyld 0x10bd550e2 dyld4::RuntimeState::setObjCNotifiers(void (*)(unsigned int, char const* const*, mach_header const* const*), void (*)(char const*, mach_header const*), void (*)(char const*, mach_header const*)) + 82 5 dyld 0x10bd68d45 dyld4::APIs::_dyld_objc_notify_register(void (*)(unsigned int, char const* const*, mach_header const* const*), void (*)(char const*, mach_header const*), void (*)(char const*, mach_header const*)) + 79 6 libobjc.A.dylib 0x7ff81e064244 _objc_init + 1279 7 libdispatch.dylib 0x7ff81e01d993 _os_object_init + 13 8 libdispatch.dylib 0x7ff81e02b1b8 libdispatch_init + 311 9 libSystem.B.dylib 0x7ff828fd585f libSystem_initializer + 238 10 dyld 0x10bd5ae4f invocation function for block in dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const + 182 11 dyld 0x10bd81aad invocation function for block in dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const + 242 12 dyld 0x10bd78e26 invocation function for block in dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const + 557 13 dyld 0x10bd47db3 dyld3::MachOFile::forEachLoadCommand(Diagnostics&, void (load_command const*, bool&) block_pointer) const + 129 14 dyld 0x10bd78bb7 dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const + 179 15 dyld 0x10bd81604 dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const + 466 16 dyld 0x10bd5ad82 dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const + 144 17 dyld 0x10bd6165a dyld4::PrebuiltLoader::runInitializers(dyld4::RuntimeState&) const + 30 18 dyld 0x10bd6e76e dyld4::APIs::runAllInitializersForMain() + 38 19 dyld 0x10bd4c38d dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*) + 3443 20 dyld 0x10bd4b4e4 start + 388 Can someone at Apple with the right domain expertise confirm that this is the type of crash you would see because the framework was built assuming it would run on macOS 14.6 and later, and when facing an older environment (e.g. ObjC runtime) it lacks extra code that would ensure backward compatibility with the earlier ObjC runtime found on macOS 12.x?

I've noticed a major third-party app has the following flag set to 1/true in its Info.plist: CAMetalLayerWantsCompositingDependencies Does anyone know if it’s recognized by Core Animation / Metal, and what it’s supposed to do? It might obviously have zero relationship to the OS, defined by that app and for that app... but since it looks very much like an unofficial/undocumented environment setting, it might be great to know what problem it solves. I happen to have issues related to compositing other CALayers over a CAMetalLayer in my app... so this definitely stood out as interesting. Thank you!

Does anyone know if any Apple Open Source repository would contain the source code to NSStringFromSelector? TSAN has pointed out an issue in my code that stems from assuming that the value returned by NSStringFromSelector is immutable, and that the function itself is re-entrant. I’d like to check both those assumptions against the actual sources... assuming they haven't changed in macOS Sequoia to begin with.

I'm investigating an odd problem that surfaced with macOS Sequoia related to CoreGraphics (CGColorSpaceCreateWithICCData()). I couldn't find a reliable way to track the lifetime (retain/releases) of a CGColorSpaceRef (any pointers appreciated) so I was hoping to use objc_setAssociatedObject() to attach an instance of my own class that would be deallocated when the "owning" CGColorSpaceRef is deallocated. In this way I could set a breakpoint on my own code, presumably invoked when the CGColorSpaceRef is itself going away. While objc_setAssociatedObject() does seem to work, the results don't seem deterministic. Is it because objc_setAssociatedObject() simply won't work reliably with CF types?

This is both a heads up and an invitation for anyone affected by this to file feedback. All betas of Xcode 16, up to beta 4, will crash when you attempt to view the Build Settings for any target that happens to have a Build Carbon Resources phase. Any lucky soul who is still dealing with Rez, please make sure to file feedback to try and have this issue solved.

I'm having a hard time relying on TSAN to detect problems due to its rightful insistence on reporting data-races (I know, stick with me). Picture the following implementation of a lazily-allocated property in an Obj-C class: @interface MyClass { id _myLazyValue; // starts as nil as all other Obj-C ivars } @end @implementation MyClass - (id)myLazyValue { if (_myLazyValue == nil) { @synchronized(self) { if (_myLazyValue == nil) { _myLazyValue = <expensive computation> } } } return _myLazyValue; } @end The first line in the method is reading a pointer-sized chunk of memory outside of the protection provided by the @synchronized(...) statement. That same value may be written by a different thread within the execution of the @synchronized block. This is what TSAN complains about, but I need it not to. The code above ensures the ivar is written by at most one thread. The read is unguarded, but it is impossible for any thread to read a non-nil value back that is invalid, uninitialized or unretained. Why go through this trouble? Such a lazily-allocated property usually locks on @synchronized once, until (at most) one thread does any work. Other threads may be temporarily waiting on the same lock but again only while the value is being initialized. The cost of allocation and initialization is guaranteed to be paid once: multiple threads cannot initialize the value multiple times (that’s the reason for the second _myLazyValue == nil check within the scope of the @synchronized block). Subsequent accesses of the initialized property skip locking altogether, which is exactly the performance we want from a lazily-allocated, immutable property that still guarantees thread-safe access. Assuming there isn't a big embarrassing hole in my logic, is there a way to decorate specific portions of our sources (akin to #pragma statements that disable certain warnings) so that you can mark any read/write access to a specific value as "safe"? Is the most granular tool for this purpose the __attribute__((no_sanitize("thread")))? Ideally one would want to ask TSAN to ignore only specific read/writes, rather than the entire body of a function. Thank you!

Having just downloaded the newly posted Xcode 15 Beta 3, it shows an "Apple Internal" badge on the debugging/console toolbar. The Dock icon spells the build number. Anyone else seeing the same? Has this been rectified on the developer Downloads section?

Xcode 15 warns you when targets contain a Build Carbon Resources phase. The solution is to drag all your .r files to the Copy Bundle Resources phase instead, and deleting the now-empty Build Carbon Resources phase. Beware that after this change your project is unlikely to build correctly with Xcode 14. While both versions of Xcode support .r files in the Copy Bundle Resources phase, invoking Rez to compile your inputs, Xcode 14 incorrectly outputs a .rsrc file whose name matches the input .r file (MyResources.r → MyResources.rsrc). This is wrong, since the Carbon Resource Manager recognizes only one file containing Carbon resources (AFAIK) and its name must match the bundle executable. If your executable is named Foo, your Carbon resources should be in a Foo.rsrc file or else they will be ignored. It is unclear if Xcode 15 is smart enough to merge the output of multiple .r files into a single .rsrc. Lucky me I don't need that functionality for my targets but it's something else to look out for. ...and for those in utter disbelief that in 2023 there are still people talking about and using Carbon Resources as designed and implemented in the 80s... welcome to the world of third-party plug-ins for Adobe apps ;-)

Offering this here for those who may run into the same issue... There is more than one reason you may get the following error message when attempting to build your targets: Cycle inside ...; building could produce unreliable results But if you just switched to Xcode 15 and you are currently customizing DSTROOT to set the root install location for the deliverables (app, bundle, etc) built by your Target, Xcode 15 will refuse to build any target with dependencies on other targets that use the same underlying configuration. There is obviously no real cycle: Xcode 15 is just confused by both targets sharing the same DSTROOT. For example, if you set up your projects with: DSTROOT=/ INSTALL_PATH=/Applications (notice that DSTROOT=/ is even mentioned in the docs) Xcode will wrongfully detect a circular dependency as both targets share the build destination and thus refuse to build. The solution is to not customize DSTROOT, thus allowing it to have a directory name that is target-dependent and thus fairly immune to collisions. Instead, customize the INSTALL_ROOT setting. While this setting does not appear in the Build Phases tab, it defaults to reusing the DSTROOT value. If you set it explicitly, it allows DSTROOT to remain for other purposes, while using the value of INSTALL_ROOT to deploy your deliverables: INSTALL_ROOT=/ INSTALL_PATH=/Applications This allows the build system to proceed without errors.

Is anyone else seeing that Xcode 13.2 no longer creates a single default.metallib that combines all *.air files together? (Seeing this with a framework target, at least.) Nothing in the release notes suggests this change... so for now a custom script like the following seems needed: if [ ! -d "${METAL_LIBRARY_OUTPUT_DIR}"/default.metallib ]; then      xcrun -sdk macosx metallib "${TARGET_TEMP_DIR}"/Metal/*.air -o "${METAL_LIBRARY_OUTPUT_DIR}"/default.metallib fi; Would be grateful to know if this is a bug or an intended change in the toolchain. Thanks!

Does anyone know why it is impossible to enable/test Private Relay even with an Apple One Premier subscription? Wouldn't it make sense that during the macOS Beta all users would be able to turn in on? This feature looks good on paper but the barrier to testing makes no sense. Any help greatly appreciated.

The Xcode 13 Beta (1 & 2) is showing some serious performance regressions when building our large project, and wondering if others are noticing the same. If you Build again after a build had just completed, Xcode 13 redoes a ton of work, as visible through the thousands of tasks it takes on. It's as if Xcode 13 lost the ability to skip unnecessary work. Building again in Xcode 12 does incur a small penalty too, but the difference is between 2-3 seconds (Xcode 12) vs 1-2 minutes (Xcode 13). ...and as a side note, the new progress reporter is useless: it switches from reporting progress for one set of tasks (1928/3022 completed) to a completely different set of tasks (444/1255 completed). You never know which "set of tasks" is the last you'll need for the build process as a whole to be done. Any idea why it doesn't display cumulative progress? Thanks!

We have a non-sandboxed app that uses a custom URL scheme to allow redirection of certain tasks from Safari to our app, when installed, and with permission from the user. In the latest Beta of Safari 14 on macOS Big Sur Beta, Safari launches our app in its own Sandbox Container. This obviously breaks our software, which expects and requires a "normal" environment. This is a regression in Safari. It still asks for permission before opening every single custom URL. Users still have to install our notarized software beforehand on their systems in order to access these custom URLs. I tried filing a bug. Tried a DTS ticket. No reply to either. Does anyone know of this problem, and know of a workaround? Our software obviously cannot escape Safari’s sandbox container. At best we can detect it, right now, but our software is broken 😫 For the record, if the user launches our app *before* attempting to open the custom URL, then Safari is more than happy to pass along the URL to the running instance of our software (which is great). But if Safari has to launch our app in order to process the custom URL, our app lives within the confines of Safari’s container.