Jony Ive (Hacker News):
Steve rarely attended design conferences. This was 1983, before the launch of the Mac, and still relatively early days of Apple. I find it breathtaking how profound his understanding was of the dramatic changes that were about to happen as the computer became broadly accessible. Of course, beyond just being prophetic, he was fundamental in defining products that would change our culture and our lives forever.
[…]
In the talk, Steve predicts that by 1986 sales of the PC would exceed sales of cars, and that in the following ten years, people would be spending more time with a PC than in a car. These were absurd claims for the early 1980s. Describing what he sees as the inevitability that this would be a pervasive new category, he asks the designers in the audience for help. He asks that they start to think about the design of these products, because designed well or designed poorly, they still would be made.
He was such a clear thinker and communicator.
Adam Engst:
It’s a fabulous time capsule of the pre-digital era, with Jobs saying “Uh-oh” when no one in the audience admits to owning an Apple or any other personal computer. This is a young Steve Jobs, speaking more extemporaneously and unguardedly than he would in later years. I encourage you to spend some time on the exhibit and, in particular, try to watch the full 55-minute presentation.
I was mostly struck by how prescient Jobs was in that talk. Although he had to explain computers and software by analogy for an utterly non-technical audience, he still tossed out prediction after prediction about how things would be in the future. Given that this is 1983, we’ve lived through much of that future by now, and with the benefit of hindsight, we can see that he was remarkably accurate, if sometimes optimistic regarding timeframes.
M.G. Siegler:
I’ve never seen a bad Steve Jobs video. So when a new one is put out there into the world, the bar is quite high. Surprising no one [it] does not disappoint.
[…]
His talk really takes off though when he ends his prepared remarks almost comically abruptly with “so what do you want to talk about?” The crowd sort of laughs and then realizes he’s dead serious and breaks into applause. And then the questions start. I’ve written about Jobs’ ability to command a Q&A before, and it was clearly the mode in which he best operates. As someone who was in a few such sessions (mostly public, as a member of the press, but one memorable one which was private), it’s impossible to overstate how good he was at these. Everyone knows the famous/infamous “reality distortion field”, but it really undersells Jobs’ ability to command a room by speaking in a way that’s intensely human.
Apple II Artificial Intelligence Design History Lisa Networking Programming Speech Recognition Steve Jobs Xerox
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:
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:
- 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.
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
