WWDC 2023 - Swift Macros and Data

[TC72]

Just wondering how everyone feels about the huge announcements at WWDC?

I laughed a lot to see them use macros which left just environment and state. Obviously these are brand new so nobody's had a chance to do much with them but I think they could be a huge boost to implementing systems like TCA.

Making use of Macros is Swift Data, the promise of simple data storage for Swift UI apps without getting your hands dirty with core data and cloudkit. This is handled by a macro so hopefully if there are any parts of it which aren't compatible with TCA it'll be possible to change the macro to suit.

What does everyone think? I'm just off to sell a kidney ready for the launch of Vision Pro in the UK some time in 2025. 😂

P.S. We'll be getting more info on both of these at sessions today:

[mariob]

Yeah, I'm really excited to try out SwiftData. If you only need a struct to conform to Codable to be able to persist and do queries, that would be awesome.

The whole macro thing seems to open up really great ways to simplify and make things more ergonomic. I was smiling when they had a macro to create a URL from a string without having to put an '!' at the end 😀. I also wonder if macros can make TCA even more ergonomic, for example when it comes to scoping, it would be nice to just have to specify the child feature datatype, but not sure if that's possible to do with a macro.

I really like that they have an 'Observable' annotation now. The view can use any of the properties from such class and the change notification will only come for those properties that the view is actually consuming. I wonder if TCA can use this to get rid of the 'observe' param you need to specify.

I already sold my kidney yesterday before I say the availabliity date 🤣

[fabstu]

How do you distinguish between persistent state and navigation state?

I've got that issue already with having a feed of items (persisted) that I have to scope into using 3 levels of SwitchStore. Would that work better using Data?

[TC72]

The Tuesday sessions are available, including what's new in Swift, Swift UI and sessions for macros and swift data:
https://developer.apple.com/wwdc23/sessions/

[TC72]

I'm not sure if Swift Data will be compatible with TCA out of the box. After watching Apple's videos it seems like using @Model to use Swift Data automatically uses its new observable system.

SwiftData supports the all-new observable feature for your modeled properties. SwiftUI will automatically refresh changes on any of the observed properties.

This automatically does things like publish all the variables and handles changes being propagated to views.

My understanding of TCA isn't very good so I might be getting this wrong. This chart from their video on observation shows how data can be used with observable:

[kamcma]

My initial thought is that neither @Observable nor @Model will be immediately, directly applicable from the perspective of users of TCA. Both require their attached declarations to be classes, not value types. [Edit: apparently not true of @Observable, so I retract that.]

In the case of @Model, this means those models are not appropriate to use directly in TCA state, which must be value types. Now, if you like the SwiftData API, you could still implement your persistence client with SwiftData, but you would need to copy your data out of @Model reference types before returning them to into TCA state, and you'd be knowingly forfeiting much of the change-tracking stuff that comes with these kinds of ORMs. (ORMs are, in general, very effectful frameworks and are an impedance mismatch, or least quite constrained, in unidirectional UI architectures like TCA.)

In the case of @Observable, the library itself may be able to use that to improve the implementation of ViewStore, which is currently an ObservableObject. But again, not something you as a user would mark your state with, because your state must be value types.

[lightandshadow68]

@Observable could alleviate issues with updating unreferenced state with WithViewStore in SwiftUI Views. I don't think it would remove the need for the observe: parameter, as there are use cases beyond performance. And you can still might want to slice off a bit of state, as a feature could have several collections of row data.

SwiftData @Query , etc. exposes persistence details to the view. Those details are usually implemented in Effects called from a Reducer.

Unfortunately, SwiftData doesn't support returning query results as structs. And, it's unclear how we could "add" a value type to a context, beyond implementing Identifiable and passing in a different value type with the same ID to update. Uniquing, etc. simply wouldn't make sense. Then again, things like uniquing can enable an entire class of bugs. Normally, I'd consider leaking stored models outside an effect an anti-pattern. But if they were effectively identical as a value types after being transformed using @Model this might be acceptable with trivial models.

While SwiftData doesn't provide this, it might make developing a framework that does around it easier than CoreData.

[arasan01]

I personally think that a closer look at the Swift Macros announcement could easily create a good way to write Shared State. The current TCA CaseStudies include a Shared State that handwrites getter and setter. This is a straightforward approach but quickly becomes intolerable boilerplate. This is exactly where Macros comes in!

