-
Section 1: Getting Started
-
Section 2: Core Syntax
-
Section 3: Optionals
-
Section 4: Object-Oriented and Value Types
-
Section 5: Memory Management
-
Section 6: Generics and Error Handling
-
Section 7: Concurrency
-
Section 8: Working with Collections
-
Section 9: Codable and Data Handling
-
Section 10: Protocol-Oriented Programming
-
Section 11: Testing and Tooling
-
Section 12: Practical Projects
-
Section 13: Interview Practice
-
Section 14: More Practice Exercises
-
Section 15: More Standard Library
-
Section 16: Advanced Concurrency
-
Section 17: Foundation Framework Deep Dive
-
Section 18: URLSession and Networking Deep Dive
-
Section 19: Combine Framework
-
Section 20: SwiftUI Fundamentals for Swift Developers
-
Section 21: Server-Side Swift with Vapor
-
Section 22: Swift Package Manager Deep Dive
-
Section 23: Swift Concurrency Deep Dive
-
Section 24: More Language Features
-
Section 25: Error Handling Deep Dive
-
Section 26: Testing Deep Dive
-
Section 27: Data Structures and Algorithms in Swift
-
Section 28: More Practice Exercises
-
Section 29: More Interview Practice
-
Section 30: Swift Macros (Swift 5.9+)
-
Section 31: Property Wrappers Ecosystem
-
Section 32: Swift Interop Deep Dive
-
Section 33: iOS App Architecture Patterns
-
Section 34: Performance and Debugging
-
Section 35: App Distribution and CI/CD
-
Section 36: More Practical Projects
-
Section 37: SwiftData and Persistence
-
Section 38: More Design Patterns
-
Section 39: More Review and Practice
-
Section 40: More Foundation Deep Dive
-
Section 41: Advanced Collections in Swift
-
Section 42: Advanced Generics Practice
-
Section 43: UIKit for Legacy and Hybrid Apps
-
Section 44: watchOS and visionOS Development Basics
-
Section 45: More Networking Patterns
-
Section 46: More Testing Practice
-
Section 47: Accessibility in Swift Apps
-
Section 48: Localization
-
Section 49: More Practical Projects Round 2
-
Section 50: Swift Charts Framework
-
Section 51: More Interview and Algorithm Practice
-
Section 52: Final Practice and Mastery
-
Section 53: Swift Compiler and Build System
-
Section 54: More Concurrency Practice
-
Section 55: App Store Guidelines and Review
-
Section 56: More Design and Architecture
228: Practice Exercise: Building a Custom ViewModifier
How do I actually start building a custom modifier?
Think of a ViewModifier as a way to bundle a set of changes you find yourself repeating over and over. Instead of piling five or six modifiers on every single Text or VStack in your app, you encapsulate them into a single reusable object.
To do this, you create a struct that conforms to the ViewModifier protocol. This requires you to implement a body(content:) method. The content parameter is basically the view that the modifier is being applied to. You wrap that content in your styles and return it.
struct CardStyle: ViewModifier {
func body(content: Content) -> some View {
content
.padding()
.background(Color.white)
.cornerRadius(12)
.shadow(color: Color.black.opacity(0.1), radius: 5, x: 0, y: 2)
}
}
I usually do this when I notice my UI code starting to look like a shopping list of modifiers. It cleans up the call site significantly.
Can I pass data into the modifier to make it flexible?
Absolutely. Since a modifier is just a struct, you can give it properties. This is where it gets powerful because you can change the "theme" of the modifier based on the context of the view.
Let's say you want your cards to have different border colors depending on whether they represent a "Warning" or "Success" state. You just add a property to your struct:
struct CardStyle: ViewModifier {
var accentColor: Color = .blue // Default value
func body(content: Content) -> some View {
content
.padding()
.background(Color.white)
.cornerRadius(12)
.overlay(
RoundedRectangle(cornerRadius: 12)
.stroke(accentColor, lineWidth: 2)
)
.shadow(radius: 3)
}
}
Now you aren't locked into one look; you've built a tool that's adaptable.
How do I make it feel like a native SwiftUI modifier?
Right now, to use your modifier, you have to call .modifier(CardStyle(accentColor: .green)). Honestly? That's clunky. It doesn't feel like the rest of the SwiftUI DSL.
The industry standard is to create an extension on View. This wraps the modifier call into a clean, dot-syntax method. It's a tiny bit more boilerplate upfront, but your teammates (and your future self) will thank you for the readability.
extension View {
func cardStyle(color: Color = .blue) -> some View {
self.modifier(CardStyle(accentColor: color))
}
}
// Now you can use it like this:
Text("Hello World")
.cardStyle(color: .purple)
By doing this, .cardStyle() becomes a first-class citizen in your project, exactly like .padding() or .font().
📋 Practical Task
Exercise: The Neon-Glow Profile Card
Your goal is to create a custom ViewModifier that gives a view a "Neon Glow" effect. This is a common pattern for high-contrast dashboards or gaming apps.
- Create a
ViewModifiernamedNeonGlow. - The modifier should accept a
glowColor: Colorproperty. - Inside the
body, apply the following to the content:- A padding of 16.
- A background of
Color.black. - A
cornerRadiusof 20. - An
overlayconsisting of aRoundedRectanglewith a stroke ofglowColorand a lineWidth of 3. - A
shadowusing theglowColorwith a radius of 10.
- Create an extension on
ViewcalledneonGlow(color:)that applies this modifier. - Apply this modifier to a
VStackcontaining a user's name and bio to verify it works.
There are no comments for now.