SwiftUI Data Flow in iOS 17 - Observation & @Observable
Vložit
- čas přidán 25. 06. 2023
- Go to squarespace.com/seanallen to save 10% off your first purchase of a website or domain using code SEANALLEN.
iOS 17 introduces the new Observation Framework as well as the @Observable macro. This is a new an improved way to update your UI when underlying data of a model object changes and the concept of @StateObject and @ObservedObject no longer apply. This has cleaner syntax and better performance so it is a welcomed update.
This tutorial was created using Xcode 15 beta 2 and iOS 17.
My iOS Dev Courses:
seanallen.teachable.com/
WWDC Session on @Observable:
developer.apple.com/videos/pl...
Twitter:
Sean Allen - / seanallen_dev
Hired.com:
hired.com/x/1n01g
Book and learning recommendations that help out the channel if you decide to purchase (Affiliate Links):
Paul Hudson's Hacking With Swift:
gumroad.com/a/762098803
Donny Wals - Combine:
gumroad.com/a/909014131
Mark Moeyken’s SwiftUI Books:
www.bigmountainstudio.com/swiftui-views-book/fzc51
Objc.io Books (Thinking in SwiftUI & Advanced Swift):
gumroad.com/a/656585843
#swift #softwaredeveloper #iosdeveloper - Věda a technologie
My iOS Dev Courses (SwiftUI & UIKit) - seanallen.teachable.com
This video made me think how far Xcode has come; from the days of coding everything in Objective-C, to the early days of storyboards, Simulator sometimes catching all the issues with an app before actually testing on a physical device. Apple has really hit their stride with Swift and SwiftUI.
While these changes might be a bit confusing for us "veteran developers", I believe this new syntax is much nicer than before.
It will take a bit to get used to, but I agree. This is much better.
how exactly is this confusing since it just eliminates unnecessary and doesn't add any extra code?
I see problem here about we have to set init values, Prefer constants way
Very good update! Thanks for sharing!
I hope SwiftUI will let us use the .toolbar modifier without needing a NavigationView sometime soon.
Great Video of the new SwiftUI update Sean! Thank you so much. Keep going 🎉 I need such videos because they are short and explain core changes as I'm so busy 😂
Thanks Donat! That's why I make them. A lot of people don't have time to study the WWDC videos so I make short and to the point summaries.
Thank you for this video Sean! That’s going to help a bunch
Thinks for sharing!
Can you help to explain a bit more about adding @State against no wrapper at all when declaring an @Observable class variable in a view?
Wow this just made my life easier as I’m learning SwiftUI and building an app for the first time.
Glad it helped!
I am new to programming as well, and this whole @StateObject and @ObservableObject was confusing to me. I don’t know how many articles I’ve read and videos I’ve watched. But that seems simpler. I am heading back to the drawing board.
Beautifully explained!
Glad you enjoyed it!
Swift - constant improvements. It's nice to see that the language is evolving and so alive.
It's a gift and a curse. I agree, it's nice to see it evolving and improving. But stability is also valuable.
Nicely explained-as usual.
Glad you liked it!
I hope SwiftUI will become stable in my lifetime
This is fair.
Swift is developing quickly! And it will be around for a generation…
OH MY GOD, THANK YOU for this video. I was doing everything BUT importing Observation (is it in the docs or a WWDC video?)
It's in the Docs, but in the WWDC video they import Swift Data (which imports Observation)
Nice and clean
💪
Any thoughts on how the new changes with @Observation will affect using ViewModels or reinforce not using ViewModels? I think it will depend, but I think it would be great to see how @Observation would impact one of your more involved MVVM projects.
Also, love your videos, thanks for all the content!
I don't think this will have any affect on the view models vs. no view models debate. The way I see it, it's just a cleaner, more performant way to do something we've already been doing. It's not a fundamental ideological change on updating the UI.
What’s the difference between using @Published and the attribute .onchange with the same var ?? With onchange I can also apply update to the UI only when there is need to
Thanks for the excellent video. My SwiftUI app have this design pattern:
view model
the view model has @Published and non published properties along with business and helper methods that support the view, the model doesn't have @Published properties, now if I want to adopt the new @Observable macro, is it a best practice to take off the "view model" and migrate all of its business logic into the model itself ?
There would be no way with this approach to avoid tracking one or more attributes of a class as you mentioned. Although new syntax is arguably cleaner, we are losing a functionality from previous ObservableObject way to go… i d add a @notupdatable like macro to attributes i dont need to update in the ui, or something like that, or just stick to ObservableObject. Thank you for pointing out this new feature !
Your videos are awesome! Can you do a video on SwiftData as well and how it compares to CoreData?
Thanks. That video is coming in a few weeks. I haven't started wrapping my head around SwiftData yet.
@@seanallen As long as it is coming in the future, it makes me happy!!!
Is it only possible to use it on iOS 17? Isn't it possible for previous versions?
These changes and the whole SwiftData overhaul makes me want to wait for all of it to get out of beta.
Thankfully until now it seems that it won’t be forced to macOS Sonoma right? That risk I won’t take for sure short term release.
Looks good at first, but how do I react to changes in my business logic? Let’s say the filter changes and I want to run a REST call or execute any other business logic.
when you selected all the @Published text at once how did you do that? what do you have to hold / tap on the keyboard? that's cool
found it, you hold the option key
Thanks, wondered the same thing xD
how cool is that :)
Pretty cool
Nice, I like the cleaner syntax. Do these features ever get backported to older iOS versions?
I'm building a new app, which is currently targeting iOS 15 (I think it was... )
No, its iOS 17+ now
@@gmikay Great, thanks - I'll stick to the old method for now then :)
When I was learning SwiftUI last year, a lot of articles would say to prefer structs over classes. With iOS 17 and the new @Observable macro, does this represent a shift away from preferring structs over classes and instead choosing classes for view models, all else being equal?
structs over classes is good advice, but not absolute. Classes are necessary for a lot of model objects (even before this change). The new Observation framework and @Observable changes nothing in that regard.
Looks like this is more for observing an existing object... I would keep the older syntax for clarity... I don't agree it's more readable.... It obfuscates the use of that variable in your swiftUI view.... Forcing you to check through the view as to it's use.. That is to say "Is this observable?"... You clearly know if you have a @stateObject declaration... Very cool that you can see what the macro's are doing.... that's a killer feature. Also if performance is actually improved... That's kind of regrettable having to chose between more verbose syntax and faster execution.
I see your point about readability and not being sure if your variable on the view is being observed. You kinda just have to "know" that object is marked @Observable - and that could be confusing. Especially in a large codebase with a larger team.
@@seanallen yeah exactly... In the quest for cleanliness we lose some things... Of course.. as devil's advocate... One should avoid larger views entirely as the compiler will do the heavy lifting of code optimization... I do like how much work is being put into swift[UI] to improve it's usefulness. Keep up the great videos!
Sean how do you use @MainActor with thses new way i keep getting errors when i try to put an Observable on the main queue, this didnt happen before
I think you still need @State for data that is owned by the view and not provided from the outside.
Correct.
how did you select the published with the mouse and deleted it?
It's vertical selection in Xcode. I have a CZcams Short about it here - czcams.com/users/shorts6mWo5XHkEWo?feature=share
3:02 how did he select a box like this? A keyboard shortcut?
holding the "option" key
How about the $ sign? do we need it in TextField or other Two way Binding?
This video doesn't address Bindings and the new @Bindable. It is focused on @Observable. But, yes... the way Bindings are handled has changed a bit if you are using the new @Observable. I have a video on that planned.
@@seanallen Do you happen to have a mailing list? I'd love to know when you release this new @Bindable video, as you've explained @Observable so well (newbie here). Or best to just check back here?
I don't have a mailing list, so it's best to check back here from time to time (or subscribe)
Any word on when Swift Playgrounds is getting iOS 17 support?
No idea.
So basically you don’t need to mark @State for reference types in views as long as the type itself is marked @Observable? I kinda wish it was uniform in requiring @State for value and reference types hmm
@State isn't changing. It works exactly the same. You no longer need @StateObject (or @ObservedObject) when using @Observable.
i see, i click, i like, i comment.
I appreciate it.
Sean, may you please tell me one thing. If i want to start creating apps that target IOS17 and above only, so no need to support legacy code, can i use Swiftui for highly customizable app? The things i want to customize are, custom layouts of any imagination i can think of, complex navigation like uikit, customizing tab bar, navigation bar and so forth. Can swiftui accomplish all of this ?
SwiftUI can accomplish that, but you'd be fighting against the framework. The strength of SwiftUI is the ease of using Apple's components. If you want to customize every little thing, then UIKit is probably the correct framework to go with.
@@seanallen but it is possible right? Just composing custom stuff with simpler built in SwiftUI views? Also, if I plan to target iOS 17 and above, then I don’t need UIKit right? SwiftUI has me covered?
It is possible, yes
I don't see the WWDC link in the description box. How can I get that?
I'll make sure to add it. But here it is - developer.apple.com/videos/play/wwdc2023/10149/
No more Preference and Environment keys.
SolidJS is bringing the magic of signals everywhere
how did you select the code like in 3:00?
Hold option and drag
Sadly, it works only on ios 17 apps.
Is it difficult for Apple to make it functional for previous iOS?
And again, iOS 17, maybe in 2-3 years we will be able to use it. But knowing Apple, after this time, they can deprecate this API 🤦♂
Oh boy. If only Swift worked outside Apple :/
.NET has a superior broadcast model.
I assume you're referring to SwiftUI not Swift, Swift is an open source project that can be used on various other operating systems and for other needs.
@@georgebarlowr yes and no. I wish we could develop websites with swift ui for example, but even if swift is open source, most people doesn’t use it outside apple, and we need a community for a tech to get traction. Would be cool to be used as node is for example by companies
@@bobweiram6321 not my thing. I did program a little bit of C# in the past though. Not bad, not great either.
@@danvilela Swift e un lingua muito complicado e mal desiniado!