Shapes, Gestures, Persistence— Annotated Lecture Notes & Key Takeaways

This is Lecture 16 of  iOS Development with SwiftUI course, from the Spring 2025 semester. The lecturer framed this as a grab bag of final project-focused topics, walking through three practical, demo-driven skills: building custom vector shapes, handling multitouch gestures beyond basic taps, and working with file-system persistence using JSON. Every demo builds on the semester’s ongoing Codebreaker game project, so you get to see how each feature integrates into a real, working app rather than an isolated snippet.
 

Building Custom Shapes in SwiftUI and Taming the Geometry Reader

We’ve used built-in shapes like Circle and RoundedRectangle all semester, but SwiftUI lets you define your own shapes entirely. All you do is conform to the Shape protocol, which inherits from View, and implement the required path(in rect:) method.

The Path type is essentially a 2D drawing canvas. You call methods like move(to:), addLine(to:), addCurve(to:), and closeSubpath() to draw the outline you want. Once you return the path, SwiftUI handles all the standard shape behavior: filling, stroking, hit testing, and all the usual view modifiers.

The demo builds a simple Diamond shape to replace the circular pegs in the Codebreaker game. The diamond is drawn by connecting four points: top center, right middle, bottom center, left middle, then closing the path. It works exactly like any other built-in shape once defined.

The lecturer also showed a much more powerful tool that they’d intentionally held back all quarter: GeometryReader. This is a view that lets its child views read their own bounding frame, in either local or global coordinates. It sounds perfect for things like calculating animation offsets without hardcoding numbers, but it comes with a huge catch.

GeometryReader is infinitely flexible. It always tries to take up all the space it can, just like a plain Rectangle. Drop one into the middle of a layout, and it can completely mess up spacing by pushing other elements around. The lecturer repeatedly stressed that you have to understand this behavior before using it, or you’ll get confusing layout bugs.

The big demo use case was removing the “magic number” 200-point offset that controlled the peg chooser’s slide-out animation. Instead of guessing how far to move the chooser off-screen, they used two GeometryReaders: one wrapping the entire scene to get the full screen frame, and one wrapping the peg chooser itself. The offset is calculated as the scene’s max Y minus the chooser’s min Y, both in global coordinates. This works regardless of screen size or device orientation.

Even this simple use case ran into layout issues. Adding the GeometryReader around the chooser made it split available space 50/50 with the game’s scroll view, since both are flexible. The fix involved constraining the GeometryReader with aspectRatio and maxHeight to match the actual size of the chooser content. They also had to add ignoresSafeArea() to make the chooser slide fully off the bottom of the screen, instead of stopping above the home indicator.

One final note on custom shapes: they work properly with the .contentShape() modifier, which controls where taps register. If you just draw a raw Path, taps outside the diamond outline still trigger actions. Using a proper Shape type restricts hit testing to the inside of the shape, which is almost always what you want.
 

Multitouch Gestures: Rotation and Pinch Resizing

Up to this point in the class, we’d only used tap gestures and the built-in scrolling in ScrollView. This lecture dives into continuous multitouch gestures, which track finger movement in real time.

Gestures fall into two categories. Discrete gestures, like taps or long presses, fire once when complete, and use the .onEnded handler. Continuous gestures, like drag, rotation, and magnification (pinch), fire constantly as the user moves their fingers, and use .onChanged with a gesture-specific value parameter.

The first demo adds a rotation gesture to the game view. You put two fingers on the screen and twist like turning a knob, and it cycles through the available peg colors. The implementation is straightforward: every 90 degrees of rotation maps to the next peg index, wrapping around with modulo. The lecturer noted one basic practicality: you have to attach the gesture to a large enough view, because both fingers need to fit inside its bounds. You would never put a rotation gesture on a small button.

The second, more complex demo adds a magnification (pinch) gesture to the list of game summaries. Pinching out makes the summary cards bigger and show more detail; pinching in makes them smaller so more fit on screen.

I found this part a little hard to follow at first, because it uses two separate state variables instead of one. There’s a static size (an enum: compact, regular, large) that represents the last saved size, and a dynamic magnification factor that updates live while the user is pinching. The displayed size is the static size multiplied by the dynamic factor. When the gesture ends, you update the static size to match the final magnification, then reset the dynamic factor back to 1.0. This prevents the UI from jumping when the user lifts their fingers.

