macOS Golden Gate 27 Beta Release Notes:
AsyncImagenow automatically caches downloaded images using HTTP caching protocols, allowing servers to control caching behavior via standard headers.[…]
Xcode 27 introduces a new
@Stateimplementation that avoids this repeated evaluation. This new behavior back-deploys to iOS 17 aligned OSes. The new@Stateis implemented with a Swift macro. It is largely source compatible with the property wrapper version, with a few exceptions.[…]
Textviews now supportTextRenderer.[…]
In apps built with the 27.0 SDKs, the new
ReadableDocumentandWritableDocumentprotocols support asynchronous reading and writing, progress reporting, and direct access to document URLs. NewDocumentGroupinitializers that adopt these protocols let you disable document creation for editing-only apps and present custom UI before any document is opened.[…]
TextFieldrespects custom font and color styling applied to its prompt.[…]
Listaccepts drops in two cases that previously didn’t work: drags with compatible transfer representations are accepted into reorderable content even when the.reorderableItemtransfer type isn’t present, and a.dropDestination(…)modifier declared on a list item now performs the drop.
Build your project in Xcode 27 or later to construct type-agnostic content from closures that you mark with
ContentBuilder, which serves as the unified replacement for type-specific builders likeToolbarContentBuilderandCommandsBuilder.Add reordering by drag-and-drop in containers such as lists, stacks, grids, or custom layouts with
reorderable()andreorderContainer(for:isEnabled:move:).Add custom swipe actions to views in containers such as scroll views, stacks, grids, or custom layouts using
swipeActions(edge:allowsFullSwipe:content:onPresentationChanged:)andswipeActionsContainer().[…]
Use the
visibilityPriority(_:)modifier to prioritize important toolbar actions so SwiftUI keeps them visible as space shrinks, moving lower-priority items to the overflow menu first.[…]
Present an alert or confirmation dialog from an optional data item or error object, and use that data to produce the content and title[…]
Explore the latest additions to SwiftUI and discover how they can improve your apps. We’ll introduce a new Document protocol with direct disk access and snapshot-based diffing for building high-performance apps; new APIs for reordering content in lists, grids, and sections; and toolbar enhancements including visibility priority and auto-minimizing behavior. We’ll also cover expanded presentation APIs — including swipe actions on any view — plus AsyncImage caching improvements and lazy state initialization for Observable types.
Use SwiftUI with AppKit and UIKit:
Discover how to incrementally adopt SwiftUI in your existing AppKit or UIKit app. We’ll show you how to use the Observation framework to automatically update your views, integrate SwiftUI components into an existing view hierarchy, and bring gesture recognizers into SwiftUI. We’ll also explore how to add complete SwiftUI scenes to your app without changing your overall architecture.
Dive into lazy stacks and scrolling with SwiftUI:
Discover the inner workings of lazy stacks in SwiftUI. We’ll explore how LazyVStack and LazyHStack estimate sizes, lazily load subviews, and prefetch content to deliver smooth scrolling experiences. We’ll also cover advanced performance optimizations, state management best practices, and tips for precise programmatic scrolling. To get the most out of this session, we recommend basic familiarity with SwiftUI layout using stacks.
Compose advanced graphics effects with SwiftUI:
Discover how to craft rich, custom experiences by creatively composing SwiftUI layout and graphics APIs. We’ll show you how to break down complex designs and use a creative pipeline to chain simple building blocks together. Learn how to draw with layer shaders, animate with timelines, and anchor views with alignment guides.
Build powerful drag and drop in SwiftUI:
Follow along as we build a game of Solitaire to explore the latest drag-and-drop capabilities in SwiftUI. We’ll show you how to use the new reordering API to let people arrange content, implement drag containers to move multiple items at once, and customize the drag-and-drop lifecycle to fit your app’s rules.
There are also a bunch of labs.
Up until now it was a property wrapper conforming to the
DynamicPropertyprotocol, but in Xcode 27 it becomes a Swift macro. In this post we will look at what the change means for@Observablemodels stored in@State.
Only took 3 years lol!
SwiftUI also introduces a new prominent tab role. You can use the prominent role for trailing-separated tabs, similar to search.
[…]
Document-based apps get a refreshed look and feel, along with a performance boost. It looks like Xcode has started using these improvements, which might explain why we see so much work around document-based apps this year. And finally, Xcode introduces SwiftUI Specialist and What’s New in SwiftUI skills for agentic coding in Xcode.
For me, the biggest change in SwiftUI comes from its comprehensive support for document-based apps. It not only adds a large number of new APIs, but also shifts the mental model toward “observable document objects + asynchronous snapshots + dedicated readers / writers.” This is clearly better suited to complex document apps, and it also aligns more closely with the overall evolution of modern Swift around Observation and Concurrency.
The sessions also mentioned that SwiftUI continues to optimize layout- and container-related implementations, bringing noticeable performance improvements in some scenarios. This is an improvement developers have urgently needed. However, SwiftUI still does not provide the ability to create custom Lazy containers, which remains a clear disappointment.
iOS 27 introduces new reordering APIs that work with any container. We can mark dynamic content with
reorderable()and define the scope of the interaction withreorderContainer(for:). SwiftUI handles the drag preview, insertion placeholder, and drop animation, while our code applies the resulting change to the model.SwiftUI’s drag container APIs are also now available on iPhone and iPad, after previously being limited to macOS. They let us make items in a collection draggable without making the collection reorderable, and include multiple selected items in the same drag. The APIs also support lazy generation of transferable values and drag-session observation.
robb:
I love the new #SwiftUI Text selection but without a way to make selection span multiple Texts in a group, it doesn’t really address our needs at Linear – here’s hoping we see an update in a later seed 🤞
The NavigationTransition protocol has been available in SwiftUI since iOS 18, letting us control how views animate when pushed onto a
NavigationStackand when presenting sheets and full-screen covers. We specify the transition using thenavigationTransition(_:)modifier on the destination or presented view, and SwiftUI uses it instead of the default animation for that context. Before iOS 27, SwiftUI provided two built-in conforming types:AutomaticNavigationTransition, used via theautomaticstatic value, which defers to the system default for the current context, andZoomNavigationTransition, used viazoom(sourceID:in:), which animates the presented view expanding from a source view marked withmatchedTransitionSource(). iOS 27 introduces CrossFadeNavigationTransition, a new built-in transition that cross-fades between views without requiring a source, and adds AnyNavigationTransition, a type eraser that lets us select a transition at runtime.
The last few years watching WWDC has been a mixed experience for me, because I honestly believe Swift and SwiftUI are actively either bad or being made worst.
Yet every year, the problems I have with them are doubled down on, not improved.
The FB21333309 cache bug I submitted is now confirmed to be fixed on iOS 27.
Instead of introducing a new CacheKey like I suggested, SwiftUI team choose to move the intensity payload out of the FeedbackType enum to a new Payload enum and add a new payload var to SensoryFeedback storage.
A few weeks ago I realised that most iOS jobs require knowledge of SwiftUI. So I started to rebuild my Mastodon client in SwiftUI. Then I got an offer for a new job and accepted it. This means I can get back to working on the ObjC version. Feels good. :)
Previously:
Update (2026-06-23): Natalia Panferova:
iOS 27 adds new
AsyncImageinitializers that accept aURLRequestinstead of a URL. We can now configure request headers, cache policy, and timeout interval while continuing to use the built-in loading and phase handling provided byAsyncImage. A new asyncImageURLSession(_:) modifier also lets us provide the URL session used by asynchronous images in a view hierarchy.
Update (2026-07-10): Luc Vandal:
SwiftUI
.reorderable()crashes when the reordered view body containsif #available: “Unexpected identifier type. Expected [Type], got [Type]”[…]
Even attaching a
.popoverto an item causes it to crash when reordering.
Update (2026-07-23): Yakov Manshin (video, via Mohammad Azam):
Seven years after its blockbuster 2019 announcement, SwiftUI was supposed to be the mature, production-grade future of cross-platform UI development on all Apple platforms. Instead, SwiftUI feels like a perpetual beta, even in 2026. In this deep dive, I break down why the initial excitement has given way to deep professional frustration for senior engineers. I analyze the systemic issues with performance and layout predictability, the chaotic state of SwiftUI’s ever-changing data flow, and the frustrating lack of backward compatibility that forces developers into a nightmare of shims and workarounds.
Through real-world examples—including Apple’s own SwiftUI tutorial (which is broken) and a head-to-head performance comparison with UIKit (guess who wins)—I demonstrate how SwiftUI trades precise engineering for an illusion of convenience.
Beyond the code, this video explores a broader, more concerning shift in Cupertino: a transition away from the uncompromising craftsmanship of the original era of Cocoa, Aqua, and Auto Layout toward a modern corporate culture of “good enough” products.
Apple this week confirmed that Notion is migrating its user interface to SwiftUI, citing the app’s desire for greater performance and UI consistency than its existing web-based stack can deliver.
[…]
The callout was clearly deliberate; Notion is one of the most widely used productivity apps on the Mac, and has long been criticized for the sluggishness that comes with its Electron-based architecture.
Previously:
An iron artifact recovered by archaeologists may be the oldest of its kind ever found in Japan, according to new research.
Recovered during excavations at the Hayashi-Fujishima archaeological site in Fukui, the capital city of Fukui Prefecture, the artifact measures slightly more than an inch and a half across, just under an inch in width, and just a millimeter in thickness.
The presence of tiny, triangular teeth measuring up to 3 millimeters deep indicates the artifact’s use as an early saw, according to investigations by the Fukui Prefectural Archaeological Research Center, which recently announced the discovery.
While similar discoveries have been made in Japan, none are believed to be as old as this saw, which archaeologists have tentatively dated to the late Yayoi Pottery Culture Period, which thrived between the second and third centuries, making it the oldest known in the country.
Tomokatsu Uozu, Deputy Director at the Center, said the age of the discovery indicates the advancement of early iron technologies along the region’s coastal communities during the period.
“The artifact could be an important piece of evidence supporting the advancement of ironware culture along the Sea of Japan coast during the Yayoi period,” Uozu recently told The Asahi Shimbun.
The saw uncovered at the Hayashi-Fujishima archaeological site bears some similarities to saws from the same period that have been unearthed during past excavations in China.
Such similarities are important, since it is believed that the same iron processing techniques used in the creation of the saw from the Hayashi-Fujishima site originated in China, having been carried across the Korean Peninsula and eventually reaching northern Kyushu, where ancient traders carried it along the Sea of Japan to its eventual arrival at Fukui.
The saw recently showcased by the Fukui Prefectural Archaeological Research Center is only one example of the many artifacts recovered from the Hayashi-Fujishima site.
Past work at the site has uncovered additional iron artifacts, as well as stone tools, pottery, distinctive “magatama” and “kudatama” bead varieties, and a range of items during primary excavations, which were conducted during the late 1990s and early 2000s.
The site is believed to also host what remains of an ancient settlement dating to the Yayoi period, a period that was significant for the emergence of organized food production, as well as a unique element associated with the culture: the creation of distinctive, keyhole-shaped burial mounds.
However, it wasn’t until 2021, during restoration work with many of the artifacts retrieved from the site, that researchers first noticed something significant that had gone unnoticed decades earlier at the time of the artifact’s discovery: tiny serrations were present on one of its edges.
Further examination with the help of X-ray CT scan imaging confirmed the artifact’s identity as a triangular or “beak-shaped” saw, similar to other discoveries from later periods. At the time of its use, the complete saw would likely have measured up to five times the length of the remaining fragmentary portion.
Another notable feature of the saw is that the tip of the blade is bent, which archaeologists think may indicate that the saw was used for work involving fine crafting of wooden or stone items.
The discovery now overturns the previous oldest artifact of its kind known from the region, which was uncovered from a third-century burial mound in Hyogo Prefecture. That saw’s association with the Kofun Period, which thrived near the end of the third century, made it the oldest known at the time of its discovery.
Although additional studies are required, the team says that confirmation of the age of the Hayashi-Fujishima site’s saw would extend the timescales once again on the earliest use of such technologies by as much as a century.
I spend more time today than ever before interacting with terminal windows, which is something I don't think Past Me would have believed in the early '90s. Back then, poor MS-DOS was the staid whipping boy of the industry, and at least on the consumer side, graphical environments like Windows (and maybe even odder creatures like AmigaOS) seemed poised to stamp the command line into oblivion, leaving text interfaces behind as we all blasted into the ooey-GUI future.
As it turns out, though, the command line is still the best tool for some jobs—many jobs, in fact. I read a wise post some years ago (probably on Slashdot) arguing that a mouse-driven point-and-click interface essentially reduces the user to pointing at something on the screen and grunting, "DO! DO THAT!" at the computer. (The rise of right-click context menus adds the ability for the user to also grunt "MORE THINGS!" but doesn't otherwise add vocabulary.)
The command line, by contrast, gives the user the opportunity to precisely tell the computer what they want done, using words instead of one or two gestalts that the computer must interpret based on context.
© Aurich Lawson | Getty Images
Login