show when run

Thank you for your post. May I request that you create a focused sample that developers in the forums can run and observe the results? When running a SwiftUI app designed for iPad on Mac Catalyst, it can be challenging to ensure that the UI scales appropriately and fills the available screen space. However I am confused your iPad target is an iPhone 17? Ensure that your main view is set to expand and fill the available space. You can try using to understand the available space and adjust your layout accordingly. Mac Catalyst provides specific modifiers and environment values you can leverage to better adapt your UI. Ensure that the Mac Catalyst app’s window toolbar isn’t consuming excessive space or causing layout issues. Test your app with different Mac resolutions or window sizes to confirm whether the layout issue is specific to certain dimensions or more general. Since you are using Xcode 26.2 (17C52), ensure that you are also on the latest version of macOS. I look forward to seeing your

// StoreView.swift import StoreKit import SwiftUI struct StoreView: View { @ObservedObject private var storeController = StoreActor.shared.productController var hasPro: Bool { storeController.isEntitled } var body: some View { if let product = storeController.product, !storeController.isEntitled { // Pro features available to the user TO PURCHASE if(product.displayName == ProductNames.pro.humanReadablePurchaseLevel()) { // Show the product in a nice way, using the properties of the `product` variable ProductRow(product: product) } } if(hasPro) { // The user has already purchased the pro version, so show the pro features } } } struct ProductRow: View { @ObservedObject private var storeController = StoreActor.shared.productController var product: Product var body: some View { Text(Upgrade to (product.displayName)) Text(product.description) // Purchase button Button { Task(priority: .userInitiated) { await storeController.purchase() } } label: { Text((product.displayPrice)) } } }

Oh, one more thing. That dispatch_sync call being made by XProtect is doing some one-time initialisation. That initialisation has to be done on the main thread. So, you might be able to work around this by forcing that initialisation to run on the main thread in advance of all this secondary thread work. An easy way to do that would be to use NSAppleScript to run a trivial script from the main thread as part of your app init sequence. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thanks for attaching a sysdiagnose log to your bug (FB21334477). I took a look at the enclosed spin dump and I see this: Thread 0x222f6b 180 samples (216-395) priority 31 (base 31) cpu time 0.016s (43.3M cycles, 111.3M in… 180 thread_start + 8 (libsystem_pthread.dylib + 7080) [0x19ea8cba8] 180 _pthread_start + 136 (libsystem_pthread.dylib + 27656) [0x19ea91c08] 180 ??? (XojoFramework + 1309844) [0x10569bc94] 180 ??? (XojoFramework + 2624740) [0x1057dcce4] … redacted … 180 -[NSAppleScript compileAndReturnError:] + 136 (Foundation + 9808488) [0x1a0c7da68] 180 OSACompile + 52 (OpenScripting + 78068) [0x1bffa30f4] 180 SecurityPolicyTestDescriptor + 152 (OpenScripting + 8836) [0x1bff92284] 180 _SecurityPolicyTest(char const*, void const*, unsigned long) + 332 (OpenScripting + 8472) … 180 InterpreterSecurity_ScanBuffer + 112 (libInterpreterSecurity.dylib + 4868) [0x298e39304] 180 -[InterpreterSecurity scanData:withSourceURL:] + 164 (libInterpreterSecurity.dylib + 3… 180 -[XProtectScan beginAnalysisWithFeedback:] +

Looking at the code you posted, the only way [1] that preferences can be nil at line 15 is if your decoded object code fails. You didn’t show that code, so it’s hard to tell what’s going on there. It sounds like you can reproduce this reasonably reliably. Given that, you can debug this using logging. I have general advice on that topic in Testing and Debugging Code Running in the Background. IMPORTANT It’s time to stop using NSLog habitually. Rather, use print(…) for transient debugging and Logger for debugging that you want to keep in your codebase (or for cases like this, where you need to debug without Xcode being attached). Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Well, not the only way. You could be dealing with an issue that’s outside of the scope of the Objective-C / Swift execution models, like a memory corruption problem. However, let’s rule out the easy things first (-:

I can’t really help with the AVB side of this, so I’m hoping someone else will chime in on that front. However, I have insight into the logging. The assert you’re hitting shows a bunch of values because: The log point indicates that the data is private. Our system don’t record private data by default. Presuming that you’re on the Mac, you can configure the system to record that data. See Recording Private Data in the System Log. If this works and you’re able to unmask all those values, please post the results here and I’ll take another look. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Hello Quinn, many thanks for all this. Normally I use Script Debugger to export my applet run-only. Then, I use SD Notary to sign and notarize. I will try to put your suggestion into that workflow. Up until Tahoe, I was avoiding Script Editor partly because it ignored/wiped my custom icon no matter what I tried. SD, did not. I don't know how to use Xcode. Have tried a few times but found it impenetrable. It will take me some time to get it working even to just create a dummy app with a custom icon. Cheers.

Thank you for your guidance on focusing on the packaging rather than the certificate! Following your recommendation, I ran systematic tests and identified the exact root cause. Summary The Developer ID Application certificate works perfectly. The Developer ID Installer certificate has a broken chain. Test Results I created an automated diagnostic that tested 5 different combinations: Test Executable Packaging Result 1 Compiled Swift binary ditto (.zip) ✅ Accepted 2 Compiled C binary pkgbuild (.pkg) ❌ Invalid 3 Shell script ditto (.zip) ✅ Accepted 4 Shell script pkgbuild (.pkg) ❌ Invalid 5 Compiled C binary productbuild (.pkg) ❌ Invalid Pattern: Every .zip passes. Every .pkg fails. The Issue When signing with the Installer certificate, this warning appears: Warning: unable to build chain to self-signed root for signer Developer ID Installer: Matthew Seymour Greer (W2AT7M9482) This warning does NOT appear when signing .app bundles with the Application certificate. The Installer certificate can sign locally, but