SwiftUI at WWDC24

What’s new in SwiftUI:

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.

SwiftUI essentials:

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.

Work with windows in SwiftUI:

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.

Demystify SwiftUI containers:

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.

Fatbobman:

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.

Colin Cornaby:

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.

Majid Jabrayilov:

SwiftUI introduced the new overloads for Group and ForEach views, allowing us to create custom containers like List or TabView.

[…]

The new ScrollPosition type, in pair with the scrollPosition view modifier, allows us to read the precise position of a ScrollView 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.

Paul Hudson:

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 from body up to the [View] protocol itself, which means the body property along with all other properties and methods we make are run on the main actor.

Kyle Howells:

After 5 years SwiftUI ScrollView finally gets one of the basic fundamental features a ScrollView needs.

Majid Jabrayilov:

This week, we will discuss monitoring scroll phases in SwiftUI.

Clarko:

The new Entry macro being backported is so wonderful.

Immediately deleted a bunch of boilerplate from EnvironmentValues and FocusedValues.

Majid Jabrayilov:

This week, we will talk about the Entry macro type.

Swift Talk:

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 and ForEach 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.

Matthaus Woolard:

New in macOS 15, we can now use onModifierKeysChanged(mask:initial:_:) to update our views when keyboard modifiers are held down.

Francisco Tolmasky:

“If we just keep saying SwiftUI is the best way to write apps it’ll eventually come true, right?”

Steve Troughton-Smith:

You can now build AppKit NSMenus in SwiftUI with the NSHostingMenu API.

Marcin Krzyzanowski:

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

Robb Böhnke:

SwiftUI’s new Color.mix(with:by:) API allows you to interpolate Colors that match SwiftUI.Gradient in discrete steps.

Khoa:

The new SwiftUI Window modifier for macOS is great. There is less need for AppKit now

Antoine:

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

Ron Avitzur:

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.

Duncan Babbage:

Would love any leads on this: setting [Core Data] .fetchBatchSize causes entire collection to be immediately traversed [by SwiftUI].

Helge Heß:

Did someone try whether the SwiftUI refresh issue in SwiftData got fixed? Some blog sounded like no?

Scott Anguish:

Just realized, SwiftUI views still can’t just print. I can’t believe another year went by without that.

Damien Petrilli:

5y into SwiftUI, still no justify Text alignment.

Natalia Panferova:

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.

Andy Finnell:

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.

alfamsome2:

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.]

Andy Finnell:

Xcode previews would be super-helpful in iterating over Forms. However, I also discovered if my SwiftUI View 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?

Andy Finnell:

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 what Views would work in a specific context, or type errors about invalid combinations.

Ole Begemann:

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

Marcin Krzyzanowski:

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

Steve Troughton-Smith:

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.

Pasi Salenius:

[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.

Helge Heß:

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.

Helge Heß:

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.

Sean Heber:

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.

Highlander:

If I want quality, I need to control. If I want to control, SwiftUI is not the answer.

Felix Deimel:

This is a demo project that highlights performance issues with hierarchical SwiftUI lists.

There are three main problems:

1. Rendering of the list is slow if there are many items. (Just start the app and wait for the list to be rendered.)
2. Changing the selected item is very slow. (Tap/Click an item and wait for the selection to change.)
3. 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.

Craig Hockenberry:

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 content View 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 or UICollectionView with UIHostingConfiguration 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.

Update (2024-11-19): Core Intuition:

Manton relates his recent attempts to write a new app in SwiftUI, which leads to an assessment of whether SwiftUI is ready for prime-time on iOS and/or Mac.

Update (2024-12-03): Steven Woolgar:

After seeing an implementation of a very important app on macOS using SwiftUI, I remain convinced that it is not ready to ship apps with. Text field editing is not ready. The engineer in question is very good and senior. Sigh.

Accessibility Core Data iOS iOS 18 Mac macOS 15 Sequoia Programming Swift Concurrency Swift Programming Language SwiftUI

8 Comments RSS · Twitter · Mastodon

---

---

---

---

---

---

---

---

Leave a Comment

Name

E-mail (will not be published)

Web site

Δ