Post

Replies

Boosts

Views

Activity

Reply to Can an ExtensionFoundation-based extension on macOS have its own extension point and host its own extensions?
Thanks Quinn, I'll file that enhancement request next. The scenario I painted is the following: our visual effects are hosted as an FxPlug (PlugInKit) in Final Cut Pro, Motion and Compressor – I presume maybe incorrectly that PlugInKit is sitting on top of ExtensionKit, but it is certainly based on NSXPC so our plugin sits outside Apple’s video apps. Our visual effects are based on FxCore (https://fxfactory.com/info/fxcore/), a replacement for Quartz Composer. Just like QC, it is an application and framework combo, with its own plugin SDK waiting to be made public. I wanted to use FoundationExtension/Kit because it seems like a better idea than loading random bundles in my own address space. Hopefully in the future!
Sep ’26
Reply to PrivilegedHelperTool no longer launches automatically after SMJobBless to SMAppService
As it happens, shortly after posting I had a hunch that the com.apple.developer.service-management.managed-by-main-app entitlement may not be needed at all. That entitlement features on the GitHub repo LLMs are likely training on: https://github.com/malpern/privileged_helper_help/tree/main The .developer suffix hints that this would only be needed during development, but my best guess is that the fact that my main app uses a provisioning profile in both Debug and Release configuration somehow plays a role. Either way, removing that entitlement from the Helper tool suddenly allowed the connection to be started automatically. It would be great to know the answers to the other questions, since trial-and-error sometimes leads to half-truths: In addition to having the launchd plist that describes the helper tool copied to /Contents/Library/LaunchDaemons, should the same plist also be embedded by the helper tool binary via -sectcreate __TEXT __launchd_plist? Would this requirement, if it exists, be true for all versions of macOS where SMAppService is now available (13 > 27)? Is it true that XPC_CONNECTION_MACH_SERVICE_PRIVILEGED should be omitted when creating the client connection, if the helper tool is managed via SMAppService API? My current working version has it, but if the LLM’s claim of its obsolescence is true, is this something that might break in previous/future versions of macOS, for example? If one needs these LaunchDaemons to perform some actions with root privileges, what exactly would enabling the App Sandbox (com.apple.security.app-sandbox = true) on the privileged helper tool accomplish? Is there any point in confining a process with root privileges inside a container?
Aug ’26
Reply to Xcode 26 Beta 5 XIB Compiler outputs NIBs with dependency on class that isn't available pre-macOS 26
@bdkjones Filed bug, even used one of my tech support incidents, heard nothing back yet. Your best bet right now is to find an Intel Mac capable of running macOS 15.6 and Xcode 26 Beta 5. When XIBs are compiled to NIBs on those, no unwanted dependency is injected into the output. There is a possibility the workaround doesn't really depend on using an Intel Mac. It could be the key is simply to compile on macOS 15 rather than 26. I just haven't bothered to try because one method to save the day was all I needed. We already "volunteer" so much of our time helping Apple with their yearly release cycle. If you have success on Apple silicon + macOS 15, please let us know.
Aug ’25
Reply to Xcode 26 Beta 5 XIB Compiler outputs NIBs with dependency on class that isn't available pre-macOS 26
@elemans Downgrading to Xcode 16.4 does eliminate the dependency on NSScrollPocket. Is this a viable workaround? For some, perhaps. Apple has created an undesirable situation where the new macOS 26-specific .icon files edited via Icon Composer are only understood and compiled to the Assets catalog (and legacy .icns files to back-deploy) by Xcode 26. Downgrading to Xcode 16.x means you can't output a macOS 26 app with new icons for the macOS 26 Public Beta they feel compelled to release (bad idea) and you lose what very little progress has been made in the macOS SDK regarding @Sendable conformance annotations in a handful of frameworks. So you’re back to adding @retroactive @unchecked Sendable statements and cursing that other mess that is Swift Concurrency. Xcode 16.5 also means downgrading to the macOS 15 SDK. In C/C++/Obj-C you can bracket statements that use symbols found only in the macOS 26 SDK with #if defined(MAC_OS_VERSION_26_0) but while Swift adds a new keyword per week, hell no #if os(...) doesn't support versions so it can't help in keeping the same code compilable against different versions of the same platform SDK 🤷‍♂️ The cumulative experience of developing native apps for macOS has never looked this uncoordinated. Good luck! Still hoping someone posts an incantation that magically gets rid of NSScrollPocket in the archived NIB.
Aug ’25
Reply to Xcode 26 Beta 5 XIB Compiler outputs NIBs with dependency on class that isn't available pre-macOS 26
Bad news... I downgraded to Xcode 26 Beta 4 hoping it would output NIBs that work pre-macOS 26, but it didn't. Not quite sure how this regression works, but it might be that the regression was there earlier, but the XIB must have some currently unknown characteristic to suffer from it. It could be that the editor itself is injecting this dependency during normal user actions, in a way that the XIB > NIB compilation cannot actually remove.
Aug ’25
Reply to Xcode 26 Beta 5 XIB Compiler outputs NIBs with dependency on class that isn't available pre-macOS 26
@elemans That checks out... all my affected XIBs have NSOutlineViews... but oddly enough I also have XIBs with NSOutlineViews that do not trigger the problem. Judging by the scoping on that class, this is someone playing with a Swift-based addition to AppKit that forgot how everything fits and works together (with tape and glue!)
Aug ’25
Reply to Xcode 26 Beta 5 XIB Compiler outputs NIBs with dependency on class that isn't available pre-macOS 26
Hi @elemans I am not loading a Storyboard so the error I see on the console is less verbose, and only mentions failure to instantiate that class: Could not instantiate class named _TtCC6AppKit14NSScrollPocketP33_EC3F85FAB7755D56E669206D2B17725B12BackdropView because no class named _TtCC6AppKit14NSScrollPocketP33_EC3F85FAB7755D56E669206D2B17725B12BackdropView was found; the class needs to be defined in source code or linked in from a library (ensure the class is part of the correct target) Time for both of us to file a bug. Update: filed as FB19530323
Aug ’25
Reply to Xcode 26 XIB ignores difference between NSView frame and alignment rectangles
If your NIBs already have auto-layout constraints, they will look and work OK on macOS 26. The problem I described only affects views that are laid out without any constraints, using the Autoresizing Mask, or Inferred (Autoresizing Mask). The issue is that for complex UI, the "old stuff" is really the only one that performs well both when making changes through the Xcode Editor, and at runtime.
Jul ’25
Reply to Xcode 26 XIB ignores difference between NSView frame and alignment rectangles
Posting this here as a summary for the three people left writing native macOS apps using AppKit, who might stumble here from a search. macOS 26 has brought us the yearly facelift that – as tradition – brings no break-through features or discernible improvement to usability (quite the opposite, this time around). This year’s diktat from Marketing has also brought a regression that affects how AppKit reconstructs and displays UIs in XIB/NIB files. (Haven't checked if this exists on UIKit too.) If you had carefully laid out your controls to be aligned without the assistance of auto-layout, reopening these files with Xcode 26 will show all controls to be misaligned. This same problem is sadly visible at runtime too. AppKit has removed the crucial distinction between frame rectangles and alignment rectangles. You would be spared from this problem only if your controls were participating in auto-layout by having at least one constraint, or by calling -[NSView setTranslatesAutoresizingMaskIntoConstraints:YES] and setting constraints programmatically. The most obvious solution is to slowly add constraints to all your XIBs. It makes sense if your app uses simpler view hierarchies. For complex hierarchies, auto-layout never was a viable option. The more constraints you add to your XIB the slower it becomes, until the point where adding a single widget or constraint will take seconds. Assuming they ship with this regression (still there as of Beta 4) the solution for large XIBs is to painfully realign and resize all controls while leaving them on the older springs-and-struts layout system. This luckily can still be done fast in Xcode. The downside? All your controls will look correct on macOS 26 but will be both misaligned and probably look too small on previous versions of macOS. For the latter problem you can thank the fact that they changed the size of controls so that a small button or popup menu on macOS 26 is taller and wider than on previous versions 🤷‍♂️ (my previous post was incorrect on this point) Here we are in 2025 with NextStep-era UI still being the only one you can preview and layout reliably both in Xcode and at runtime. They never allowed auto-layout to become great. Having used it both programmatically and visually, it's been left 90% done to make room for SwiftUI, now 6 years old and nowhere near usable without massive problems and frustration. I wouldn't be surprised if more apps switch to non-native UI frameworks just to stay away from this. Taking a step back from this particular regression, the broader picture is that Apple keeps externalizing upkeep costs to its third-party developers with a yearly facelift that feels more and more superficial, adding busywork to our schedule, forcing rewrites and redesigns, and bringing no rewards. Even if you jump through all of these hoops, your software gains no new features that might actually be considered valuable to users. Best of luck!
Jul ’25
Reply to Xcode 26 XIB ignores difference between NSView frame and alignment rectangles
This looks like a bug in AppKit... even if you manually re-adjust all your UI, this will only fix the appearance on macOS 26. On prior versions of macOS, many UI widgets will look smaller than they should be, all as a side effect of AppKit no longer interpreting frame rectangle vs alignment rectangle. Unclear if the fix would be to have the XIB compiler actually spit out the correct rectangles so as to maintain visual consistency with all versions of macOS.
Jul ’25
Reply to Can an ExtensionFoundation-based extension on macOS have its own extension point and host its own extensions?
Thanks Quinn, I'll file that enhancement request next. The scenario I painted is the following: our visual effects are hosted as an FxPlug (PlugInKit) in Final Cut Pro, Motion and Compressor – I presume maybe incorrectly that PlugInKit is sitting on top of ExtensionKit, but it is certainly based on NSXPC so our plugin sits outside Apple’s video apps. Our visual effects are based on FxCore (https://fxfactory.com/info/fxcore/), a replacement for Quartz Composer. Just like QC, it is an application and framework combo, with its own plugin SDK waiting to be made public. I wanted to use FoundationExtension/Kit because it seems like a better idea than loading random bundles in my own address space. Hopefully in the future!
Replies
Boosts
Views
Activity
Sep ’26
Reply to PrivilegedHelperTool no longer launches automatically after SMJobBless to SMAppService
As it happens, shortly after posting I had a hunch that the com.apple.developer.service-management.managed-by-main-app entitlement may not be needed at all. That entitlement features on the GitHub repo LLMs are likely training on: https://github.com/malpern/privileged_helper_help/tree/main The .developer suffix hints that this would only be needed during development, but my best guess is that the fact that my main app uses a provisioning profile in both Debug and Release configuration somehow plays a role. Either way, removing that entitlement from the Helper tool suddenly allowed the connection to be started automatically. It would be great to know the answers to the other questions, since trial-and-error sometimes leads to half-truths: In addition to having the launchd plist that describes the helper tool copied to /Contents/Library/LaunchDaemons, should the same plist also be embedded by the helper tool binary via -sectcreate __TEXT __launchd_plist? Would this requirement, if it exists, be true for all versions of macOS where SMAppService is now available (13 > 27)? Is it true that XPC_CONNECTION_MACH_SERVICE_PRIVILEGED should be omitted when creating the client connection, if the helper tool is managed via SMAppService API? My current working version has it, but if the LLM’s claim of its obsolescence is true, is this something that might break in previous/future versions of macOS, for example? If one needs these LaunchDaemons to perform some actions with root privileges, what exactly would enabling the App Sandbox (com.apple.security.app-sandbox = true) on the privileged helper tool accomplish? Is there any point in confining a process with root privileges inside a container?
Replies
Boosts
Views
Activity
Aug ’26
Reply to Xcode 26 Beta 5 XIB Compiler outputs NIBs with dependency on class that isn't available pre-macOS 26
@bdkjones Filed bug, even used one of my tech support incidents, heard nothing back yet. Your best bet right now is to find an Intel Mac capable of running macOS 15.6 and Xcode 26 Beta 5. When XIBs are compiled to NIBs on those, no unwanted dependency is injected into the output. There is a possibility the workaround doesn't really depend on using an Intel Mac. It could be the key is simply to compile on macOS 15 rather than 26. I just haven't bothered to try because one method to save the day was all I needed. We already "volunteer" so much of our time helping Apple with their yearly release cycle. If you have success on Apple silicon + macOS 15, please let us know.
Replies
Boosts
Views
Activity
Aug ’25
Reply to Xcode 26 Beta 5 XIB Compiler outputs NIBs with dependency on class that isn't available pre-macOS 26
@elemans Downgrading to Xcode 16.4 does eliminate the dependency on NSScrollPocket. Is this a viable workaround? For some, perhaps. Apple has created an undesirable situation where the new macOS 26-specific .icon files edited via Icon Composer are only understood and compiled to the Assets catalog (and legacy .icns files to back-deploy) by Xcode 26. Downgrading to Xcode 16.x means you can't output a macOS 26 app with new icons for the macOS 26 Public Beta they feel compelled to release (bad idea) and you lose what very little progress has been made in the macOS SDK regarding @Sendable conformance annotations in a handful of frameworks. So you’re back to adding @retroactive @unchecked Sendable statements and cursing that other mess that is Swift Concurrency. Xcode 16.5 also means downgrading to the macOS 15 SDK. In C/C++/Obj-C you can bracket statements that use symbols found only in the macOS 26 SDK with #if defined(MAC_OS_VERSION_26_0) but while Swift adds a new keyword per week, hell no #if os(...) doesn't support versions so it can't help in keeping the same code compilable against different versions of the same platform SDK 🤷‍♂️ The cumulative experience of developing native apps for macOS has never looked this uncoordinated. Good luck! Still hoping someone posts an incantation that magically gets rid of NSScrollPocket in the archived NIB.
Replies
Boosts
Views
Activity
Aug ’25
Reply to Xcode 26 Beta 5 XIB Compiler outputs NIBs with dependency on class that isn't available pre-macOS 26
Bad news... I downgraded to Xcode 26 Beta 4 hoping it would output NIBs that work pre-macOS 26, but it didn't. Not quite sure how this regression works, but it might be that the regression was there earlier, but the XIB must have some currently unknown characteristic to suffer from it. It could be that the editor itself is injecting this dependency during normal user actions, in a way that the XIB > NIB compilation cannot actually remove.
Replies
Boosts
Views
Activity
Aug ’25
Reply to Xcode 26 Beta 5 XIB Compiler outputs NIBs with dependency on class that isn't available pre-macOS 26
@elemans That checks out... all my affected XIBs have NSOutlineViews... but oddly enough I also have XIBs with NSOutlineViews that do not trigger the problem. Judging by the scoping on that class, this is someone playing with a Swift-based addition to AppKit that forgot how everything fits and works together (with tape and glue!)
Replies
Boosts
Views
Activity
Aug ’25
Reply to Xcode 26 Beta 5 XIB Compiler outputs NIBs with dependency on class that isn't available pre-macOS 26
Hi @elemans I am not loading a Storyboard so the error I see on the console is less verbose, and only mentions failure to instantiate that class: Could not instantiate class named _TtCC6AppKit14NSScrollPocketP33_EC3F85FAB7755D56E669206D2B17725B12BackdropView because no class named _TtCC6AppKit14NSScrollPocketP33_EC3F85FAB7755D56E669206D2B17725B12BackdropView was found; the class needs to be defined in source code or linked in from a library (ensure the class is part of the correct target) Time for both of us to file a bug. Update: filed as FB19530323
Replies
Boosts
Views
Activity
Aug ’25
Reply to Xcode 26 XIB ignores difference between NSView frame and alignment rectangles
If your NIBs already have auto-layout constraints, they will look and work OK on macOS 26. The problem I described only affects views that are laid out without any constraints, using the Autoresizing Mask, or Inferred (Autoresizing Mask). The issue is that for complex UI, the "old stuff" is really the only one that performs well both when making changes through the Xcode Editor, and at runtime.
Replies
Boosts
Views
Activity
Jul ’25
Reply to Xcode 26 XIB ignores difference between NSView frame and alignment rectangles
Posting this here as a summary for the three people left writing native macOS apps using AppKit, who might stumble here from a search. macOS 26 has brought us the yearly facelift that – as tradition – brings no break-through features or discernible improvement to usability (quite the opposite, this time around). This year’s diktat from Marketing has also brought a regression that affects how AppKit reconstructs and displays UIs in XIB/NIB files. (Haven't checked if this exists on UIKit too.) If you had carefully laid out your controls to be aligned without the assistance of auto-layout, reopening these files with Xcode 26 will show all controls to be misaligned. This same problem is sadly visible at runtime too. AppKit has removed the crucial distinction between frame rectangles and alignment rectangles. You would be spared from this problem only if your controls were participating in auto-layout by having at least one constraint, or by calling -[NSView setTranslatesAutoresizingMaskIntoConstraints:YES] and setting constraints programmatically. The most obvious solution is to slowly add constraints to all your XIBs. It makes sense if your app uses simpler view hierarchies. For complex hierarchies, auto-layout never was a viable option. The more constraints you add to your XIB the slower it becomes, until the point where adding a single widget or constraint will take seconds. Assuming they ship with this regression (still there as of Beta 4) the solution for large XIBs is to painfully realign and resize all controls while leaving them on the older springs-and-struts layout system. This luckily can still be done fast in Xcode. The downside? All your controls will look correct on macOS 26 but will be both misaligned and probably look too small on previous versions of macOS. For the latter problem you can thank the fact that they changed the size of controls so that a small button or popup menu on macOS 26 is taller and wider than on previous versions 🤷‍♂️ (my previous post was incorrect on this point) Here we are in 2025 with NextStep-era UI still being the only one you can preview and layout reliably both in Xcode and at runtime. They never allowed auto-layout to become great. Having used it both programmatically and visually, it's been left 90% done to make room for SwiftUI, now 6 years old and nowhere near usable without massive problems and frustration. I wouldn't be surprised if more apps switch to non-native UI frameworks just to stay away from this. Taking a step back from this particular regression, the broader picture is that Apple keeps externalizing upkeep costs to its third-party developers with a yearly facelift that feels more and more superficial, adding busywork to our schedule, forcing rewrites and redesigns, and bringing no rewards. Even if you jump through all of these hoops, your software gains no new features that might actually be considered valuable to users. Best of luck!
Replies
Boosts
Views
Activity
Jul ’25
Reply to Xcode 26 XIB ignores difference between NSView frame and alignment rectangles
This looks like a bug in AppKit... even if you manually re-adjust all your UI, this will only fix the appearance on macOS 26. On prior versions of macOS, many UI widgets will look smaller than they should be, all as a side effect of AppKit no longer interpreting frame rectangle vs alignment rectangle. Unclear if the fix would be to have the XIB compiler actually spit out the correct rectangles so as to maintain visual consistency with all versions of macOS.
Replies
Boosts
Views
Activity
Jul ’25