XCC latest Xcode/macOS RC and CodeMagic 16 RC also instant crash our app. Stack trace is "NO_CRASH_STACK" in Xcode organizer.

For us, the crash was due to using NSDecimal* functions. I missed this in the release notes. Eliminating those functions restored Xcode 16 RC builds running on iOS 17.x.

Lost an hour to that missing doco re: AppShortcuts exposed intents must reside in the main target, not a dynamically linked xcframework. I've noticed that a parameterized AppIntent registered as an AppShortcut and that uses an AppEnum located in that xcframework will work for Siri and Shortcuts triggers, but does throw an SSU warning about a missing symbol. Are there other gotchas? The limitation — that our primary user exposed intents cannot be in that xcframework — is a drag if one maintains multiple apps that may share some limited overlapping functionality. Is there work to change this? The AppIntentsPackage API has had a rocky public introduction since iOS 17.

Two of our competitors have action extensions that appear in Safari, based on some predicates, that do not launch com.apple.ui-services sheets but rather immediately cold start their app and deliver some deep link context. Is there an approved way to do this via com.apple.services or com.apple.ui-services (the ui-less and ui-ful action extension variants)? Is this passing something back to the JS finalize method to have Safari navigate to a webpage or navigate to a Shortcuts URL?

[quote='850730022, Frameworks Engineer, /thread/793565?answerId=850730022#850730022'] -p 443 [/quote] Thanks for that port set flag. I assume I just need to retrace my steps to find the provisioning mistake along the way: xcrun ba-serve --host 192.168.0.10 -p 443 pack.aar xcrun ba-serve url-override https://192.168.0.10 -> on iOS 26.0 b4 device w/ URL Override set 2025-07-26 14:41:39.804 ba-serve[36964:3124040] CFNetwork SSLHandshake failed (-9806) The certificate for this server is invalid. You might be connecting to a server that is pretending to be “192.168.0.10” which could put your confidential information at risk.

Filed FB19512759. If you're working up tests on the bug, I ought to detail the "almost always throws": on the very first access of a novel asset url(for:) does not throw. Thanks for that workaround. Indeed, FileManager will enumerate and find assets and the manifest json. One minor hitch: an asset that no longer exists in a pack will still exist in that directory (i.e., a previous pack version included it, that pack was locally deleted, and a new version of the pack without that asset was downloaded again).