İOS 26 beta battery %1

Oh, you’re a system extension. That changes things. System extensions, due to their privileges position on the system, are not allow to use entitlements to disable the additional security measures imposed by the hardened runtime. The only exception that that rule is that macOS platform extensions [1] are allowed to use JIT via the com.apple.security.cs.allow-jit entitlement. Sadly this isn’t documented on the Hardened Runtime page, and I’ve filed a bug to get that fixed (r. 164078299). So, if you want to use JIT in your sysex, you can’t lean on the com.apple.security.cs.allow-unsigned-executable-memory compatibility crutch. You’ll have to do the right thing and use com.apple.security.cs.allow-jit, as explained in Porting just-in-time compilers to Apple silicon. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] So, not DriverKit drivers.

I recommend that you seek help from your third-party vendor here. It seems likely that they’ll have a well-trodden path that you can follow for this. If you decide to debug this yourself, I have some general hints. To start, dont use --deep when signing code. For an explanation as to why not, see --deep Considered Harmful. Rather, sign each code item separately, from the inside out. Creating distribution-signed code for macOS explains that process in detail. I think that’ll reveal that there’s an issue with FMWrapper.framework. If so, that’s good, because gives you something to focus on. One of the most common causes of weird problems signing frameworks is that folks copy the framework without preserving symlinks. You should check that’s not the case here. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

The way you sign your app does not, in general, affect how it does HTTPS server trust evaluation. It’s hard to say exactly what’s going on here because you neck deep in third-party tools and libraries, but my best guess is that this is a build issue. That is, your code tries to get access to this root certificate but fails, either because the code is doing that incorrectly or because it’s not in the right place. If you were using Apple APIs I’d be able to suggest more specific paths for debugging this. I can’t do that here because I’m not familiar with the libraries you’re using. That leaves me with a couple of suggestions: You could dump the contents of your built app’s bundle to see if the certificate is where you expect it to be. You could track down the code that uses this root certificate and see how it’s failing. Is it using the right path to access it? Is the file actually there? Or is it failing to load it? You might have more luck asking this via the support channel for your third-party tooling. Shar

Is there no solution for this? I checked your other thread as well. Is there a way for me to remove the third party libraries from my SDK? I run the below commands to generate the SDK. xcodebuild archive -project Abc.xcodeproj -scheme AbcSDK -configuration Release -destination generic/platform=iOS Simulator -archivePath BuildArtifacts/iossim.xcarchive | tee build.log xcodebuild archive -project Abc.xcodeproj -scheme AbcSDK -configuration Release -destination generic/platform=iOS -archivePath BuildArtifacts/ios.xcarchive | tee build.log xcodebuild -create-xcframework -framework BuildArtifacts/iossim.xcarchive/Products/Library/Frameworks/AbcSDK.framework -framework BuildArtifacts/ios.xcarchive/Products/Library/Frameworks/AbcSDK.framework -output Frameworks/AbcSDK.xcframework As soon as I run, it gives me the list of resolved source packages that includes all the third party libraries. If I try removing the libraries, it gives error at all the import statements in my code. I even

I’m not sure I understand the concern here: Are you asking about how to interact with this FIDO2 USB device? Or whether that code will work in an authorisation plug-in? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thanks for filing FB20303191. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

This is eminently bugworthy. I’d appreciate one of you [1] filing a bug about it, and then posting the bug number here, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Well, at least one of you. Multiple bugs are fine (-:

The other thread discussing this issue has a bit more traction, so I’m gonna reply over there. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

The issue seems to have been resolved in iOS 26.1 (tested on simulator) Thank you!

I just tried to upload the app to App Store Connect, but the upload failed with this error: Unsupported Platform. The extension bundle myApp.app/PlugIns/myApp iOS QuickLook.appex is not supported for this platform. Please refer to the App Extension Programming Guide at http://developer.apple.com. (ID: 5df7bb8c-0216-4845-af78-c83d9a94de21) So I ended up creating a completely separate target for visionOS without the QuickLook extension.

The problem still persists with iOS 26.2 beta...