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

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

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?

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.

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.

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