AMARTI
@amarti.music
Dextr: Contacts Reimagined now available:
hspec.io/dextr
DJ / Producer / Software Engineer
music stuff: amarti.bio
software stuff: hspec.io
🇺🇦
hspec.io/dextr
DJ / Producer / Software Engineer
music stuff: amarti.bio
software stuff: hspec.io
🇺🇦
IIRC from one of the WWDC 25 videos the intention is to have devs move away from text to iconography wherever possible in nav elements
July 27, 2025 at 1:46 AM
IIRC from one of the WWDC 25 videos the intention is to have devs move away from text to iconography wherever possible in nav elements
Yea exactly, & there isn't a way reconcile that queue with the a normal actor's serial executor without ditching NSManagedObjectContext. SwiftData in iOS 18 moved a lot of stuff to interact with the store directly vs routing through CoreData, so it's possible iOS 19 will take that further
May 19, 2025 at 6:02 PM
Yea exactly, & there isn't a way reconcile that queue with the a normal actor's serial executor without ditching NSManagedObjectContext. SwiftData in iOS 18 moved a lot of stuff to interact with the store directly vs routing through CoreData, so it's possible iOS 19 will take that further
I think you're right. Been a while since I've messed with CoreData
May 19, 2025 at 5:47 PM
I think you're right. Been a while since I've messed with CoreData
I'm not really sure how they implicitly "added" nonisolated to all functions of a ModelActor, but my guess is the ModelActor extension with unownedExecutor is setup in such a way that this happens
May 19, 2025 at 5:46 PM
I'm not really sure how they implicitly "added" nonisolated to all functions of a ModelActor, but my guess is the ModelActor extension with unownedExecutor is setup in such a way that this happens
`nonisolated` actor functions (or in this case the executor) will always run on the thread (or task context) they're invoked from. You can try adding nonisolated to a regular actor function to see this in action
May 19, 2025 at 5:32 PM
`nonisolated` actor functions (or in this case the executor) will always run on the thread (or task context) they're invoked from. You can try adding nonisolated to a regular actor function to see this in action
It's likely nonisolated because it has to manage NSManagedObjectContext on a single thread behind the scenes, which doesn't really jive with how actors work
May 19, 2025 at 5:19 PM
It's likely nonisolated because it has to manage NSManagedObjectContext on a single thread behind the scenes, which doesn't really jive with how actors work
And actually this isn't anything to do with ModelExecutor, it's just because it's marked nonisolated, so it doesn't require the actor's isolation for operations
May 19, 2025 at 5:11 PM
And actually this isn't anything to do with ModelExecutor, it's just because it's marked nonisolated, so it doesn't require the actor's isolation for operations
Testing your example, I see what you're talking about. Appears to be how the ModelExecutor was designed (always executing functions on the thread it's called from). This only appears to be an issue with SwiftUI's .task {} though. This works:
.task {
Task.detached { modelActor.hello() }
}
.task {
Task.detached { modelActor.hello() }
}
May 19, 2025 at 5:05 PM
Testing your example, I see what you're talking about. Appears to be how the ModelExecutor was designed (always executing functions on the thread it's called from). This only appears to be an issue with SwiftUI's .task {} though. This works:
.task {
Task.detached { modelActor.hello() }
}
.task {
Task.detached { modelActor.hello() }
}
Tested `preconditionIsolated()` on one of the functions, and execution doesn't stop
`MainActor.preconditionIsolated()` will, but the ModelActor obviously isn't running on MainActor's serial executor
`MainActor.preconditionIsolated()` will, but the ModelActor obviously isn't running on MainActor's serial executor
May 19, 2025 at 4:43 PM
Tested `preconditionIsolated()` on one of the functions, and execution doesn't stop
`MainActor.preconditionIsolated()` will, but the ModelActor obviously isn't running on MainActor's serial executor
`MainActor.preconditionIsolated()` will, but the ModelActor obviously isn't running on MainActor's serial executor
That said, my ModelActors are created on App init / main thread and it appears their work happens on background thread. Going to check now to see if when it accesses their ModelContext something is still hitting the main thread...but I don't think so
May 19, 2025 at 4:34 PM
That said, my ModelActors are created on App init / main thread and it appears their work happens on background thread. Going to check now to see if when it accesses their ModelContext something is still hitting the main thread...but I don't think so
Reading your blog again, ModelActors could be sensitive to where they're created because of ModelContext (which is a wrapper around NSManagedObjectContext, which are bound to the thread they're created on).
May 19, 2025 at 4:32 PM
Reading your blog again, ModelActors could be sensitive to where they're created because of ModelContext (which is a wrapper around NSManagedObjectContext, which are bound to the thread they're created on).
In any case, ModelActor is meant for long write operations (or other non-UI interacting work) unless you use Sendable DTOs for fetching. @Query will automatically update your view/models when a ModelActor makes changes to the store
May 19, 2025 at 4:01 PM
In any case, ModelActor is meant for long write operations (or other non-UI interacting work) unless you use Sendable DTOs for fetching. @Query will automatically update your view/models when a ModelActor makes changes to the store
Using @State could lead to multiple inits of the actor. Usually good practice to create actors during App init and pass via .environment() (or use a singleton)
You might be right about the executor, iirc I did see times ModelActor operating on the main thread which might be what I'm thinking of
You might be right about the executor, iirc I did see times ModelActor operating on the main thread which might be what I'm thinking of
May 19, 2025 at 3:34 PM
Using @State could lead to multiple inits of the actor. Usually good practice to create actors during App init and pass via .environment() (or use a singleton)
You might be right about the executor, iirc I did see times ModelActor operating on the main thread which might be what I'm thinking of
You might be right about the executor, iirc I did see times ModelActor operating on the main thread which might be what I'm thinking of
From a quick read through, obv using ModelActor (or any actor) as a @State param is going to cause issues. Actors ensure functions and state modifications are executed serially, but make no guarantees about the thread they’re run and can still tie up the main thread if that’s where they’re called
May 19, 2025 at 2:40 PM
From a quick read through, obv using ModelActor (or any actor) as a @State param is going to cause issues. Actors ensure functions and state modifications are executed serially, but make no guarantees about the thread they’re run and can still tie up the main thread if that’s where they’re called
Not at all! I find it easier to create a local Swift Package (ie, just lives inside the project) than messing with XCFrameworks. They also can be opened on their own, which allows you to work with that code only—speeding up builds / Previews later down the road when your project gets larger!
May 19, 2025 at 2:05 PM
Not at all! I find it easier to create a local Swift Package (ie, just lives inside the project) than messing with XCFrameworks. They also can be opened on their own, which allows you to work with that code only—speeding up builds / Previews later down the road when your project gets larger!
Hmm, not with ModelActor. You have an example of the type of issue you’ve run into?
May 19, 2025 at 1:53 PM
Hmm, not with ModelActor. You have an example of the type of issue you’ve run into?
I built Dextr.app using SwiftData
ModelActors are key for complex apps
Knowing SwiftUI view identity & how to breakdown views is crucial to avoid unnecessary context reads when working with large datasets
The docs def leave a lot out!
Aiming to blog about what I learned when I have downtime 😊
ModelActors are key for complex apps
Knowing SwiftUI view identity & how to breakdown views is crucial to avoid unnecessary context reads when working with large datasets
The docs def leave a lot out!
Aiming to blog about what I learned when I have downtime 😊
Dextr: Contacts Reimagined
Meet Dextr, the app to effortlessly manage your personal connections. Remember people you meet, capture important details, and easily visualize your social network. Beautifully designed and privacy-f...
Dextr.app
May 19, 2025 at 7:43 AM
I built Dextr.app using SwiftData
ModelActors are key for complex apps
Knowing SwiftUI view identity & how to breakdown views is crucial to avoid unnecessary context reads when working with large datasets
The docs def leave a lot out!
Aiming to blog about what I learned when I have downtime 😊
ModelActors are key for complex apps
Knowing SwiftUI view identity & how to breakdown views is crucial to avoid unnecessary context reads when working with large datasets
The docs def leave a lot out!
Aiming to blog about what I learned when I have downtime 😊
Swift Packages within your project is the easiest way to share code between targets!
May 5, 2025 at 6:22 PM
Swift Packages within your project is the easiest way to share code between targets!
You want to set fixedSize on the opposite axis you’re trying to solve for. So to ensure Text expands down, set .fixedSize to .horizontal
April 15, 2025 at 3:54 PM
You want to set fixedSize on the opposite axis you’re trying to solve for. So to ensure Text expands down, set .fixedSize to .horizontal
The US bonds sell off is by far the most worrying. I’m no economist, but if they become an unattractive investment we’re going to have an ugly reckoning with our little debt problem
April 11, 2025 at 9:45 PM
The US bonds sell off is by far the most worrying. I’m no economist, but if they become an unattractive investment we’re going to have an ugly reckoning with our little debt problem