-
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
232: Practice Exercise: Building a Custom Layout with the Layout Protocol
I've noticed a pattern with a lot of developers moving into advanced SwiftUI: they treat the Layout protocol as a "break glass in case of emergency" tool. Usually, the misconception is that any layout—no matter how complex—can be achieved if you just nest enough HStacks, VStacks, and ZStacks, perhaps throwing in some .offset() modifiers to nudge things into place.
Thinking Nested Stacks Can Handle Non-Linear Geometry
Here is why that mindset will eventually lead you into a wall of frustration. Imagine you want to build a radial menu where items are arranged in a perfect circle around a center point. If you try to do this with stacks, you're fighting the system. You'll end up calculating offsets manually for every single element based on sine and cosine, then you'll realize that when the screen size changes or the views have different content lengths, your "perfect circle" is now an oval of overlapping text. You're trying to force a linear coordinate system (rows and columns) to behave like a polar coordinate system.
// The "wrong" way: Fighting the framework HStack { Text("Item 1").offset(x: -50, y: 20) Text("Item 2").offset(x: 0, y: -50) Text("Item 3").offset(x: 50, y: 20) } // This is brittle. It doesn't scale, and it doesn't actually // communicate the layout's intent to the SwiftUI engine.Taking Control of the Proposal and Placement Cycle
When you use the
Layoutprotocol, you stop guessing and start commanding. Instead of hoping the stack puts a view in the right place, you get to participate in the two-step negotiation that SwiftUI performs: Size Proposal and Placement.First, the system calls
sizeThatFits. This is where you tell SwiftUI, "Given this amount of space, here is how much I actually need to fit my children." I like to think of this as the "request" phase. You aren't placing views yet; you're just defining the boundary of your custom container.Second, the system calls
placeSubviews. This is the magic part. You get aSublayoutProxythat lets you ask each child view how big it wants to be, and then you provide aCGPointfor exactly where it should go. No more offsets or padding hacks—just raw coordinates.Here is a concrete example of a
RadialLayout. Notice how we calculate the center of the available space and use basic trigonometry to distribute the views. This is infinitely more robust than nested stacks because it recalculates dynamically based on the actual proposed size.struct RadialLayout: Layout { var maxRadius: CGFloat = 100 func sizeThatFits(proposal: ProposedViewSize, subviews: Subviews, cache: inout ()) -> CGSize { // We want a square area that can fit our radius in all directions let side = maxRadius * 2 return CGSize(width: side, height: side) } func placeSubviews(in bounds: CGRect, proposal: ProposedViewSize, subviews: Subviews, cache: inout ()) { let center = CGPoint(x: bounds.midX, y: bounds.midY) let angleStep = (2 * Double.pi) / Double(subviews.count) for (index, subview) in subviews.enumerated() { let angle = angleStep * Double(index) // Calculate the position on the circumference of the circle let x = center.x + cos(angle) * maxRadius let y = center.y + sin(angle) * maxRadius subview.place( at: CGPoint(x: x, y: y), anchor: .center, proposal: .unspecified ) } } }I'll give you a pro tip: always pay attention to the
anchorparameter in theplacemethod. By default, views are placed by their top-left corner. If you're building something symmetrical like a circle or a grid, setting the anchor to.centerwill save you from doing a lot of tedious subtraction of half-widths and half-heights.
📋 Practical Task
Exercise: Building a Concentric Ring Gallery
Instead of a single circle, your task is to create a custom layout called ConcentricLayout. This layout should distribute its subviews across multiple concentric rings. If there are 10 views, for example, the first 4 should be in an inner ring (radius 50) and the remaining 6 should be in an outer ring (radius 120).
Requirements:
- Implement the
Layoutprotocol. - Define a logic in
placeSubviewsthat checks the index of the subview to determine which radius to use. - Ensure the
sizeThatFitsmethod returns a size large enough to encompass the outermost ring. - Use
.centeras the anchor for placing subviews to ensure they are perfectly centered on their calculated coordinates. - Test your layout by placing 12 different
Circle()orImage()views inside it.
There are no comments for now.