Post

Replies

Boosts

Views

Activity

Reply to WidgetKit widgets vanish in Montery with Xcode 16
Sorry, I didn't mean to leave this hanging. It turned out that the problem was the location of the application. It is an accessory app, so we were storing it outside of the Applications folder. Installing it in the Applications folder 'solved' the issue. You can reproduce in Monterey by moving an app containing widgets to somewhere like Application Support. It appears that later versions of macOS can discover widgets outside of Applications, while earlier ones cannot. Thanks!
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Jan ’25
Reply to Linker changes in Xcode 16 / macOS 15?
I can't speak to the Swift side without doing a lot of refactoring, but the Objective-C version works! I do get the following warning, however: Incompatible pointer types passing 'const struct mach_header *' to parameter of type 'const struct mach_header_64 *' Using this declaration fixes the warning: extern const struct mach_header_64 __dso_handle; I'd call this one settled... is it possible to change the accepted answer to your final post? Thanks!
Aug ’24
Reply to Linker changes in Xcode 16 / macOS 15?
After finding this, I searched for the setting, and found a known issue about it in the XCode 16 release notes here: https://developer.apple.com/documentation/xcode-release-notes/xcode-16-release-notes?changes=_1 Known Issues Some large or complex projects may fail to build and run if they are scanning for specific Mach-O sections in their binaries. (123416939) Workaround: Try setting the build setting ENABLE_DEBUG_DYLIB=NO. This will disable the debug dylib that enables the new preview execution mode. Setting this to NO will still allow you to preview in Xcode 16 Seed 1 using the legacy execution mode, but support for this mode will be removed in a future build. Perhaps I need to switch from "legacy execution mode" to the new preview execution mode? Is there a setting for this?
Jul ’24
Reply to Linker changes in Xcode 16 / macOS 15?
A little more background. I dug into the build output, and it is as follows: Undefined symbols for architecture x86_64: "__mh_execute_header", referenced from: -[MyClass init] in MyClass.o ld: symbol(s) not found for architecture x86_64 I'm building on an M1 Machine, and my targets are all set to build both architectures. Interesting that it can't find the symbol for x86_64, even if building just for Apple Silicon.
Jul ’24
Reply to Linker changes in Xcode 16 / macOS 15?
We have a linker flag set as follows, and I've used otool to dig into the headers, so I know that we're trying to read header data from an executable, not a dynamic library (Though, the code DOES read the plist data at runtime when building with Xcode 16 using the dylib_header). This leads me to think that perhaps it's Xcode 16 that has introduced a new default build setting that changes the Xcode 15 linker behavior? -Wl,-rpath,@loader_path/../Frameworks -sectcreate __TEXT __somePlist_plist ../MySubModule/somePlist.plist.enc
Jul ’24
Reply to Getting Progress from long running process
Thanks! I'm afraid I still need to support Ventura, so I can't adopt Swift 6 just yet. I have a tool that verifies volumes using diskutil.
Replies
Boosts
Views
Activity
May ’25
Reply to NSStatus Images missing in 15.4 Beta
Thanks for the quick response. Feedback filed, number: FB16924007.
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
Boosts
Views
Activity
Mar ’25
Reply to WidgetKit widgets vanish in Montery with Xcode 16
Sorry, I didn't mean to leave this hanging. It turned out that the problem was the location of the application. It is an accessory app, so we were storing it outside of the Applications folder. Installing it in the Applications folder 'solved' the issue. You can reproduce in Monterey by moving an app containing widgets to somewhere like Application Support. It appears that later versions of macOS can discover widgets outside of Applications, while earlier ones cannot. Thanks!
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Replies
Boosts
Views
Activity
Jan ’25
Reply to Method for privileged action using Framework
I think I figured it out. In any event, the helper is no longer crashing. I added @executable_path/../Frameworks to Runpath Search Paths in the helper's build settings. Thanks!
Replies
Boosts
Views
Activity
Jan ’25
Reply to Method for privileged action using Framework
For reference, the crash report includes this: Library not loaded: @rpath/MyFramework.framework/Versions/A/MyFramework
Replies
Boosts
Views
Activity
Jan ’25
Reply to Method for privileged action using Framework
There is no default framework search path for the helper tool. As a result, the helper crashes at launch because it can't find the framework. What's the search path to look in the parent directory?
Replies
Boosts
Views
Activity
Jan ’25
Reply to Method for privileged action using Framework
If the framework will then be able to perform privileged operations, then yes. 😉 Thanks!
Replies
Boosts
Views
Activity
Jan ’25
Reply to Linker changes in Xcode 16 / macOS 15?
I can't speak to the Swift side without doing a lot of refactoring, but the Objective-C version works! I do get the following warning, however: Incompatible pointer types passing 'const struct mach_header *' to parameter of type 'const struct mach_header_64 *' Using this declaration fixes the warning: extern const struct mach_header_64 __dso_handle; I'd call this one settled... is it possible to change the accepted answer to your final post? Thanks!
Replies
Boosts
Views
Activity
Aug ’24
Reply to Linker changes in Xcode 16 / macOS 15?
After finding this, I searched for the setting, and found a known issue about it in the XCode 16 release notes here: https://developer.apple.com/documentation/xcode-release-notes/xcode-16-release-notes?changes=_1 Known Issues Some large or complex projects may fail to build and run if they are scanning for specific Mach-O sections in their binaries. (123416939) Workaround: Try setting the build setting ENABLE_DEBUG_DYLIB=NO. This will disable the debug dylib that enables the new preview execution mode. Setting this to NO will still allow you to preview in Xcode 16 Seed 1 using the legacy execution mode, but support for this mode will be removed in a future build. Perhaps I need to switch from "legacy execution mode" to the new preview execution mode? Is there a setting for this?
Replies
Boosts
Views
Activity
Jul ’24
Reply to Linker changes in Xcode 16 / macOS 15?
I was able to build with ENABLE_DEBUG_DYLIB set to NO... though the default appears to be yes, based on the value in the test project.
Replies
Boosts
Views
Activity
Jul ’24
Reply to Linker changes in Xcode 16 / macOS 15?
Looking in the build log, the call to ld contains an additional flag in my project, as compared to the test project: "-dynamiclib" ... this may explain why the "_mh_dylib_header" change works, but I have yet to find the build setting which would influence Xcode to use this flag.
Replies
Boosts
Views
Activity
Jul ’24
Reply to Linker changes in Xcode 16 / macOS 15?
An additional piece of information, I have found that Archiving succeeds, so it would appear I'm only experiencing the issue when building/running in debug.
Replies
Boosts
Views
Activity
Jul ’24
Reply to Linker changes in Xcode 16 / macOS 15?
Naturally, the test project works fine. I'm also assuming that there is some project setting that I'm missing. NB - this is a well established large project with numerous targets and sub-projects.
Replies
Boosts
Views
Activity
Jul ’24
Reply to Linker changes in Xcode 16 / macOS 15?
A little more background. I dug into the build output, and it is as follows: Undefined symbols for architecture x86_64: "__mh_execute_header", referenced from: -[MyClass init] in MyClass.o ld: symbol(s) not found for architecture x86_64 I'm building on an M1 Machine, and my targets are all set to build both architectures. Interesting that it can't find the symbol for x86_64, even if building just for Apple Silicon.
Replies
Boosts
Views
Activity
Jul ’24
Reply to Linker changes in Xcode 16 / macOS 15?
We have a linker flag set as follows, and I've used otool to dig into the headers, so I know that we're trying to read header data from an executable, not a dynamic library (Though, the code DOES read the plist data at runtime when building with Xcode 16 using the dylib_header). This leads me to think that perhaps it's Xcode 16 that has introduced a new default build setting that changes the Xcode 15 linker behavior? -Wl,-rpath,@loader_path/../Frameworks -sectcreate __TEXT __somePlist_plist ../MySubModule/somePlist.plist.enc
Replies
Boosts
Views
Activity
Jul ’24