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

Entitlements and code-signing requirements are very different. See the following for more background on each: TN3125 Inside Code Signing: Provisioning Profiles TN3127 Inside Code Signing: Requirements You can use a code-signing requirement to check for an entitlement, for example: % codesign --verify -R '=entitlement [com.apple.security.app-sandbox] exists' -v /Applications/Pages.app … /Applications/Pages.app: explicit requirement satisfied % codesign --verify -R '=entitlement [com.apple.security.app-sandbox] exists' -v /usr/bin/true … test-requirement: code failed to satisfy specified code requirement(s) However, entitlements are tricky to use in this situation because: You can’t create a provisioning profile that authorises a custom requirement. Many of of the popular entitlements are either unrestricted on macOS, or only restricted in that they clear the entitlement-validate flag [1]. Given that, I think maintaining your previous approach makes sense, that is, check for the Team ID and a list of code-signi

If you haven't already, take a look at my post here. I haven't checked the code to confirm, but I strongly suspect that calling gen32IOVMSegments with a mask of the wrong size (like 0xFFFFF000) will cause kIOReturnMessageTooLarge, as the true mask range you've specified (0x00000000FFFFF000) is too large to fit in 32 bits. Yes, I am currently using the inTaskWithPhysicalMask interface in my code, and the masks I have tried are 0 x0000 0000 FFFF FFFFULL，0x0000 0000 FFFF F000ULL, 0xFFFF FFFF，0xFFFF F000, and 0x0, but the result is the same, using gen32IOVMSegments will return the same error. I have also used IOBufferCacheDescriptors:: withOptions and IOBufferCacheDescriptors:: withCapacity to build memory descriptors, but the results have not changed much. If you have time, Could you take a look at the code? I have submitted on the bug. One more thing to add: I have also tried using the prepare() interface of IODMACommand, but there have been no significant changes. Thanks!!

Thanks for bringing this to the Apple Developer Forums. First up, I want to double check that this is for iOS. You mentioned the “System Keychain”, which is a macOS thing [1]. On iOS there is only one keychain, known as the data protection keychain. Within that keychain, credentials exist within a keychain access group. Your app’s access to keychain access groups is moderated by entitlements, as explained in Sharing access to keychain items among a collection of apps. Note For a lot more background on keychain APIs, see: SecItem: Fundamentals SecItem: Pitfalls and Best Practices Next, let’s look at your specific questions: [quote='815135021, HSB, /thread/815135, /profile/HSB'] 1- Is there an API that allows us to create a signature without us having to pass the private key itself [/quote] No. iOS does have the ability to work with keys where the key material isn’t directly accessible to your app. We use this, for example, to allow keys to be protected by the Secure Enclave and to su

CloudKit share acceptance still requires a UIWindowSceneDelegate on iOS. Can try this approach ---- Keep SwiftUI lifecycle @main struct MyApp: App { var body: some Scene { WindowGroup { ContentView() } } } Add SceneDelegate import UIKit import CloudKit class SceneDelegate: UIResponder, UIWindowSceneDelegate { func windowScene( _ windowScene: UIWindowScene, userDidAcceptCloudKitShareWith metadata: CKShare.Metadata ) { acceptShare(with: metadata) } } Register it in Info.plist UISceneDelegateClassName = SceneDelegate

I’m generally skeptical of using Network framework for multicasts. It should work in general, but: There are a bunch of things it can’t do. And even when it can, you often hit weird edge cases. My general advice — and this makes me very sad — is to stick with BSD Sockets for broadcasts and multicasts. See Extra-ordinary Networking > Broadcasts and Multicasts, Hints and Tips. Having said that, this is weird: [quote='815127021, Anshuman1989, /thread/815127, /profile/Anshuman1989'] Reinstalling the app fixes the issue [/quote] This isn’t a standard pathology I see with Network framework’s multicast support and you are right to suspect local network privacy in that case. So let’s dig into that. First up, you’ve signed your app with the the com.apple.developer.networking.multicast entitlement, right? You didn’t mention that, and it’s very important. 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. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

If your submission relies on features that are only available on device, I recommend that you built and test it using the Swift Playground app and then request that it be judged in that environment. The major drawback with that is that the current Swift Playground app doesn’t support the iOS 26 SDK )-: I don’t have anything to share about that limitation right now, but if and when I do I’ll update this other thread. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com