SwiftUI Architecture, A11y, SwiftUI Charts, UICollectionView & More!

Swift News comes out every Monday - Subscribe or follow me on twitter to be notified of new episodes. In this episode we discuss architecture patterns for SwiftUI, Accessibility for your apps, some examples of charts for SwiftUI as well as custom modifiers. We also discuss some UICollectionViewCompositionalLayout and DiffableDataSource and some design ideas.

My new SwiftUI Fundamentals course is now available:

If you like my teaching style, I've started releasing my own courses:

Timestamps:
0:00 Intro, Links & #SwiftNews
0:24 SwiftUI Architecture
1:23 Accessibility
3:10 SwiftUI Charts
4:20 SwiftUI Custom Modifiers
5:37 UICollectionView 2.0
6:38 Twitter Wisdom
8:26 Design
9:26 LOL

Links:

Swift News Link Repo:

Link to my book - How I Became an iOS Developer:

My Twitter:

My Podcast - iOS Dev Discussions:

Book and learning recommendations that help out the channel if you decide to purchase (Affiliate Links):

Ray Wenderlich Books:

Ray Wenderlich Videos:

Paul Hudson's Hacking With Swift:

Donny Wals - Combine Framework:

Mark Moeyken’s SwiftUI Views:

Learn Advanced Swift Here:

#swift #softwaredeveloper #iosdeveloper

[seanallen]

If you enjoy my presentation/teaching style, I've started creating my own courses at seanallen.teachable.com. You can watch the first ~10% of each course for free to get a feel for them.

[EmmaKAlexandra]

On custom view modifiers, I think they’re great for defining consistent styling in your app. I tend to avoid making Views with single elements just because it abstracts away too much.

For example, if you build a custom View that contains a Text view & some view modifiers you can’t add additional modifiers to the Text view. The custom View erases the Text view to `some View`. So if, in the future, you want to add a strikethrough or apply a different font with the same styling you can’t use the custom view because the underlying Text view is erased. You can sometimes fix this with defining the Type of your `body` property to be Text but not always.

I think maintaining the underlying type of your View is really important in SwiftUI and often overlooked because so many view modifiers are available just on View. But if you look at the Text view documentation you can see a lot of the view modifiers for Text actually return a Text instance rather than `some View`. Some view modifiers are available exclusively on Text, which is why you sometimes get type errors when applying multiple view modifiers in a random order. The same is true for a lot of Views. So if you want to take advantage of these type-dependent view modifiers in the future you should avoid erasing your types like you would with a single element View.

I tend to reserve custom Views for times when composition of multiple Views is required. So, a custom layout of multiple Views, containing some complex, reusable logic on multiple views or handling some complex ObservedObjects.

[michaellatta]

Custom modifier if you are creating a “style” that can be applied to a range of views.

[awais.fayyaz]

Thanks for the News Sean. As always, great content!

[victoriawaschenko]

I just learned of your videos and am a new subscriber as of today!! I am an interior architect by trade however always had a passion for UIUX and have a background in engineering prior to architecture. I am using my time of unemployment during covid to learn as much as I can about THIS type of architecture! A pivot in career is looking more realistic the more I learn

[huntermeyer]

I would use a ViewModifier when I'm changing style (such as the Text example), but I'd create a custom View when I need to modify the layout or pass any data that is more complex than what I would feel comfortable passing through a view modifier

[nX-]

CustomModifiers, I use for reusing styles. Example: An avatar view might have the same shadow style and border style, as a card view. So you create two different views, but instead of repeating these modifiers, you create a ShadowBackground modifier and use on both AvatarView and CardView.

[wesleybritob]

4:21 - In my last project I had the same doubt and came to the following conclusion:
If you are going to change only de visual part and it's not gonna have any conditional situation i think you should use modifier, but if you gonna use any kind of conditional like .padding(true ? 24 : 32) and apply different behaviour depending of the situation you must create a reusable component.

[mihailsalari]

Good job man! Keep doing this! Respect!

[connyhakansson]

I usually distinguish the usage between modifiers and custom views, by its contents. Design /layout goes to modifies. But if I use actions or custom event handling etc, I create a new custom view for that. This makes it very easy to read, for instance a Text view, would use a custom modifier for its repeating modifiers (color, font etc). But a TextField with custom validation would go to a custom TextField view. (appearance vs action)

[chestermang]

I am using the custom view modifiers as something that I can reuse in other UI components. Dedicated Custom view if that works only for the given one case. I find custom modifiers like an extension over some generic type/protocol.

[dave]

We have built an entire struct system for views with modifiers instead of using modifiers directly. I find the code reads better and the extensibility is amazing. Our system has really helped new devs use our custom views with ease

[frozi]

Custom modifier can be used for other views, not just for TextView. In my opinion this is an advantage of this approach.

[sergeimeza]

I think is easier to onboard new developers with standard SwiftUI elements with custom modifiers rather than having custom SwiftUI views altogether. That being said if the element is complex and handles State I would use a custom SwiftUI view.

[petersuvara]

Keep up the great work Sean! Perhaps one of these days we'll run into each other!

[OmOmingCookies]

I like using custom modifiers, when it's part of the styling needed. If I have buttons, that share some of the modifiers, but don't share some for example. I could have 'ConfirmButton' and 'DeclineButton' that share a bunch of modifiers, but differ in some. That way I only have to write the custom modifier to both and then extend that with the differing modifiers.
So I'm using a combination of both.

[darato]

I would use a custom modifier in this case, it's just a simple combination of other view modifiers. It doesn't justify creating a new SwiftUI file or refer to it down below for me.

[Kevin_Zed]

I was asking myself the same thing yesterday, I going for custom view 100%. Just cause that's what I learned first.

[tahmidazam]

Sean what’s the best option to start writing articles for SwiftUI and iOS development?

[VlastimirRadojevic]

Wouldn’t be useful to create a custom modifier if you need it to implement same modifiers on different view elements, whereas a custom View Element would be for reusability of that specific type of element?