[TC72]

Yes, I think TCA could make use of macros to make it even more powerful and easier to work with.

[mariob]

Yes, and it would be great if the macro could cache the value because sometimes the getter is called quite often and it could be "expensive" depending how you assemble the child state from the parent state.

[TC72]

The latest session on creating an App with Swift Data is available:
https://developer.apple.com/wwdc23/10154

An another looking into schema:
https://developer.apple.com/wwdc23/10195

I am so torn right now. I've been spending a few months learning TCA. I have one App on the app store already built with Swift and then updated for Swift UI. I have ideas for another 4 apps but they will all rely on using iCloud for data storage.
I like TCA as It's just my son and myself working on the apps and the TCA flow along with testing could help us a lot, but Swift Data with @model and @query look like they could take care of a lot of complicated data storage for us.
I haven't seen any examples of using TCA with Core Data and CloudKit, I need to work out what's involved.

I think macro libraries will be open to work on so it might be possible to have a TCA implementation of Swift Data that uses the backend parts without the observable parts.

[mbrandonw]

Hi everyone, sorry for the delay in response. We were busy this week recording new episodes.

We’ve spent a little bit of time exploring some of the new tools, but it is far too early to make any concrete statements. There are a lot of exciting things to consider. For one, macros are certainly going to help out the case path situation for us, though we still do hope someday Swift has first class support for the concept.

Macros are also going to be applicable to dependency design and dependency management, parsing, and a whole bunch more.

And then of course we want to be able to support things like @Observable and @Model in TCA. We don’t have any concrete details, but hopefully @Observable alleviates the need for view stores. And at the very least @Model is probably immediately usable in dependencies, but using directly in state is going to of course be tricky because it is largely still built on reference types.

So, we hope everyone can be patient as we digest things and explore, and we also hope everyone shares their own explorations to see what is possible. For what it’s worth, this is pretty similar how things went last WWDC (20222) when NavigationStack was announced. A discussion was started the first day it was announced and it wasn’t until just last week that we released the final version of navigation stacks that works with TCA.

I’m sure there are going to be a lot of explorations, a lot of false starts, and a lot of re-thinking of things. At the end of the day TCA is all about writing applications in a consistent manner with modularity, effects management, testing, and ergonomics in mind. These are the principles we want to always build upon, and let the library evolve however it needs to live up to those ideals and play nicely in Apple’s ecosystem.

[DandyLyons]

I'm using the same approach that @SouzaRodrigo61 started in their SwiftDataTCA repo. Not using @Query at all.

We create a swift data dependency and a dependency for each model and that's all of the communication between TCA and SwiftData. No need for a .bind.

I'm liking it so far.

[mbrandonw]

SwiftData should work in TCA in the sense that changes to a SwiftData model will cause the view to re-render even though it's a reference type, which prior to Observation was not the case. But, testing SwiftData models in state is going to be very tricky. You can't perform exhaustive testing since the models are reference types. At best you can only assert on individual fields of the model after an action is sent.

[SouzaRodrigo61]

@DandyLyons I'm building an application following the SwiftDataTCA concept that I developed, and it's been working well so far. Without the need for @Query, all queries are performed using the SwiftData concept for UIKit.

https://github.com/SouzaRodrigo61/cashew

In a part of the code, I have data retrieval done like this:

return .run { send in
    let data = try loadData()
    
    await withTaskGroup(of: Void.self) { group in
        group.addTask {
            await send(.taskResponse(.success(data)), animation: .default)
        }
        
        group.addTask(priority: .background) {
            await self.startTimer(send: send)
        }
    }
} catch: { error, send in
    await send(.taskResponse(.failure(error)), animation: .default)
}

For the fetch part, I do it like this. In my case, I don't have much need to add various validations, and I leave all control flow to TCA.

fetch: {
    do {
        @Dependency(\.modelContext.context) var context
        let movieContext = try context()
        
        let descriptor = FetchDescriptor<Task.Model>()
        return try movieContext.fetch(descriptor)
    } catch {
        return []
    }
},

[GierlJn]

Are there any new ideas on how we can get the changes submitted by the @Query macro to TCA State?

[stephencelis]

@GierlJn @Query only works in views, so you could add an onChange(of: self.query) to feed updates into TCA.