I have tried to make sense of what "Add Missing Constraints" has done, but I can see no logical pattern to it. One of the parts that makes the least sense is that some elements (for example an "OK" button) have an intrinsic size, and resizing the window should have no effect on the size of the OK button. Other elements, such as a box containing editable text, has no intrinsic size, but would (in theory) either take the size of the surrounding superview, or would take an explicit size set by me. What is confusing me hugely is that there is no obvious way to tell which elements set a size, and which elements take a size based on their surroundings. In all cases we have a "view" section, which has an edited X, Y, width and height. Values exist in each case. Should these values be set by me (and if so, how do I know they're set by me), or should they be set by autolayout? How do I tell which is which? I am developing what seems to be a reasonable simple window. A label, a resizable text box, another label, a popup, a label, and then a tab view containing various possible options, then a Cancel and OK button. Everything in this window has a fixed size, except the resizable text box, which in theory should be as large as all the remaining space in the window. I read the docs over and over and they all make sense. I then try out what the docs say and nothing makes sense, and Xcode keeps crashing. I'm lost.

May be there is some confusion here. Autolayout does NOT set constraints, it just computes objects layout based on the constraints. Which means it is up to you to set constraints as size. I know that autolayout doesn't set constraints. What I am talking about are the X, Y, width and height values under the "view" option in the size inspector. These entries are editable, and have values, and I have no idea where these values come from or what the effect on autolayout is if I edit the values. What makes no sense to me is that I have constraints that link (with equals) the bottom of each element to the top of the element above, and I have linked the top most element to the superview, and the bottom most element to the superview, but this is not enough to create an unambiguous layout.

As I said above already, there is no shortage of google searches ("XCode xib examples") and tutorials that describe the theory of MacOS user interface design. The limitations of most tutorials however can be described as "how to draw an owl". What I am looking for is best practise for realistic user interfaces of a realistic level of complexity - and obviously the best of best practises will come from Apple themselves. Does such a thing exist?

I am seeing the same problem in Safari 14.1.2 for Big Sur.

Five months later, anyone making Safari Web Extensions?

I think I am having the same issue with a Safari Web Extension. The window appears, but nothing interactive works - it cannot be sized, a splitview cannot be moved, etc. Did you ever get to the bottom of this?

Lots of digging, stumbled on something that said that kSecAttrPublicKeyHash in the certificate is supposed to match kSecAttrApplicationLabel on the key. It does not however appear possible to retrieve kSecAttrPublicKeyHash from a certificate. The function this is set in is defined below, but appears to be a private API. https://github.com/apple-opensource/Security/blob/5e9101b3bd1fb096bae4f40e79d50426ba1db8e9/OSX/sec/Security/SecCertificate.c#L5627 In theory I could emulate this code with SecCertificateCopyKey() and SecSHA1DigestCreate(), but this would then break as soon as Apple used a digest other than SHA1. Am I missing something, or is this a bug?

The code that needs to do this is the Redwax Tool at https://redwax.eu/rt/, which does universal certificate and key handling between different systems. SecKeyCopyAttributes() doesn't work in this case, because when the key you are trying to find the class of is a private key, you have to unlock the keychain for this key before keychain will tell you this is a private key, and the whole point is to not unlock private keys that are unrelated to the task - a chicken and egg problem. This gives a terrible user experience as the user is asked to unlock every key one by one. One possible way around this is if there was a search parameter to SecItemCopyMatching() that allows you to restrict the class to kSecAttrKeyClassPublic, but this too appears not possible / undocumented. What I'm looking for are the public keys that keychain has, so I can match them up with certs on the outside, which will then trigger an attempt to unlock the private keys that are relevant and no others.

SecIdentityCreateWithCertificate() is the secret for MacOS thank you. In this case, the certificate created with SecCertificateCreateWithData() is passed into SecIdentityCreateWithCertificate(), and you get a SecIdentityRef that you can extract the key from. Getting the key exported is the next problem, SecKeyCopyExternalRepresentation's output format isn't well defined. Subject for a different post.

There is a search parameter to SecItemCopyMatching() - pass value of kSecAttrKeyClassPublic into the key kSecAttrKeyClass and you get public keys. CFStringRef dictkeys[] = { kSecClass, kSecMatchLimit, kSecAttrKeyClass, kSecReturnRef, }; CFTypeRef dictvalues[] = { kSecClassKey, kSecMatchLimitAll, kSecAttrKeyClassPublic, kCFBooleanTrue, }; CFDictionaryRef query = CFDictionaryCreate( NULL, (const void **) dictkeys, dictvalues, sizeof(dictkeys) / sizeof(dictkeys[0]), &kCFTypeDictionaryKeyCallBacks, &kCFTypeDictionaryValueCallBacks ); OSStatus err = SecItemCopyMatching(query, &keys);

Through experimentation I have worked out that exporting the public key as follows will generate a SubjectPublicKeyInfo: err = SecItemExport(keyref, kSecFormatOpenSSL, 0, NULL, &der);

So SecKeychainCopyDomainSearchList takes a SecPreferencesDomain, which is an enumeration of user, system, common and dynamic. If I start with user, I get one entry back: <SecKeychain 0x101604b70 [0x7ff84e723800]> I only appear to be able to get the path of this SecKeychain with SecKeychainGetPath, which gives me what looks like a path on the filesystem like this: /Users/minfrin/Library/Keychains/login.keychain-db How do I get the name "login" from the above, do I have to parse the filename? That doesn't make sense for keychains not backed by a file, I feel like I a missing an API call or an attribute I should be requesting for the name, the docs say nothing on this. The system enumeration gives me one keychain, with a path as follows: /Library/Keychains/System.keychain The common enumeration gives me the same as the system enumeration, but I can't see any explanation as to why: /Library/Keychains/System.keychain The dynamic enumeration gives me nothing (not tried it with any smartcards plugged in). How does this map onto the Keychain Access application? Neither "iCloud" nor "System Roots" appear anywhere as keychains, are these handled as special cases? Where do their names "iCloud" and "System Roots" come from, are they returned by an API or are they hardcoded? What is the correct way to query iCloud as a keychain using SecItemCopyMatching?

There’s no API to get the user-visible name for a keychain. For a file-based keychain one typically shows the file name. I usually do this by getting the localizedNameKey property. I don’t think that’ll hide the extension by default, so you’ll want to drop the extension first. Will try this. It doesn’t. Keychain Access is built in to macOS and, as such, it can do things that a third-party app can’t do. Is it true to say that the iCloud keychain (the one visible in Keychain Access, not private groups defined by SecAccessControl) is hidden from all 3rd party apps? The end goal is to add keychain support to Redwax Tool at https://redwax.eu/rt/, which reads certificates and keys from all the places, matches them all up in ways you define, and then writes them back to all the places. It seems that supporting anything other than file based keychains is not possible.

Seeing this problem with Xcode Version 15.2 (15C500b).