Building for iOS Simulator, but the linked and embedded framework ‘XX.framework‘ was built for

The error here, -25303, or errSecNoSuchAttr, suggests a problem with your attributes. And the only non-required attribute you’re supplying is kSecAttrApplicationTag. Which is, in fact, the cause of your issue. kSecAttrApplicationTag is only supported on keys. I recommend that you have a read of SecItem: Fundamentals [1], and specifically the The Four Freedoms^H^H^H^H^H^H^H^H Functions section, which explains how you can use SQL to model the expected behaviour of the SecItem API. In this case, the SQL table for certificate items has no kSecAttrApplicationTag, and thus this error. It also has links to the doc that explains which keychain item class supports which attributes. [quote='815390021, ellinj, /thread/815390, /profile/ellinj'] Is there an alternative to create SecIdentity without keychain access? [/quote] We finally (finally finally!) have this. See the docs for the SecIdentityCreate function. IMPORTANT This was added in Xcode 26 but backdeploys to much older systems. Or at least that’s the pla

Hi Travis, Thanks for the reply. I actually found the issue. Problem was arising due to the assets file being in Development Assets in Build Settings. So Image was not displaying in devices where I installed the app from TestFlight.

[quote='815354021, JacobHearst, /thread/815354, /profile/JacobHearst'] OSLogStore … it only collects logs for the current process [/quote] Correct, at least on everything except the Mac. I cover this and many other logging topics in Your Friend the System Log. There isn’t truly a happy path here. When it comes to NE debugging, you need to see the full system log and there are no APIs on iOS that’ll let you get that. Oh, one last thing. If you’re goal is to work with Apple to help debug a problem, you can ask your user to file a bug in Feedback Assistant. That’ll attach a sysdiagnose log to the bug report. You won’t be able to see the sysdiagnose log, but if you pass the Apple folks that bug number they should be able to get it. I talk more about this idea in Using a Sysdiagnose Log to Debug a Hard-to-Reproduce Problem. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

You can expect that most uploads will be notarised quickly. Occasionally, some uploads are held for in-depth analysis and may take longer to complete. As you notarise your apps, the system will learn how to recognise them, and you should see fewer delays. For lots of additional info about notarisation, see Notarisation Resources. Specifically, it links to a Q&A with the notary service team that’s quite instructive. [quote='815402021, AbubakrLatif, /thread/815402, /profile/AbubakrLatif'] have created new certificate [/quote] Yikes! That won’t help with this issue and, as these are Developer ID certificates, it can have negative consequences. Developer ID as precious, as I explain in The Care and Feeding of Developer ID. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

If an “agent” can’t: run a build/test for a specified scheme/target/destination, interpret failures, apply the needed project/build-setting changes, iterate until green, then it’s an in-editor assistant, not an agentic workflow.

Apple can fairly say: “Agents shouldn’t directly edit our serialization format.” But if they advertise agentic workflows and the agent can’t reliably do core build/debug tasks (target build settings, linking, schemes), then the product gap is real. Agentic workflows require a closed loop: apply build-setting changes → build → fix → repeat. If the only exposed interface is “chat + inline code edits,” it’s not agentic for build/debugging. Therefore Apple needs a supported automation surface (typed project actions with preview/undo), regardless of how ugly project.pbxproj is. Expected: Agent can apply target/scheme/build-setting changes (typed + preview/undo), run build, iterate on failures. Actual (Xcode 26.3 RC): Agent mostly suggests or edits source files; can’t reliably adjust the build/ debug configuration loop for multi-target/C++ integration. C/C++ integration is where an agent should shine because it’s repetitive, error-driv

After upgrading to MacOS and iOS 26.3, this problem is solved.

So splitting targets into different projects is a way to go, but do not make cross-project references and add target dependency. The idea is to build the subproject fully separately. Claude helped with implementation, so I asked it to write the rest of the post. The Solution Two scripts, triggered at different build stages: 1. Scheme Pre-Action — BuildPkgTestCMD.sh Builds the CLI project via a separate xcodebuild invocation before the main build starts. 2. Run Script Build Phase — CopyPkgTestCMD.sh Copies the built binary into the app bundle after the Resources phase. Both scripts check EFFECTIVE_PLATFORM_NAME and skip on non-Catalyst builds (e.g. iOS). Gotchas We Hit Build settings leaking into the nested xcodebuild call. Scheme pre-actions inherit all build settings from the parent target as environment variables. This means the nested xcodebuild silently picks up Catalyst platform, signing, and arch settings. Fix: wra

I've been waiting for Review now since February 5th. Can't even seem to get TestFlight builds approved - Had one that was done in a day, but everything else just sat in waiting for review. Emailed support but no reply. Might try calling as found them to be super helpful on the phone before

Dear Richard, Thank you for reply! Yes, I would like external device (MacBook) to display the same content as iOS device. I use fully programmatical approach. Sorry for the misleading information provided, by saying window has already been created I meant that the instance of UIWindow and its rootViewController has already been created, before I enabled Screen Mirroring. After enabling Screen Mirroring I see the instantiation of second UIWindowSceneDelegate and willConnectToSession of the second instance is supplied with new scene instance. For my app this is actually the same as creating new instance of my app. To avoid creating second instances I've placed the following code: if(connectingSceneSession.role == UIWindowSceneSessionRoleExternalDisplayNonInteractive) { return nil; } in AppDelegate's configurationForConnectingSceneSession method. But this is not documented, and I am not sure if this will work for all cases. In willConnectToSession. It takes place after connecting to the AirPlay receiver