I finally found the issue: mode=developer on the associated domains links causes a phone without the developer support enabled to emit Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1004 "Unable to verify webcredentials association of with domain . Please try again in a few seconds." I had seen this in the simulator and thought it was temporary, as retrying almost always worked. But on an actual device without developer mode set, this error kept happening (and was silently ignored by my UI). IMO mode=developer should have no effect if a) AASA developer mode is not enabled, or b) the app came from the App Store and not TestFlight. At the very least the error description doesn't match the conditions.

[quote='905951022, Tomato, /thread/847244?answerId=905951022#905951022, /profile/Tomato'] I don't know what 'this' is or why that's is not possible, but they are not going to take your word at its face value. If I were you, I would show them a screen-capture video to show them how things are put altogether. [/quote] I'm referring to TestFlight app review. I never used the word "beta" in my discussion with them, and that's not the reason it was rejected. What is the thing that you refer to as the beta app review? If you casually use the word 'beta,' that action alone will prompt them to reject your submission. You must not be familiar with app store submission, so let me try to explain it in simple terms. In their web form they have fields for me to provide them a username and password to a demo account so that they can log in and exercise the app. It is not possible to give them a passkey via a form like this. "This" refers to the web form. Maybe you don't know what passkeys are. They are a cryptographic key used for authentication, and they are stored in the keychain (Passwords). I can't give one to someone else in a text field.

Just a heads-up, my own access has been restored. I don’t know if the overall problem has been fixed.

It seems all that functionality showcased in Control Center by Apple widgets is reserved for Apple only. I’m so fed up with this from Apple. Introduce a poorly-documented API, we see examples of how it can work, only to find out no, we don’t get to do the same things. On iOS it’s even worse. A long-press on the Camera control brings up a popup menu with four camera modes to enter. A long-press on the Timer control bings up a fancy full-screen UI to let the user choose a duration for a new timer. All I can do is let the user pre-configure several buttons with the options I want to offer, or open my app for them, which defeats the purpose of the control widget. Apple could've spent time enhancing this API, but instead gave us yet another new look and feel that adds effort for us and gives users no benefit.

I see a three of issues here. First, you’re asking for something that doesn’t make sense. accessControl uses a this-device-only modifier, but you’re setting kSecAttrSynchronizable to true. What’s the point of synchronising something if it’s limited to this device only? This stems from a misunderstanding of kSecAttrAccessibleWhenUnlockedThisDeviceOnly, I think. I set it to kSecAttrAccessibleWhenUnlocked, and it still didn’t work. Second, you’re setting kSecAttrAccessControl and kSecAttrAccessible. That’s weird because the former subsumes the latter. Note how the value you’re using to kSecAttrAccessible is also being passed when you create accessControl. I removed the kSecAttrAccessible attribute altogether, and it still gives me paramErr. Persistent references to synchronizable items should be avoided; while they may work locally, they cannot be moved between devices, and may not resolve if the item is modified on some other device. I only use the identifier locally and in-memory, so it doesn’t matter if it’s not valid on other machines, but this seems like an unnecessary limitation either way, since it’s not hard to make a globally unique identifier. Something that's confusing to me is that when you call SecAccessControlCreateWithFlags(), you pass both "protection" and "access control" constraints, which seem to have at least semantic overlap. I want the user to have to provide access to the password each time it is used, rather than only when unlocked. My understanding is that that’s what .userPresence does, but it seems like that could have also been a protection class. What does it mean to say kSecAttrAccessibleAlways and .userPresence, for example? And the "ThisDeviceOnly" variants could imply that unlocking on one device doesn't automatically unlock on another device, hence why I was using that. In any case, I'm using kSecAttrAccessControl because I want each use of the password to require the user actually be there (I get that the system won’t always prompt, that it caches authorization for some amount of time, but that's okay). In any case, I still can't figure out why it won’t let me add .userPresence to the password. … On a whim I removed the kSecAttrSynchronizable = true, and that got rid of the error! I’m not explicitly using kSecUseDataProtectionKeychain, which is not what I was expecting. For example, TN3137 says: To target the data protection keychain, set the kSecUseDataProtectionKeychain attribute or the kSecAttrSynchronizable attribute to true. And lastly just to confirm: Something stored with .userPresence requires presence even to query attributes and not the password value itself? That's the behavior I'm seeing. I can work with that, but I wasn't expecting it for some reason.

Okay, looking into TN3137, it says To target the data protection keychain, set the kSecUseDataProtectionKeychain attribute or the kSecAttrSynchronizable attribute to true. I am setting kSecAttrSynchronizable to true when adding items, so it should be using the data protection keychain.

macOS, yes, sorry. I’ll look into this aspect, thank you. I see these items going into the iCloud keychain (the flag is for unit tests where they end up in the login keychain), as viewed via Keychain Access.

Okay, it seems ScreenCaptureKit will let me enumerate windows and get their titles, but I have to rely on the hope that the first one listed is the topmost window (seems to be, but not sure that's guaranteed). I also need screen recording permission, unfortunately, as it gives my app much more than it needs. My alternative is AppleEvents with the temporary exemption (which I think still applies, as there’s no alternative).

In my case, all I need is the window title for the frontmost Terminal.app window (and ideally, any other terminal emulator a user might use, like iTerm2). I don't need to control anything or record the screen.

I may have solved my problem. I just discovered the "Associated Domains Development" setting in Settings, and turned that on, and suddenly the phone fetched the AASA file directly.

When I try it, I get "'module' is inaccessible due to 'internal' protection level". I do see that it's being generated for one of my project's dependencies (in this case, it's a Vapor project, and the module that code completion jumps to is in in swift-crypto’s DerivedSources folder). UPDATE: Seems I had a malformed Package.swift (a missing comma), and instead of showing the error, Xcode just choked on compiling my test code. Running swift-test on the command line revealed this.

Where is Bundle.module defined?

After a lot of tinkering, I came upon a solution. Not sure if all of this is necessary: Only initialize the full stack if not in a SwiftUI preview. This was gross, relying on a runtime environment variable. Create a simple NSPersistentContainer when using in-memory store for previews and unit tests Only call setQueryGenerationFrom(.current) for the "real" stack, not the preview stack. This last one was key.

Thank you. It sounds like the best approach is to start with a standard/traditional Core Data stack and "migrate" to Swift Data from there.

Oh thank you, @DTS Engineer, that's helpful. Yes, I meant UICloudSharingController. I had completely failed to remember ShareLink, not realizing it works for this case. Ideally, I'd be able to use SwiftData for the bulk of my local objects, but afaik there’s no direct support for CKShare in SwiftData. Can you tell me if I have to create the Core Data stack from scratch, or can I insert the necessary bits (e.g. all the descriptions and options for shared zones, etc.) into the stack created by the Swift Data APIs?