You might instead consider the SwiftUI Contact Access Button (and if not using SwiftUI, use UIHostingViewController of the appropriate SwiftUI ContactAccessButtonView and .contactAccessPicker). See Meet the Contact Access Button and https://developer.apple.com/documentation/Contacts/accessing-a-person-s-contact-data-using-contacts-and-contactsui and https://developer.apple.com/forums/thread/756972.

@Alex_Lyu - FWIW, when the picker fires up (in iOS 18), it also says, “Private Access to Contacts – Your contacts are shown here, but "{app name}" can only access the contacts you select.” If your app saves details for contacts that they picked, you could add a UI for them to delete what contact info they’ve saved in your app. But the Contacts framework does not give your app persistent access to the contacts they selected (unless you went down the CNContactStore road).

If you look at the text below “Private Access”, it clearly tells your customer what this means: “This app can show your contacts, but can only access the contacts you select.” So, if a user tapped on a contact, the details of that contact have been shared with your app (and what you do with it is a matter of your own internal business practices). But if a user did not select a contact in the UI, you simply have no access. It's all right there in the line below “Private Access”.

@Praveenraj4256 – Yes, a detached task would do the job, too. But Quinn’s use of nonisolated async approach is preferable because it avoids unnecessary unstructured concurrency. In this case, the difference doesn’t matter too much (because it is non-cancelable work), but in general, remain within structured concurrency whenever you can.

@DTS Engineer – I get what you intended re your four options (ensure that the function is not isolated to the main actor) but for the sake of future readers, that alone is insufficient. A nonisolated synchronous function will just run on the current thread. I just wanted to draw readers attention to the key observation that you made this both nonisolated and async, to get it off the current actor.

@jasonnerothin “Kinda thinking out loud here, but what's to prevent this sort of implementation from "hosing the database"? I mean, who's in charge of transaction isolation?” The actor provides the mutual exclusion necessary. This is a fine pattern (once the ModelActor stuff is excised).

Note: A frequent flow consists of the use of MKLocalSearchCompleter for list of completions, and then when one is selectsd, then create a MKLocalSearch.Request from that. In that case, the above pattern introduces a problem that you no longer have a MKLocalSearchCompletion to pass to MKLocalSearch.Request. There are workarounds, so if you want to see example, let me know. Hopefully they will soon fix MKLocalSearchCompleter to support strict concurrency and avoid all this silliness.

The problem is that ModelActor inexplicably runs on the main thread. See https://forums.developer.apple.com/forums/thread/736226.

I take that back: The @ModelActor macro does indeed make them nonisolated properties. But I’m not quite sure why they’re nonisolated (other than to avoid problems stemming from this @ModelActor bug).

I think it’s broader than just the “hitches” instrument. I think “deferred” mode is broken for all instruments on physical devices. E.g., “Time Profiler” template manifests the same problem if you select “deferred” mode when profiling on iOS 18.1 physical device (but not simulator). I confess that I’ve only tested on iOS 18.1, but I don’t know if it applies to other iOS versions or not.

I do not believe that is true that you cannot use @Observable with @MainActor. If you share some of those links that made such claims, we can probably comment on those directly. You cannot (currently) use @Observable with actor types, but you can use it with classes that are isolated to a global actor (including the main actor).

I suspect he didn’t explicitly mention AsyncStream (or any AsyncSequence) because that falls under the banner of “stick with Swift concurrency”. I don’t think many would call it an “observation”, as it is a much broader pattern. But you are correct that there are parallels and it can be used to achieve observation-like behaviors.

@nestserau – Why the nonisolated properties? If you expand the @ModelActor macro, it doesn’t introduce nonisolated properties, so I am not sure why you would here.

Agreed on all counts. Thanks for taking the time to clarify!

I agree re concurrency not being the same thing as parallelism. But you appear to suggest that one cannot achieve parallelism with a task group. But we do (and we avoid the thread explosion issues of queue.async while simultaneously enjoying structured concurrency benefits). All of my recent computationally intensive and massively parallel tests demonstrate that task group performance is indistinguishable from concurrentPerform. Help me understand why not task group? I see no downside.