That’s exactly what I was looking for. I was assuming it was a separate property, not one tied to the event-concept. I’m actually already using the event-concept (which is how I rendered the colored events). Anyway, I posted a question on StackOverflow, too, (https://stackoverflow.com/questions/70600250/how-to-specify-symbol-character-in-os-signpost-point-schema/70659365#70659365) and have reposted your answer there. But obviously, if you’d rather post your own answer there to get the due credit, I’m happy to delete my answer and instead award you the bounty points! I’m happy either way.

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.

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

@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.

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.

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 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 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).

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

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.

@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).

@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.

@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.