SwiftUI at WWDC24
Learn how you can use SwiftUI to build great apps for any Apple platform. Explore a fresh new look and feel for tabs and documents on iPadOS. Improve your window management with new windowing APIs, and gain more control over immersive spaces and volumes in your visionOS apps. We’ll also take you through other exciting refinements that help you make expressive charts, customize and layout text, and so much more.
Join us on a tour of SwiftUI, Apple’s declarative user interface framework. Learn essential concepts for building apps in SwiftUI, like views, state variables, and layout. Discover the breadth of APIs for building fully featured experiences and crafting unique custom components. Whether you’re brand new to SwiftUI or an experienced developer, you’ll learn how to take advantage of what SwiftUI has to offer when building great apps.
Learn how to create great single and multi-window apps in visionOS, macOS, and iPadOS. Discover tools that let you programmatically open and close windows, adjust position and size, and even replace one window with another. We’ll also explore design principles for windows that help people use your app within their workflows.
Tailor macOS windows with SwiftUI:
Make your windows feel tailor-made for macOS. Fine-tune your app’s windows for focused purposes, ease of use, and to express functionality. Use SwiftUI to style window toolbars and backgrounds. Arrange your windows with precision, and make smart decisions about restoration and minimization.
Learn about the capabilities of SwiftUI container views and build a mental model for how subviews are managed by their containers. Leverage new APIs to build your own custom containers, create modifiers to customize container content, and give your containers that extra polish that helps your apps stand out.
Create custom visual effects with SwiftUI:
Discover how to create stunning visual effects in SwiftUI. Learn to build unique scroll effects, rich color treatments, and custom transitions. We’ll also explore advanced graphic effects using Metal shaders and custom text rendering.
Catch up on accessibility in SwiftUI:
SwiftUI makes it easy to build amazing experiences that are accessible to everyone. We’ll discover how assistive technologies understand and navigate your app through the rich accessibility elements provided by SwiftUI. We’ll also discuss how you can further customize these experiences by providing more information about your app’s content and interactions by using accessibility modifiers.
Enhance your UI animations and transitions:
Explore how to adopt the zoom transition in navigation and presentations to increase the sense of continuity in your app, and learn how to animate UIKit views with SwiftUI animations to make it easier to build animations that feel continuous.
Swift Charts: Vectorized and function plots:
The plot thickens! Learn how to render beautiful charts representing math functions and extensive datasets using function and vectorized plots in your app. Whether you’re looking to display functions common in aerodynamics, magnetism, and higher order field theory, or create large interactive heat maps, Swift Charts has you covered.
Migrate your TVML app to SwiftUI:
SwiftUI helps you build great apps on all Apple platforms and is the preferred toolkit for bringing your content into the living room with tvOS 18. Learn how to use SwiftUI to create familiar layouts and controls from TVMLKit, and get tips and best practices.
Starting with this version, the SwiftUI development team appears to have found the right path to rapidly evolve SwiftUI, exploring ways to enhance its capabilities while maintaining the characteristics of a declarative framework.
In this update, the SwiftUI team changed its previous API design strategy—from highly encapsulated and less flexible designs to providing developers with greater lower-level control. This includes integrating UIKit gestures, introducing more functional custom containers, custom rendering of Text and providing precise scroll control. These improvements have significantly raised the upper limits of SwiftUI, opening up broader technical possibilities for advanced developers.
As SwiftUI shares mechanisms for animations, transitions, and gestures with the UIKit framework, it is gradually transitioning from a framework built on UIKit/AppKit to a more equal partner within Apple’s UI framework ecosystem. It is no longer just drawing features from other frameworks but is starting to give back by contributing new features to them.
The new version of the SwiftUI framework also underwent code-level stratification, carving out a separate SwiftUICore framework. This was likely done to facilitate better collaboration with UIKit and AppKit, but it also opens up exciting possibilities for future developments.
SwiftUI has usually been thought of as an abstraction layer over AppKit and UIKit. But this WWDC is the first time I get the feeling AppKit and UIKit are becoming abstraction layers over SwiftUI.
SwiftUI introduced the new overloads for
Group
andForEach
views, allowing us to create custom containers likeList
orTabView
.[…]
The new
ScrollPosition
type, in pair with thescrollPosition
view modifier, allows us to read the precise position of aScrollView
instance. We can also use it to programmatically scroll to the particular point of the scrolling content.[…]
The new
Entry
macro allows us to quickly introduce environment values, focused values, container values, etc, without boilerplate.
This is another good year for SwiftUI, with another batch of scrollview improvements, some welcome macOS features, remarkable control over text rendering, and more – the team at Apple have a lot to be proud of, and many developers will breathe a sigh of relief as API such as fine-grained subview control is now public for all of us to use.
[…]
The difference is small, but makes a huge difference: the
@MainActor
attribute moved frombody
up to the [View
] protocol itself, which means thebody
property along with all other properties and methods we make are run on the main actor.
After 5 years SwiftUI
ScrollView
finally gets one of the basic fundamental features aScrollView
needs.
This week, we will discuss monitoring scroll phases in SwiftUI.
The new
Entry
macro being backported is so wonderful.Immediately deleted a bunch of boilerplate from
EnvironmentValues
andFocusedValues
.
This week, we will talk about the
Entry
macro type.
Today, we want to discuss environment values, preferences, and view updates.
robb:
There are some real crowd pleasers coming to SwiftUI this year at WWDC2024.
Here’s the full list, but I’ll call out some personal favorites[…]
[…]
Group
andForEach
are getting superpowers this year, including the ability to iterate over and transform the subviews of a view. (No more_VariadicView
shenanigans!)
This seems like the biggest change to me. I will be interested to hear how the performance is.
New in macOS 15, we can now use onModifierKeysChanged(mask:initial:_:) to update our views when keyboard modifiers are held down.
“If we just keep saying SwiftUI is the best way to write apps it’ll eventually come true, right?”
You can now build AppKit
NSMenus
in SwiftUI with theNSHostingMenu
API.
I had some hopes that Apple would embrace new Swift concurrency in their API for a Swift 6 launch. I guess not necessarily, if not even modern SwiftUI API got update.
It’s going fine:
@preconcurrency
,@unchecked Sendable
SwiftUI’s new
Color.mix(with:by:)
API allows you to interpolateColor
s that matchSwiftUI.Gradient
in discrete steps.
Khoa:
The new SwiftUI
Window
modifier for macOS is great. There is less need for AppKit now
I’m DYING to know why can’t SwiftUI just give you the
NSWindow
so we don’t have to wait years for them to add the most basic stuff
I submitted FB13821655 June 9, 2024 “Support onboarding View for iOS SwiftUI document-based apps” and received response from Apple June 12, 2024 saying “The API you’re asking for has been released in a new Beta now. Here’s the WWDC session that covers it.
This wins both the “Fastest response to a Feedback feature request” and the “Most useful response” awards by a long mile.
Would love any leads on this: setting [Core Data]
.fetchBatchSize
causes entire collection to be immediately traversed [by SwiftUI].
Did someone try whether the SwiftUI refresh issue in SwiftData got fixed? Some blog sounded like no?
Just realized, SwiftUI views still can’t just print. I can’t believe another year went by without that.
5y into SwiftUI, still no justify
Text
alignment.
For a while, presenting a form sheet in SwiftUI, equivalent to the UIModalPresentationStyle.formSheet, was a challenge. Now, with the new presentationSizing() modifier, we can easily achieve this using the form sizing option.
I feel like SwiftUI’s
Form
should have been an exemplar of the power and ease-of-use of declarative UI code. It instead its a demonstration of the pitfalls.The same code doesn’t adapt correctly across platforms. When layout goes wrong, it’s not clear how to fix it or if it can even be fixed.
I have a simple SwiftUI app that has a picker, textfield and several buttons. It is using a Enum as a focus state for the various controls. When I compile and run it on Mac Studio desktop it works as expected: Picker has initial focus, Selection in Picker changes focus to TextField, Tab key moves through buttons; last button resets to Picker
However when I run the exact same app on MacBook Pro (same version of MacOS, 14.5) it does not work at all as expected. Instead: Initial focus is set to TextField, Tab does not change the focus, Clicking on last button resets focus to TextField rather than Picker.
[Update (2024-07-25): It turns out that this was due to a different system setting.]
Xcode previews would be super-helpful in iterating over
Form
s. However, I also discovered if my SwiftUIView
uses macros to generate any of its code, previews don’t work at all. Doesn’t matter if I build them old-school or use the#\Preview
macro.Maybe the new preview system in Xcode 16 fixes this?
For all of Swift’s rich static typing, SwiftUI doesn’t seem able to leverage it in ways that would make it ergonomic. Everything gets erased to a
View
, effectively. There’s no typing to hint at whatView
s would work in a specific context, or type errors about invalid combinations.
If you want to go spelunking in SwiftUI’s .swiftinterface file (people have found interesting things in there in past years), note that there’s a new SwiftUICore.framework this year, so now there’s two files to check.
/Applications/Xcode-16.0b1.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/System/Library/Frameworks/SwiftUICore.framework/Modules/SwiftUICore.swiftmodule/arm64-apple-ios.swiftinterface
My beef about today’s Swift adoption at Apple is SwiftUI. It is a framework that stands against what Swift promised to developers back in the days
- slow
- limited
- runtime crashes if you use the wrong variable type (compile and don’t work?)
- unhelpful/misleading compilation diagnostics
- underlying objc frameworks crash and mem leak as it always been
- bad devtools that never improved
With SwiftUI entering its sixth year, with Apple having now revealed what this year’s change cycle will be, I haven’t seen anything that moves the needle re adopting it in existing apps if you’ve been holding off. It’s certainly improving for SwiftUI developers, and it’s getting carve-outs for things that have been pain points traditionally like gesture recognizers, but it doesn’t feel like an essential capital-t Transition, just a different way to make apps if that’s how you prefer it
Previously:
- Overcast’s New Foundation
- Swift 6 Announced
- Xcode 16 Announced
- Catalyst (Not) at WWDC24
- NSTableView With SwiftUI
- Mac Dialog in Auto Layout vs. SwiftUI
- AppKit vs. SwiftUI: Stable vs. Shiny
- SwiftUI Notes Before WWDC 2023
- Slow SwiftUI Closure Actions
Update (2024-08-07): Pasi Salenius:
SwiftUI is a big part of why I feel like I want to switch from iOS to Android.
Yes Apple uses it all over, and most apps where they use it seem buggy, behave in weird ways, often lack animations and transitions that used to be there, or just look odd.
SwiftUI lists still don’t smoothly scroll anything that has more than 10 rows in it. Yes it’s easier but the apps people build with it end up being worse for the user.
This is not the Apple that I was enamored by years ago.
[I] meant to say discoverability. By that I mean the ergonomics of writing SwiftUI, how it boils down to knowing modifiers that one just has to remember as autocomplete is crushed under the load of everything being available everywhere. And the order of those modifiers matters in myriad ways. And the fact that Apple keeps changing the modifiers every year just when you thought you might even remember the previous ones.
[…]
I went pretty far trying to implement Proxygen on Mac with SwiftUI and it performed horribly scrolling through even a relatively small number of rows. It doesn’t really matter if developers are doing something wrong or it’s SwiftUI’s fault, but scrolling performance is bad in almost any SwiftUI app you see. Latest example is Overcast (sorry Marco).
You must have seen the troubles Icecubes has gone through trying to get an app whose only task is to scroll smoothly to do that. And it never succeeded. This was supposed to be the shining pinnacle of what a good SwiftUI app can be like. And the developer lost hope getting it to work.
I think of SwiftUI as being a “form builder on steroids”. You can very quickly build quite advanced forms or viewers. I absolutely do agree that it is unsuitable for a scrollable list of thousands of items. For a settings form, it is great. But this gets me to another huge advantage of SwiftUI over other declarative frameworks: It has a very good Cocoa integration. So you can easily step out to Cocoa to do performance sensitive things. That’s a feature not a bug.
SwiftUI is very fast at layout (much faster than AutoLayout) and also faster at drawing (depending a little on what you draw).
The real achilles heel of SwiftUI is the diffing that has to be performed, and which, like AutoLayout, doesn’t scale at all.
A weird perception(?) problem with SwiftUI is that it’s easy to bang out whole entire rough UIs in a day or two that used to take weeks but then you gotta do polish and edge cases and that still takes forever except because that initial blocking out phase was so quick, when a single small polish thing takes a week or two to iron out it feels like nothing is getting done and the pressure builds unnecessarily.
If I want quality, I need to control. If I want to control, SwiftUI is not the answer.
This is a demo project that highlights performance issues with hierarchical SwiftUI lists.
There are three main problems:
- Rendering of the list is slow if there are many items. (Just start the app and wait for the list to be rendered.)
- Changing the selected item is very slow. (Tap/Click an item and wait for the selection to change.)
- Updating the list is slow. (Press the “Shuffle” button.)
[…]
All three problems are much more pronounced on macOS (tested on a Mac Studio M2) where it even takes minutes(!) for the app to become responsive.
Just discovered an issue that causes SwiftUI to crash on macOS because you change the size of a window.
A
ScrollView
that gets a width change because its contentView
height is “just right" to cause scroll bars to appear will cause AppKit to throw an exception because of overlapping constraint changes.
Update (2024-08-14): Alex Grebenyuk:
It’s also a shame SwiftUI gets a bad rep because folks keep trying to make
List
work—it does only as long as you never need to scroll or update it.[…]
if you need to dipslay more than 10 items,
UITableView
orUICollectionView
withUIHostingConfiguration
is the way to go for now.
Update (2024-08-22): Sarah Reichelt (Hacker News):
I’ll cover new features from both WWDC 2023 and WWDC 2024.
8 Comments RSS · Twitter · Mastodon
Swift and SwiftUI is too much drama, I gave up and am using Flutter now. Documentation is good, performance is acceptable, haven't run into too many issues where I what I'm trying to do isn't a possibility at all. I can focus on the task at hand and ship. I'm pretty pleased with how the Cupertino widgets feel on-device.
The only thing I don't like about it is how dependent it is on Google, especially where it has direct internal competition from Jetpack Compose.
Interesting take from the creator of Swift here on the current state of the language:
https://m.youtube.com/watch?v=ovYbgbrQ-v8
> However when I run the exact same app on MacBook Pro (same version of MacOS, 14.5) it does not work at all as expected.
This is seriously some masochist shit. When the entire platform is unstable I wonder if the managers responsible for pushing this nonsense will remain at Apple?
All these new additions and refinements are meh.
I can’t understand the excitement and reactions by some of the developers.
They all watch in amazement at the new shiny patina of a polished turd.
For 6 years, SwiftUI has not really evolved in any meaningful way to make a switch.
Developers giggle giddily at features that were always available, but in the old frameworks, that worked just fine.
> This is seriously some masochist shit.
If you read the linked forum thread, an explanation has been found: Keyboard Navigation was enabled in system settings on one machine but not the other.
If you had told me at the beginning of my journey as a programmer that people would discard a battle tested framework that did most of everything one needed, and instead would use a brand new framework that missed a whole load of functionality, I would have stared in disbelief. Yet it keeps happening.
We seem to be in a world in which fashion matters more than engineering. And it seems to me that the first few quotes in Michael's article illustrate why: they're all marketing hot air that says nothing, and speak as if there was no history, no other world. Some sort of version of North Korea's Juche year system. First there was Kim Il Sung. Nothing significant ever happened before.
It's almost as if they need to destroy stuff so that they can create the perception of "growth", of rebuilding everything they destroyed from scratch, instead of actually spending their energy innovating. A bit like the "benefits" of wars.
>If you read the linked forum thread, an explanation has been found: Keyboard Navigation was enabled in system settings on one machine but not the other.
Well, that's good. I still find Apple's obsession with SwiftUI to be a huge mistake for many reasons. It is creating a lot of instability on the platform and there clearly is a large number of developers who still *do not* like it. The results have not been very good.
It is clear that there are developers who truly enjoy playing with this framework but it looks mostly like sick self-pleasure to me. Certain Apple devs (bloggers, etc.) who make a living teaching app development love it, they got more courses to sell. I don't think it will ever be as good as AppKit. It appears to be just another cross-platform shortcut that produces subpar results. At least with other cross-platform shortcuts you can deploy on non-Apple devices.
There is so much UIKit/AppKit code and such a large ecosystem. Yet they tell UIKit developers that their storyboards are deprecated on visionOS before the product is even released. They deprecate UIKit on watchOS (which doesn't have too many developers anyway) but still....
But hey, your unmodified Objective-C apps will work on visionOS because well, they still want to say they have millions of apps! Alienating developers, obsoleting their skills, and forcing them to use something that is inferior...all while smiling at you and telling you SwiftUI is the *best way* to do something...like your some kind of moron.
Objective-C was the third most popular programming language in the world before they released Swift. They caught lightning in a bottle but dropped the bottle and it broke.
I'd like to see a poll of how much Apple developers like SwiftUI bifurcated by experienced versus inexperienced developers. My guess is there would be a huge disconnect. The new developers who can get started quickly and don't know any better love it. And as another commenter mentioned, the tutorial developers love it. But do the experienced developers who actually knew AppKit/UIKit and have given SwiftUI a first shake love it?
I mean, yes, declarative UI *is* a feature, and an important one IMO. XAML does for Windows and has since WinForms, and whatever you think of the performance there's no doubt people have used it to great satisfaction. I think this is uniquely an Apple problem, of biting off more than they could chew, trying to cram in too many innovations and the need for an inferior standard for cross-platform apps. I don't actually think there's anything wrong with the ideas, it's just a massive mis-fire.