Post not yet marked as solved
This is becoming slightly difficult to debug! The console logs for a successful launch are nearly identical to those of an unsuccessful launch. I have observed "AU failed to load in time" for both cases. Ultimately when my AU fails to load, I see an exclamation mark over the plugin item in the list and it's inactive in the audio chain.The intermittent nature of the problem suggests a timing issue, and App Launch shows total time for launching my standalone app is 1.5s, which exceeds the upper bound in the docs. But there's not much help from the logs. I would have expected some difference when things work thus pointing me in the right direction.Has anyone else ran into this problem?
Post not yet marked as solved
Found some documentation at least giving an upper bound:"App extensions should feel nimble and lightweight to users. Design your app extension to launch quickly, aiming for well under one second. An extension that launches too slowly is terminated by the system."from https://developer.apple.com/library/archive/documentation/General/Conceptual/ExtensibilityPG/ExtensionCreation.html#//apple_ref/doc/uid/TP40014214-CH5-SW1
Post not yet marked as solved
I should add I'm testing a mac catalyst app.
fixed in GM Seed. thanks.
Has anyone else encountered errors with NSLayoutConstraint after including NSToolbar+UIKitAdditions.h?
Post not yet marked as solved
Just wanted to chime in and mention I'm dealing with the same issue. I found some info that might suggest it's related to using a production App Store account in the Sandbox environment, but I've been unsuccessful trying to switch over to one of my sandbox accounts. Once/if I'm able to do that, I'll respond if that resolved the receipt issue.
re: "The "correct" answer marked above is referring to libraries built with Xcode which is not the topic of this thread"If you're referring to my answer, that's incorrect. I compiled openssl via the configure script (external to Xcode) by modifying the target per my comments. I was able to successfully compile openssl for UIKitForMac, not macOS.The only issue I found was that it seems like we can't be selective about xcframeworks in terms of excluding them from the simulator. My current solution works as long as I don't intend to release a macOS app, which should remain true since running iPad on Mac covers what I need.
You likely did not remove the previous library from your build. Make sure it's cleared from Frameworks in the General tab as well as the Build Phase - Link with Binary Libraries.I can assure you this will compile openssl for UIKitForMac.
I ended up not using an xcframework after all, just linking different libs based on SDK which is what I was previously doing. So the necessary pieces were compiling openssl for UIKitForMac, and then code signing. To compile I added to the openssl macOS Configure scripts, under the darwin64-x86_64-cc variant (10-main.conf). I added "CFLAGS => add("-target x86_64-apple-ios13.0-macabi")". Though you could create a new variant just for this.To sign, I used the codesign utility, "codesign --sign <SHA-1> <lib>". The sha was from my Apple Developer certificate, and I believe that needs to align with the code signing identity for the target.
Reading up on few posts out there, I was able to compile crypto and ssl for x86_64 (uikitformac) by adding to CFLAGS "-target x86_64-apple-ios13.0-macabi". It seems we also have to sign the binaries, which was fine. However I'm looking for a way to exclude this from simulator builds. I don't currently see a way to specify this for an xcframework. Has anyone found a way to do this?
Post not yet marked as solved
Per the release notes:Targets which override the Architectures and Valid Architectures build settings for iOS may need to remove or conditionalize the overrides to build correctly for Mac when using UIKit for Mac. (51074742)If you can revert to using standard architectures, that would also resolve the problem.
