Stanford CS193p: iOS Development with SwiftUI | 2025 | L14: SwiftData Demonstration

Key Concepts

• Transitioning from in-memory data management to SwiftData for persistent storage and querying.
• Addressing challenges related to data persistence, UI updates with transient properties, and database schema evolution.
• Implementing sorting and searching functionality for a game list within a SwiftData-based application.
• Balancing data integrity, UI responsiveness, and architectural considerations like MVVM.
• Utilizing computed properties and extensions for flexible model adaptation.

Initial Database Integration & Bug Fixes (Part 1)

The lecture began by transitioning the Codebreaker project to utilize SwiftData, replacing in-memory data management with a database-driven approach. The Code struct was converted to a class to become a @sign Model, requiring the import of SwiftData. A key change involved altering the kind property from an enum to a String due to database limitations, with a computed variable handling conversion between the enum and string representations (generated with ChatGPT assistance). An initializer (init) was added to the Code class, and missingPeg was updated to a String. mutating was removed from randomize and reset functions as class functions are not mutating by default.

The CodeBreaker import was changed from SwiftUI.Core to Foundation to make the model UI-independent, and relationships were marked for cascading deletion to maintain data integrity. Initially, marking startTime as @sign transient to prevent persistence caused a bug where elapsedTime wasn’t updating. This was resolved by incrementing elapsedTime whenever startTime is set, effectively forcing a UI update. The architectural approach was described as “lightweight MVVM,” utilizing extensions to the model rather than a dedicated ViewModel. UI adaptations included convenience functions for color-based interfaces and modifications to PegChooserView and PegView to align with the UI’s color representation.

A ModelContainer was added to CodeBreakerApp to manage the SQLite database, initialized for in-memory storage during previews. A custom PreviewModifier (SwiftDataPreview) was created to provide a ModelContainer to previews, handling potential errors during container creation via the PreviewTrait system. The source of truth for the game list was shifted from an @sign state variable to an @sign query, configured to fetch games sorted alphabetically by name. Database interaction for inserting, deleting, and updating games was implemented using modelContext. fetchDescriptor was introduced for custom queries, and fetchCount as a more efficient alternative to fetch when only record counts are needed. Error handling was implemented using try and do-catch blocks.

Enhancing Functionality: Sorting & Searching (Part 2)

Building on the database integration, the second segment focused on implementing sorting and searching functionality. The initial problem was the random ordering of game attempts, disrupting gameplay. This was addressed by adding a timestamp variable to the Code model, set to Date.now() during code creation. A computed property _attempts was introduced to sort the attempts array by timestamp on retrieval, ensuring chronological order without altering the underlying data structure.

A schema change to add the timestamp variable highlighted the importance of data migration, acknowledging that discarding old data is a lightweight but potentially undesirable solution. The ability to sort the game list by the most recently played game was implemented by adding a lastAttemptDate variable to the CodeBreaker model, updated upon each attempt, and utilizing this date for sorting in descending order.

Searching functionality was added using a Searchable text field and a predicate to filter the query results by game name. UI customization included using pickerStyle: .segmented for the sorting picker and adding horizontal padding. The lecture emphasized the importance of separating concerns, as demonstrated by the use of computed properties, and the need for careful consideration of data migration when altering the database schema. A key constraint was noted: query customization can only be performed during the initialization of a view.

Conclusion

The lecture demonstrated a practical approach to transitioning a project to SwiftData, highlighting the benefits of data persistence, querying, and sorting. It emphasized the importance of architectural considerations, such as lightweight MVVM, and the need for careful planning when evolving the database schema. The use of computed properties and extensions provided a flexible way to adapt the model to UI requirements, while pragmatic problem-solving, including utilizing ChatGPT for code generation and implementing workarounds, was showcased throughout. The overall takeaway is that SwiftData offers a powerful and flexible solution for data management in SwiftUI applications, but requires careful attention to detail and a proactive approach to potential challenges.