Hi, folks. I know that in the new observation, class property changes can be automatically notified to SwiftUI, which is very convenient. But in the new observation framework, how to monitor the property changes of different model classes? For example, class1 has an instance of class2, and I need to notify class1 to perform some actions and make some changes when some properties of class2 are changed. How to do it in observation? In the past, I could use combined methods to write the second part of the code for monitoring. However, using the combined framework in observation is a bit confusing. I know this method can be withObservationTracking(_:onChange:) but it needs to be registered continuously. If Observation is not possible, do I need to change my design structure? Thanks. // Observation @Observable class Sample1 { var count: Int = 0 var name = "Sample1" } @Observable class Sample2 { var count: Int = 0 var name = "Sample2" var sample1: Sample1? init (sample1 : Sample1) { self.sample1 = sample1 } func render() { withObservationTracking { print("Accessing Sample1.count: \(sample1?.count ?? 0)") } onChange: { [weak self] in print("Sample1.count changed! Re-rendering Sample2.") self?.handleSample1CountChange() } } private func handleSample1CountChange() { print("Handling count change in Sample2...") self.count = sample1?.count ?? 0 } } // ObservableObject class Sample1: ObservableObject { @Published var count: Int = 0 var name = "Sample1" } class Sample2: ObservableObject { @Published var count: Int = 0 var name = "Sample1" var sample1: Sample1? private var cancellables = Set<AnyCancellable>() init (sample1 : Sample1) { self.sample1 = sample1 setupSubscribers() } private func setupSubscribers() { sample1?.$count .receive(on: DispatchQueue.main) .sink { [weak self] count in guard let self = self else { return } // Update key theory data self.count = count self.doSomeThing() } .store(in: &cancellables) } private func doSomeThing() { print("Count changes, need do some thing") } }

When I run my app with XCode on my iPhone, and then moved into the background, I'm getting a EXC_BREAKPOINT exception after a few minutes, seemingly when iOS attempts to call my app with a BGAppRefreshTask: Thread 23 Queue: com.apple.BGTaskScheduler (com.mycompany.MyApp.RefreshTask) (serial) 0 _dispatch_assert_queue_fail 12 _pthread_wqthread Enqueued from com.apple.duet.activityscheduler.client.xpcqueue (Thread 23) 0 dispatch_async 20 start_wqthread I can't quite understand the reason from this crash. In the background task, I'm attempting to update live activities. In the process, it might encounter code that calls MainActor and manipulate @Observable objects. Might that be the reason?

I must admit my knowledge of swift is limited, and I cannot wrap my head around this problem. I've defined this protocol, so I can use different auth providers in my app. protocol AuthRepository { associatedtype AuthData associatedtype AuthResponseData associatedtype RegistrationData associatedtype RegistrationResponseData func login(with data: AuthData) async throws -&gt; AuthResponseData? func register(with data: RegistrationData) async throws -&gt; RegistrationResponseData? } and an implementation for my server struct MyServerAuthData { let email: String let password: String } struct MyServerAuthResponseData { let token: String } struct MyServerRegistrationData { let email: String let password: String let name: String } actor AuthRepositoryImpl: AuthRepository { func login(with data: MyServerAuthData) async throws -&gt; MyServerAuthResponseData? { ... } func register(with data: MyServerRegistrationData) async throws -&gt; Void? { ... } } To use across the app, I've created this ViewModel @MainActor final class AuthViewModel&lt;T: AuthRepository&gt;: ObservableObject { private let repository: T init(repository: T) { self.repository = repository } func login(data: T.AuthData) async throws -&gt; T.AuthResponseData? { try await repository.login(with: data) } func register(with data: T.RegistrationData) async throws { try await repository.register(with: data) } } defined in the app as @main struct MyApp: App { @StateObject var authViewModel = AuthViewModel(repository: AuthRepositoryImpl()) var body: some Scene { WindowGroup { ContentView() .environmentObject(self.authViewModel) } } } and consumed as @EnvironmentObject private var authViewModel: AuthViewModel&lt;AuthRepositoryImpl&gt; But with this code, the whole concept of having a generic implementation for the auth repository is useless, because changing the AuthRepostory will need to search and replace AuthViewModel&lt;AuthRepositoryImpl&gt; across all the app. I've experienced this directly creating a MockAuthImpl to use with #Preview, and the preview crashed because it defines AuthViewModel(repository: MockAuthImpl()) but the view expects AuthViewModel. There is a better way to do that?

