[quote='817550022, DTS Engineer, /thread/770409?answerId=817550022#817550022'] [...] that code broke when we switched to ASN.1, and hence this thread. [/quote] In fact, that is not the case here, although I understand that you would like to use it as an 'instructive case'. Nothing is broken yet in the implementations we are using, at the moment it is more about preventing something from breaking in the near future. But yes, if you use a function or feature that is not officially supported or for which there is no API, there is always a risk that something will break after an internal change. If you are aware of these dangers, you can act accordingly and plan ahead. In particular, it is important to consider whether you want to and can wait years for an official solution to be implemented, or whether you need an immediate, viable solution. [quote='817550022, DTS Engineer, /thread/770409?answerId=817550022#817550022'] Remember, DTS’s goal is to help developers build products that work now and in the future. [/quote] A noble and sensible goal. Unfortunately, in practice, I have seen in several projects and with several customers that it takes years to get sustainable solutions at the (iOS / macOS) platform level. This applies to both features and bugs. I'm happy to be positively surprised, but we'll see what happens in the future with Entitlement value retrieval on iOS. I hope you understand, as I have explained, that it is not always possible to wait so long for a solution that may never come. [quote='817550022, DTS Engineer, /thread/770409?answerId=817550022#817550022'] The doc I usually point folks at is TN2311 [/quote] Thanks. I must have either forgotten or repressed this. The consequence of potentially losing all default keychain entries by changing the App ID was a rather drastic consequence of this change. I am afraid we have gone a bit off topic, thank you for your comments and information. I think we can end this thread with the simple answer to my original question that there is, or will be, no official documentation of the ASN.1 structure.

[quote='817402022, DTS Engineer, /thread/770409?answerId=817402022#817402022'] So, yeah, DTS doesn’t support that. [/quote] I can understand if it's not actively supported, but I wouldn't call providing technical documentation 'active support'. There are several official Apple articles on the subject, but most of them are not very detailed. Wasn't the codesign utility once open source? Since the reorganisation of Apple's OSS pages, many things are not so easy to find. [quote='817402022, DTS Engineer, /thread/770409?answerId=817402022#817402022'] Please post your bug number, just for the record. [/quote] The Feedback Assistant ID is FB16077892 (But for some reason my feedback seems to have been deleted immediately? At least I don't seem to be able to access it anymore) Based on my experience over the last 15 years with this type of developer feedback for iOS development, it will be years before such a feature is available in iOS. If an implementation is considered at all. In the meantime, we need a pragmatic solution. Is SecTaskCopyValueForEntitlement considered a private API in the Security Framework, which if used on iOS will result in a rejection in the App Store review process? [quote='817402022, DTS Engineer, /thread/770409?answerId=817402022#817402022'] In the meantime, if you’re written a keychain wrapper the best option is to have your client supply the keychain access group info you need. That gets you out of this business entirely. [/quote] This just shifts the problem to the application developer, who either has to abandon the use of the default keychain access group altogether, or try to construct the string for the default group himself. [quote='817402022, DTS Engineer, /thread/770409?answerId=817402022#817402022'] The App ID prefix is not always the Team ID. Older projects might use a unique App ID prefix. If you’re writing a general purpose wrapper, make sure to take that into account. [/quote] Many thanks for the hint! Do you have more details on this? I can't remember when it was possible to define your own app ID prefix in the Developer Portal, not even in the older versions.

The Security Framework does not provide any of the Entitlement API functions such as SecTaskCopyValueForEntitlement for iOS, only for macOS. So at the moment we have no choice but to read the entitlements ourselves. Why are the Entitlement APIs from the Security Framework not available for iOS? It just doesn't make sense! An example where access to the entitlements is necessary at runtime: When using the Keychain APIs and using keychain groups, it is very important to be able to get the team ID from the app's entitlements at runtime. When saving a keychain entry, the default application identifier (team ID + bundle ID) is used as the group if none is specified. However, when retrieving keychain items, there is no way to restrict them to items from the default group if you do not have the team ID. This is an inherent design flaw that can be circumvented if the team ID can be retrieved. There are many other scenarios in which it is at least helpful, and in some cases necessary, to read out certain Entitlement values at runtime. For example, to determine which APS environment is active, what the default data protection value is, etc.

Thank you for your quick response! [quote='799295022, Developer Tools Engineer, /thread/761439?answerId=799295022#799295022'] If you want to vary runtime behavior when previewing, you could check the value of [...] [/quote] Switching off certain behavior at runtime is indeed a critical case for us, as we absolutely must prevent certain things like network requests that are normally executed when the app is started. Otherwise internal data about our developers and their behavior during development could leak to other parties since those network requests will happen each time a developer opens a preview. However, this is not the primary case I wanted to refer to. [quote='799295022, Developer Tools Engineer, /thread/761439?answerId=799295022#799295022']If you have a unique situation [...], we would be interested in hearing more details about what you’re trying to do.[/quote] We have a relatively large amount of special code that is exclusively there to ensure that SwiftUI previews work correctly and that the views can be displayed in all relevant states. This includes the typical mocks of types and services used via dependency injection. Usually, it is undesirable for previews to trigger actual network requests, for example; instead, you want simulated results. These mocks are currently only built for unit tests and previews, compilation conditionals prevent them from being available for other build configurations. Another example is special code for view models and methods that can change their otherwise internal (or even private) state. These are therefore methods that should not and must not be used by developers in the app's regular code, as they soften the visibility and accessibility of types and thus violate the integrity of the software architecture. As a specific example, we have view model methods for previews that allow their internal state to be injected or changed from "outside" (i.e. inside the #Preview macro). I hope this makes it clear why certain code whose sole purpose is for previews may not be included in any other build. Developers should not be able to use this code outside of the context of a SwiftUI preview. That's also why the dead code stripping build feature is not sufficient for this purpose.