“eskimo”

Thanks for filing FB24553094. [quote='843971021, norsegaud, /thread/843971, /profile/norsegaud'] unless of course there is a great reason not too. [/quote] I don’t think there’s any specific reason why we wouldn’t fix this, but I can’t offer any specific timeline. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

My understanding is that there are two levels of PIR approval: The Approved state indicates that your request has been approved but isn’t yet configured. The Successfully Onboarded state indicates that everything is ready to go. Please check the state of PIR requests. If they’re in the first state then the behaviour you’re seeing makes sense. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='844209021, Registered_User, /thread/844209, /profile/Registered_User'] Also filed via Feedback Assistant. [/quote] That’s the correct path for this. What was your bug number? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

The error you’re seeing is a pretty common one. Its specific meaning is that some code in your process tried to message an XPC endpoint that’s not available for some reason. And digging further into the error we see the name of the XPC endpoint involved, com.apple.devicemanagementclient.managedappsd. There are a variety of potential causes for that, but a common one is that the connection attempt was blocked by the sandbox. I suspect that’s what’s going on here. All third-party code on iOS runs in a sandbox. That sandbox is customised based on the code type. Apps have one type of sandbox, share extensions another, and so on. Some extension sandboxed are ‘tighter’ than others, and I think that’s the root cause of the error. The specific extension’s sandbox doesn’t allow the XPC connection necessary for ManagedApp framework to work. I suspect that this is omission rather than a deliberate restriction, and I recommend that you file a bug about the issue you’re seeing. Please post your bug number, just for the re

There have been significant keychain changes to the file-based keychain starting in macOS 26.4, but I’m not aware of any that would cause this specific problem. You should feel free to file a bug about it. However, be aware that the file-based keychain is effectively deprecated, and SecKeychainGetStatus itself is officially deprecated, which might limit the traction it gets. If you do file a bug, please post your bug number, just for the record. Taking a step back, I’m not sure why you’re doing any of this. Your table in your posts lists this combination: | Process | Keychain | | ------- | -------- | | GUI App | login.keychain | | GUI App | login.keychain | | GUI App | /Library/Keychains/System.keychain | | Daemon | /Library/Keychains/System.keychain | All of those combinations are valid, which is great. However, none of those combinations need you to explicitly open the keychain. The relevant keychain should be open, present in the search list, and unlocked, all by default. So why are you opening the keychai

My advice here hasn’t changed from what I suggested to zmactep back in Feb. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Please try again now. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='843331021, tttaaabbbccc, /thread/843331, /profile/tttaaabbbccc'] AI is suggesting [/quote] Hmmmm, that might actually be on track. Specifically, this part of the exception is a concern: this class is not key value coding-compliant for the key 1 Access 1.0 (iOS App). This crash should generate a crash report. Can you post it here? See Posting a Crash Report for advice on how to do that. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

This is a why question, per tip 3 in Quinn’s Top Ten DevForums Tips. Most questions like this have an extension “because I wanted to use it for X.” If that’s the case here, I encourage you to file an enhancement request for this feature along with that explanation. Please post your bug number, just for the record. Oh, one other option is to ask your question over in Swift Forums > Related Projects > Swift Crypto. Well, not that exact question, which is focused on the Apple side of things, but something more open-source-y. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Is this a background session? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

There have been significant keychain changes to the file-based keychain starting in macOS 26.4, but I’m not aware of any that would cause this sort of problem. Before we go further I’d like to clarify what exact alert you’re seeing. Please reply here with either a screenshot or the exact wording, including the button names [1]. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] See Resolving errSecInternalComponent errors during code signing for same examples of the latter.

[quote='843546021, RomainDropB, /thread/843546, /profile/RomainDropB'] So a fresh submission is technically impossible [/quote] Ah, tricky. I’m investigating whether there’s a way out of this bind. [quote='903283022, RomainDropB, /thread/843546?answerId=903283022#903283022, /profile/RomainDropB'] if I open a paid Technical Support Incident (TSI) for this [/quote] DTS hasn’t accepted paid TSIs since May 2024. Rather, we now have code-level support requests, which are all free (although we redirect most of them to the forums, so thaht everyone can benefit from our work). But… [quote='903283022, RomainDropB, /thread/843546?answerId=903283022#903283022, /profile/RomainDropB'] Or would it likely get bounced as out of scope … ? [/quote] Indeed. However, in a case like this, where the correct path forward isn’t clear, DTS might’ve accepted your TSI. And the equivalent is me wading into this forums thread. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo

Lemme tackle your questions in turn. [quote='843033021, lwebbz, /thread/843033, /profile/lwebbz'] so there appears to be a richer internal enum that isn't mapped through to the provider. [/quote] Right. Although it’s not simply that this internal enum has values beyond those used by the external enum. Rather, there’s a mapping from the internal to the external. I just took a look and it seems that the default case in the mapping yields an external value of .none, which probably explains the behaviour you’re seeing. Still, this is all implementation detail and thus not something to rely on. Which brings me back to your actual question: [quote='843033021, lwebbz, /thread/843033, /profile/lwebbz'] is there any supported way for the provider to distinguish [/quote] Nothing beyond the stop reason. If that’s not working out for you then I recommend that you file a bug about it [1]. And please post your bug number, just for the record. [1] Is it a bug? Or is it an enhancement request? Well, it’s kinda in between. Yo

[quote='843622021, FxFactory, /thread/843622, /profile/FxFactory'] what exactly are these requirements? [/quote] That question makes no sense because com.apple.developer.service-management.managed-by-main-app isn’t a real entitlement, in the sense defined by Determining if an entitlement is real. [quote='903075022, FxFactory, /thread/843622?answerId=903075022#903075022, /profile/FxFactory'] The [com.apple.developer. prefix] hints that this would only be needed during development [/quote] No, that’s not how to read this. Rather, the com.apple.developer. prefix means that: This entitlement is available to be used by third-party developers [1]. But it’s restricted, that is, it must be authorised by a provisioning profile (the unrestricted entitlements have a com.apple.security. prefix). TN3125 Inside Code Signing: Provisioning Profiles talks about these concepts in more detail. [1] To be clear, not all entitlements available to third-party developers have this prefix. Some entitlements were created before this c

[quote='843542021, Vij_mac, /thread/843542, /profile/Vij_mac'] 1- Does macOS support configuring and running multiple Transparent Proxy providers simultaneously … ? [/quote] Yes. [quote='843542021, Vij_mac, /thread/843542, /profile/Vij_mac'] 2- If multiple Transparent Proxy configurations are deployed through MDM, how does macOS determine which proxy handles the traffic? [/quote] Each provider declares the traffic it wants to see. Once the system see a matching network flow, it passes that to the provider which decides whether it wants to claim it or not. If it doesn’t claim it, the system acts like that provider wasn’t installed. It it does claim it, then the flow disappears into the provider. If the provider makes its own outgoing network connections, those connections will be seen by subsequent providers. I’d be happy to go into more detail at the API level, but I suspect that you’re coming at this from the sysadmin level. I can’t help you with that. My focus is on helping developers use our APIs to build