To support the three sizes, the game summary view adjusts its layout, font size, and visible information. Compact mode uses a horizontal layout with smaller text and hides the attempt count. Regular and large use vertical layouts, with larger text and extra details in large mode.

A neat Swift trick here lets you switch between horizontal and vertical layouts dynamically. You can’t just conditionally use HStack or VStack directly, because Swift’s type system needs a single concrete type. The solution uses AnyLayout to type-erase the layout, so you can store either an HStackLayout or VStackLayout in a single variable and use that as the container. The lecturer called this more advanced end-of-quarter material, but it’s a useful pattern to know.

The lecture closed the gesture section with a few practical notes. SwiftUI does a surprisingly good job of disambiguating overlapping gestures — if you start dragging, it will figure out you’re not tapping. Even so, you have to be careful not to conflict with system accessibility gestures like triple taps. You can also build sequential gestures (like long press then drag), but those get complicated quickly and can be confusing for users.
 

Persistence: File System, Codable, and JSON

We already use Swift Data for persistence in the game, but there’s a whole ecosystem of other persistence options. The lecturer ran through the full landscape: Swift Data, iCloud integration, raw file system storage, and User Defaults. Most of the session focuses on file system storage and JSON, since that’s what the demo implements.

First, a quick overview of the iOS app sandbox. Every app gets its own isolated sandbox directory, and can’t read any other app’s files. This exists for security and privacy, but also makes uninstalling clean — delete the app, and all its data vanishes automatically. iCloud backups also pull from the sandbox by default.

Inside the sandbox, there are a few key directories you’ll use all the time. The application directory is read-only, holding your app binary and bundled assets like images. The documents directory is for user-visible files that the user would think of as “documents”. Application support is for app data and settings that aren’t user-facing documents. The caches directory is for temporary files that don’t get backed up.

You access all of these via the URL struct, starting from system-provided base URLs, then appending path components and file extensions. You never hardcode full file paths.

For reading and writing, you can load Data directly from a local file URL, but that blocks the main thread. For any network URL, you always use URLSession.shared.data(from:), which is asynchronous. For file operations like copy, delete, and existence checks, you use FileManager. For accessing files shipped with your app, you use Bundle, which automatically handles localization and finds the right version of a resource for the current language.

The real bridge between Swift data types and raw files is the Codable protocol. For simple structs or enums where all stored properties are already Codable, you can just add : Codable to the declaration and the compiler synthesizes all the required code automatically. For classes or more complex types, you have to implement the initializer and encoder manually, along with a CodingKeys enum that maps property names to serialized keys. The lecturer was clear that in practice, you’ll almost always just have an AI write this boilerplate for you, but it’s good to understand how it works under the hood.

The demo adds a Save button to the game that exports the current game state as a JSON file to the documents directory. First they had to make the Codebreaker and Code model types conform to Codable.

This is where a weird bug came up. Adding Codable to the model classes broke the game’s guess input functionality. The issue was Swift Data got confused about whether to use the Codable serialization or its own external model schema. The fix was adding an inverse relationship from Code back to its parent Codebreaker game, even though the app never actually uses that backpointer. The lecturer just noted that Swift Data behaves much more reliably when you explicitly declare inverse relationships for one-to-many links.

Once that was fixed, saving worked perfectly. They also enabled the “Supports Document Browser” flag in the project settings, so you can view and share the saved JSON files straight from the iOS Files app.

The second half of the demo flipped the workflow: instead of hardcoding sample games in Swift code, they loaded them from JSON files bundled with the app. They dragged two saved game files into the project, then wrote code to find those URLs in the bundle, load the data, decode it from JSON, and add the games to the list.

The lecture wrapped up with a quick note on User Defaults, which the lecturer called “last and least” of the persistence options. It’s essentially a small persistent dictionary for preferences and settings, only supporting basic property list types. It’s not for storing large objects or structured data.

All three topics from this lecture are directly useful for final projects, and they all lean into SwiftUI’s core design pattern of composing small, reusable pieces. Custom shapes let you polish your visual design, multitouch gestures add tactile, intuitive interaction, and file-based persistence gives you a flexible alternative to Swift Data for features like user imports, exports, or bundled sample content. None of these are required for a working project, but they’re easy ways to add polish and functionality that make an app feel more complete.