WWDC 23, First Impressions of SwiftUI 5 and SwiftData

WWDC 2023 is in full swing. Apple has not only introduced new hardware products but has also launched several quite shocking new frameworks. This article will discuss my initial impressions of SwiftUI 5.0 and SwiftData at this year’s WWDC.

SwiftUI

If the upgrades from SwiftUI 1.0 to 4.0 each year were minor tweaks, then the effort Apple put into SwiftUI 5.0 this year can at least be considered a mid-term modification.

This year’s improvement in SwiftUI is quite significant, with some changes being revolutionary.

New Declaration and Injection Methods for Data Flow

Utilizing new features of Swift 5.9, for reference types of Source of truth, one only needs to use @Observable for marking, and the view will respond to changes in the data source with property granularity. This fundamentally solves the current efficiency problem affecting SwiftUI applications (transitional computing), allowing developers to more freely design data structures and inject data sources at will.

Unfortunately, this new feature can only be implemented on SwiftUI 5. If you plan to develop applications for iOS 17+, you should immediately abandon the declaration method of @ObservableObject.

Since there are two different data source declaration logics in the same system, this also brings more confusion to beginners.

Revolutionary Upgrades in Animation and Visual Effects

SwiftUI, which was lacking some advanced animation and visual features, has filled these gaps in this upgrade, and Apple has significantly updated the internal implementation of animations, transitions, shapes, effects, and more.

This upgrade brings animation completion callbacks, phase animations, keyframe animations, a brand new Transition protocol (supporting transition states), a brand new Shape protocol (supporting operations between shapes), a brand new TransactionKey (supporting custom Transaction attributes), Shader support (making it exceptionally easy to achieve certain special effects), type-safe image and color resource types (Assets will automatically generate corresponding code), convenient Symbol animations, a brand new CustomAnimation protocol (supporting custom animation functions), spring animations, and many other new features. In short, what will restrict animations or visual effects will no longer be the capability of SwiftUI, but the creativity of the developer.

Significant Improvements in ScrollView Control

In this update, ScrollView has been enhanced with a new dynamic scrolling positioning system (not dependent on ScrollViewReader and explicit id declarations), a one-time positioning system (directly positioning to a specific location in the scroll view after the view enters, usable only once), brand new scrollbar control (flashing), customization of row views at the top of the scroll area and their display status in the viewing area (for example, implementing a visual effect similar to the shrinking of subviews scrolled to the top in watchOS), support for paging scrolling (long-awaited by developers), custom indentation of scroll content, adding safe areas to scroll content (not the scroll container), and many other features.

Other Features

There is so much content in this upgrade that many new features are not listed in Apple’s update documentation. In the coming period, there should be numerous articles on the internet further explaining and discussing these features.

However, it is very unfortunate that Apple did not fully utilize Swift’s @_backDeploy feature. In SwiftUI 5.0, only a very few and not so important features or types have been adapted to lower versions: topBarLeading: SwiftUI.ToolbarItemPlacement, topBarTrailing: SwiftUI.ToolbarItemPlacement, accessoryBar<ID>, horizontalSizeClass, verticalSizeClass, typeSelectEquivalent.

Without considering compatibility with older versions, I would rate the SwiftUI 5.0 upgrade 95 out of 100. However, considering that many developers will not be able to use these new features for quite some time, it can be quite disheartening.

SwiftData

After a long wait by developers, Apple has finally launched SwiftData, an object graph management and persistence framework developed in Swift. As anticipated, in the data storage domain, Apple did not hastily start from scratch with a completely new logic. Essentially, SwiftData is an official Swift-based wrapper library for Core Data, utilizing the new features of Swift 5.9.

Based on my usage in the past couple of days, it will indeed bring more convenience to developers, provided its functionality and stability are further improved and enhanced.

Here are some issues and notes about SwiftData that I have compiled (originally posted in tweets, not systematically summarized):

• Does not yet support public and shared data cloud sync.
• In the current version, data created through other contexts (ModelContext) does not automatically merge into the view context.
• There are issues with custom migration plans in the first version.
• It can be mixed with Core Data code, but one needs to use entityVersionHashesByName to determine if the models of SwiftData and Core Data are entirely consistent.
• Neither PersistentModel nor ModelContext are Sendable (ModelContainer complies with Sendable), like Core Data, they also have threading restrictions.
• Even after enabling com.apple.CoreData.ConcurrencyDebug 1, trying to maintain thread consistency using transaction in a new Context will still force an error (even when done in a newly created actor).
• Still subject to the same CloudKit sync limitations; the Attribute (.unique) demonstrated is not suitable for sync scenarios.
• Currently has fewer features than Core Data, with no new additions.
• The nature of PersistentModel is similar to Observed states created through macros, directly driving view updates (no need for property wrappers when passing).
• The derived options of Attribute have been deprecated.
• In Xcode, the Model Editor can be used to convert Models into SwiftData code, but there are still many problems, especially when there are multiple options, or when the property type is transformable.
• Indexes set in the original Model cannot currently be converted (code can be generated, but Attributed is not fully complete).
• All startup parameters for Core Data are currently applicable.
• There are issues with modelContext’s auto-save, and the save method should still be called.
• When mixed with Core Data Stack, persistent history tracking must be enabled on the Core Data side.
• Query (the replacement for FetchRequest) does not provide methods for dynamically switching predicates and sorts.

From a coding style and implementation perspective, SwiftData has a bright future. However, due to its current issues, even if you plan to develop iOS 17+ applications, it’s not recommended to directly use SwiftData.

To complement SwiftData, Core Data has undergone a minor upgrade, one notable feature being custom composite types.

However, there have been no adjustments on the client side for the Core Data with CloudKit API, which is quite disappointing.

Joy or Resignation

At this year’s WWDC, Apple brought significant changes to SwiftUI and introduced SwiftData, a long-awaited framework for developers. Initially, I was incredibly excited to see these updates, but soon my excitement settled, leading to a feeling of resignation.

For most developers, once they can use these new features in their applications, Apple might already be tempting them with even newer innovations. The new features of SwiftUI greatly expand its expressive capabilities, but they also increase its learning curve, especially for beginners. Although SwiftData simplifies Core Data development, as a new framework, its stability and robustness remain to be further validated.

In recent years, Apple has released a constant stream of new technologies, requiring developers to continually learn and adapt, which implicitly increases development costs and risks. While Apple’s new technologies are generally practical, developers need to carefully weigh the pursuit of innovation against stability.

However, for me, this WWDC has provided plenty of material for learning and writing. In the coming period, I plan to introduce and discuss SwiftUI, SwiftData, and a few other new frameworks that I find interesting, such as TipKit and CKSyncEngine, in my blog.