Hi I am developing an app for counting money. One view is for entering the intended destinations specified by a donor. Each destination has a row with a TextField that has an OnChange to keep it all numeric. The model that holds the data is a class called AllocationItems, which I recently changed from having the protocol ObservableObject to having the macro @Observable. It mostly works the same, except that before with each key stroke the total would be updated, but now with the macro it only gets updated when I exit the current TextField by clicking on another TextField How do I get it to update the total with each keystroke? The code that shows the total is this: Text(allocations.totalAllocated.fmtCurrency) where allocations is an instance of AllocationItems with this definition: var totalAllocated: NSDecimalNumber { items.reduce(.zero) { $0 + $1.amountValue } } I hope someone knows why this has changed and can suggest a simple fix.

When I switched to observable, I noticed a strange behavior of the ViewModel. The ViewModel is created 3x times. And my question is: How to properly initialize the ViewModel via state? Below is a minimal example with log output: ViewModel INIT : EBBB2C41 ViewModel INIT : D8E490DA ViewModel INIT : 54407300 ViewModel DEINIT: D8E490DA @Observable final class ViewModel { @ObservationIgnored let idd: UUID init() { idd = UUID() print("ViewModel INIT : \(idd.uuidString.prefix(8))") } deinit { print("ViewModel DEINIT: \(idd.uuidString.prefix(8))") } } struct SimpleView: View { @Environment(ViewModel.self) private var viewModel var body: some View { @Bindable var viewModel = viewModel Text("SimpleView: \(viewModel.idd.uuidString.prefix(8))") } } struct ContentView: View { @State private var viewModel = ViewModel() var body: some View { SimpleView() .environment(mainViewModel) } }

I'm in the process of migrating to the Observation framework but it seems like it is not compatible with didSet. I cannot find information about if this is just not supported or a new approach needs to be implemented? import Observation @Observable class MySettings { var windowSize: CGSize = .zero var isInFullscreen = false var scalingMode: ScalingMode = .scaled { didSet { ... } } ... } This code triggers this error: Instance member 'scalingMode' cannot be used on type 'MySettings'; did you mean to use a value of this type instead? Anyone knows what needs to be done? Thanks!

I'm having the following issue: Type 'AVPlayer.Type' cannot conform to 'ObservableObject' struct MusicEditorView: View { @ObservedObject var audioPlayer = AVPlayer and this is the class: class MusicPlayer: ObservableObject { private var audioPlayer: AVPlayer? private var timer: Timer? func playSound(named sFileName: String){ if let url = Bundle.main.url(forResource: sFileName, withExtension: "mp3"){ audioPlayer = try? AVPlayer(url: url) audioPlayer?.play() } } func pause(){ audioPlayer?.pause() } func getcurrentProgress() -&gt; Double{ guard let currentTime = audioPlayer?.currentItem?.currentTime().seconds else { return 0 } guard let duration = audioPlayer?.currentItem?.duration.seconds else { return 0 } return duration &gt; 0 ? (currentTime / duration) * 100 : 0 } func startProgressTimer(updateProgress: @escaping (Double, Double) -&gt; Void){ timer?.invalidate() timer = Timer.scheduledTimer(withTimeInterval: 1.0, repeats: true) { _ in guard let currentTime = self.audioPlayer?.currentItem?.currentTime().seconds else { return } guard let duration = self.audioPlayer?.currentItem?.duration.seconds else { return } updateProgress(currentTime, duration) } } func stopProgressTimer(){ timer?.invalidate() } struct Sound: Identifiable, Codable { var id = UUID() var name: String var fileName: String } } }

