DC iOS: SwiftUI Architecture and Best Practices

SwiftUI Architecture and Best Practices
Mohammad Azam
In this talk Azam will share his experience of when working with SwiftUI architecture. Azam will discuss best practices and patterns for working with SwiftUI framework.
Slides: bit.ly/44SIP81
Resources: azamsharp.com/swiftuilessons
You can find more out about our speaker and register for his Udemy classes here: www.udemy.com/user/mohammad-a...

[@withniyaz]

Never knew i was doing the exact way how Azam did and thought myself it was wrong until watching this video. Great talk ❤

[@jdotseven]

I like the thinking behind your presentation - have to consider it in the future. What are you using to align the closing braces visually?

[@wonton120]

For iOS 17 and the new Observation framework, this pattern will make sense. Also, for iOS17, the view will not be reloaded unless the view got changed.

[@islamISHere_001]

great video
thank you

[@pengwei4872]

Great talk! This is so similar to modern react, which is great!

[@mohammedrokonuddin7153]

Hi Azam, thank you for your beautiful SwiftUI Architecture and Best Practices talk. I have a question though. In the 50 minutes of Count example, you mentioned view whose state property doesn't change, it doesn't get recreated but rather reevaluated. But I tried setting random colors to Text. Every time when I press the Increament button the count increases and also color of Counter changes even though it is a static text. Can you explain that?

[@azamsharp]

Code example?

[@mohammedrokonuddin7153]

@@azamsharp
struct ContentView: View {
@State var count = 0
var body: some View {
let _ = Self._printChanges()
VStack {
Image(systemName: "globe")
.imageScale(.large)
.foregroundStyle(.random)
Text("Counter")
.font(.largeTitle)
.foregroundStyle(.random)
Text("\(count)")
Button("Increment") { count += 1 }
.frame(width: 124, height: 32)
.tint(.random)
.background(.random)
}
}
}
extension ShapeStyle where Self == Color {
static var random: Color {
Color(
red: .random(in: 0 ... 1),
green: .random(in: 0 ... 1),
blue: .random(in: 0 ... 1)
)
}
}

[@mohammedrokonuddin7153]

But if I refactor the code to following, it works fine:
struct ContentView: View {
@State var count = 0
var body: some View {
let _ = Self._printChanges()
VStack {
AnotherView()
.background(.random)
Text("\(count)")
Button("Increment") { count += 1 }
.frame(width: 124, height: 32)
.tint(.random)
.background(.random)
}
}
}
struct AnotherView: View {
var body: some View {
Image(systemName: "globe")
.imageScale(.large)
.foregroundStyle(.random)
Text("Counter")
.font(.largeTitle)
.foregroundStyle(.random)
}
}
extension ShapeStyle where Self == Color {
static var random: Color {
Color(
red: .random(in: 0 ... 1),
green: .random(in: 0 ... 1),
blue: .random(in: 0 ... 1)
)
}
}

[@azamsharp]

@@mohammedrokonuddin7153 The .random gets called during evaluation and the view gets redrawn.

[@davidlangley9287]

This feels so wrong to me, it's like going back to the beginning but instead of having massive view controllers, we now have massive... views???
For small personal projects or tutorials (like the ones you showed from Apple), this should be enough. But in real world applications where many developers are working in one app, this pattern won't let each other to safely edit a complex view. We use automatic tests for view models AND views because many developers might be working on a single view/feature, we can't just test manually or use xcode previews... anyways

[@azamsharp]

If you views are getting bigger then divide them into smaller views.

[@RomanRomanov1441]

You are totally right and we should never forget that Apple's suggestions in usage of their frameworks are good only for a 3 screens todo app. And thus should be ignored in favor of SOLID principles.

[@trendz4422]

Answer for Bigger apps at 28:00

[@pe60t0]

"I am going to test this manually" lost me :D

[@azamsharp]

I personally invest my time on writing tests for the domain logic.

[@shakil807g]

Exactly!! lol "I am going to test this manually"

[@trendz4422]

48:00 We can't run tests in parallel in this case, right?

[@RiccardoMontagnin]

You can actually use an in-memory database that is created with each test run. But if you use a real database, then yeah. In this case it's better to just mock the database

[@VinoKanan]

Can you please talk about The Composable Architecture.

[@gogugigi85]

Nice approach, not applicable in big projects also remind me the masive view controller and seems too permisive to where business logic resides, not so good for clarity on big projects, tutorial projects will be fine.

[@azamsharp]

On the contrary, I have completed several very large projects using this approach and it worked out very well. We were able to reduce at least 40% of the code by not creating VM for every single screen. Less code is always better.

[@gogugigi85]

@azamsharp how exactly it reduces 40% the code, the business logic is just moved somewhere else, if is not in the VM it in a Reducer or Presenter or Model or in the View(which is the worst), and in most cases when the business logic is not where expected it reduces code clarity. I have my concerns that this can be applied in large projects and improve the project.

[@pe60t0]

Also why “less code is always better” this is so wrong

[@narencool236]

We can create whole app in single file but that does not mean we should, same way we can write whole logic in view class sill it will work that does not mean we should

[@praveenvelanati9450]

Test manually lol :). This is not a good practice