I have a SwiftData model where I need to customize behavior based on the value of a property (connectorType). Here’s a simplified version of my model: @Model public final class ConnectorModel { public var connectorType: String ... func doSomethingDifferentForEveryConnectorType() { ... } } I’d like to implement doSomethingDifferentForEveryConnectorType in a way that allows the behavior to vary depending on connectorType, and I want to follow best practices for scalability and maintainability. I’ve come up with three potential solutions, each with pros and cons, and I’d love to hear your thoughts on which one makes the most sense or if there’s a better approach: **Option 1: Use switch Statements ** func doSomethingDifferentForEveryConnectorType() { switch connectorType { case "HTTP": // HTTP-specific logic case "WebSocket": // WebSocket-specific logic default: // Fallback logic } } Pros: Simple to implement and keeps the SwiftData model observable by SwiftUI without any additional wrapping. Cons: If more behaviors or methods are added, the code could become messy and harder to maintain. **Option 2: Use a Wrapper with Inheritance around swiftdata model ** @Observable class ParentConnector { var connectorModel: ConnectorModel init(connectorModel: ConnectorModel) { self.connectorModel = connectorModel } func doSomethingDifferentForEveryConnectorType() { fatalError("Not implemented") } } @Observable class HTTPConnector: ParentConnector { override func doSomethingDifferentForEveryConnectorType() { // HTTP-specific logic } } Pros: Logic for each connector type is cleanly organized in subclasses, making it easy to extend and maintain. Cons: Requires introducing additional observable classes, which could add unnecessary complexity. **Option 3: Use a @Transient class that customizes behavior ** protocol ConnectorProtocol { func doSomethingDifferentForEveryConnectorType(connectorModel: ConnectorModel) } class HTTPConnectorImplementation: ConnectorProtocol { func doSomethingDifferentForEveryConnectorType(connectorModel: ConnectorModel) { // HTTP-specific logic } } Then add this to the model: @Model public final class ConnectorModel { public var connectorType: String @Transient public var connectorImplementation: ConnectorProtocol? // Or alternatively from swiftui I could call myModel.connectorImplementation.doSomethingDifferentForEveryConnectorType() to avoid this wrapper func doSomethingDifferentForEveryConnectorType() { connectorImplementation?.doSomethingDifferentForEveryConnectorType(connectorModel: self) } } Pros: Decouples model logic from connector-specific behavior. Avoids creating additional observable classes and allows for easy extension. Cons: Requires explicitly passing the model to the protocol implementation, and setup for determining the correct implementation needs to be handled elsewhere. My Questions Which approach aligns best with SwiftData and SwiftUI best practices, especially for scalable and maintainable apps? Are there better alternatives that I haven’t considered? If Option 3 (protocol with dependency injection) is preferred, what’s the best way to a)manage the transient property 2) set the correct implementation and 3) pass reference to swiftdata model? Thanks in advance for your advice!

Recently I noticed how my ViewModels aren't deallocating and they end up as a memory leaks. I found something similar in this thread but this is also happening without using @Observation. Check the source code below: class CellViewModel: Identifiable { let id = UUID() var color: Color = Color.red init() { print("init") } deinit { print("deinit") } } struct CellView: View { let viewModel: CellViewModel var body: some View { ZStack { Color(viewModel.color) Text(viewModel.id.uuidString) } } } @main struct LeakApp: App { @State var list = [CellViewModel]() var body: some Scene { WindowGroup { Button("Add") { list.append(CellViewModel()) } Button("Remove") { list = list.dropLast() } ScrollView { LazyVStack { ForEach(list) { model in CellView(viewModel: model) } } } } } } When I tap the Add button twice in the console I will see "init" message twice. So far so good. But then I click the Remove button twice and I don't see any "deinit" messages. I used the Debug Memory Graph in Xcode and it showed me that two CellViewModel objects are in the memory and they are owned by the CellView and some other objects that I don't know where are they coming from (I assume from SwiftUI internally). I tried using VStack instead of LazyVStack and that did worked a bit better but still not 100% "deinits" were in the Console. I tried using weak var struct CellView: View { weak var viewModel: CellViewModel? .... } but this also helped only partially. The only way to fully fix this is to have a separate class that holds the list of items and to use weak var viewModel: CellViewModel?. Something like this: class CellViewModel: Identifiable { let id = UUID() var color: Color = Color.red init() { print("init") } deinit { print("deinit") } } struct CellView: View { var viewModel: CellViewModel? var body: some View { ZStack { if let viewModel = viewModel { Color(viewModel.color) Text(viewModel.id.uuidString) } } } } @Observable class ListViewModel { var list = [CellViewModel]() func insert() { list.append(CellViewModel()) } func drop() { list = list.dropLast() } } @main struct LeakApp: App { @State var viewModel = ListViewModel() var body: some Scene { WindowGroup { Button("Add") { viewModel.insert() } Button("Remove") { viewModel.drop() } ScrollView { LazyVStack { ForEach(viewModel.list) { model in CellView(viewModel: model) } } } } } } But this won't work if I want to use @Bindable such as @Bindable var viewModel: CellViewModel? I don't understand why SwiftUI doesn't want to release the objects?