I am looking at displaying a database record. The layout is designed by the user but typically looks more like an index card than the row of a spreadsheet. There might be 20-30 fields in a record. Multiplying by the number of records that might be on the screen at a time, that could be a lot of fields. Most fields are text, so UITextView is a natural choice. But is UITextView too heavy or expensive to be used in so many copies? I seem to have 3 choices, in ascending order of apparent efficiency and also ascending order of difficulty of implementation: Have one UITextView per field. Have one UIView subclass per field, designed to look like a UITextView but be cheaper. When the user comes to edit, the current field (but no other) can be overlaid with a UITextView to enable editing. Have one UIViewSubclass for the entire record, designed to look like a collection of UITextViews but cheaper (one view per record instead of one view per field). When the user comes to edit, overlay the current field (but no other) with a UITextView to do the editing. I would welcome advice as to how expensive UITextView actually is. Is it in fact so cheap that there is no point in working hard to avoid having many UITextViews?

ViewThatFits is a great way to handle large type and resizability. I wonder what are the performance considerations here? What are common pitfalls using it? I appreciate any tip or thing to keep in mind. ✌️

Hey Team, I'm developing an app that normally resides in the menu bar and has no Dock icon (activation policy set to accessory. When the user clicks the status icon, and selects 'Settings' in the menu, I change the activation policy to regular, show the window, and activate the app. Since cooperative activation was introduced, the option to ignore all apps when activating was deprecated, so I activate the app without the option. The result is that in 20% of the times, the window doesn't come to the front, or the app is not activated. The user obviously wants this behavior, so what is the proper way to achieve it? Thanks, Ari

I'm heavily involved in making reusable components for specific features, as well as generic ones as part of a design system / component library. Does Apple have any guidance doing this? There is a lot to be learned from the decisions around the 'style' APIs, as well as the overloaded constrained initializers of views like Label. The design system should be opinionated, but allow a degree of flexibility. I liked Sarah's talk about incorporating brand which is certainly important when building components for 10+ apps, internal and external. The focus on purposeful design, but there isn't much at a technical level for designing (coding) reusable components and embracing strategies using the Environment, making custom EnvironmentValues, leveraging built-in system constructs, etc. Any resources and guidance here would be welcomed!

I am encountering a systemic issue on macOS where NSViewRepresentable (and some native container views like Table) completely discard explicit SwiftUI animations when the state change is handled via an .onChange modifier. While the exact same reactive architecture produces fluid animations on iOS, the AppKit bridge on macOS snaps the frame updates instantly. I have filed a formal bug report for this behavior, but I want to open this up to the community to see if anyone has found a cleaner architectural workaround. The Problem When observing a state change (e.g., via @AppStorage, @SceneStorage, or local state) using .onChange, applying a withAnimation block fails to animate the underlying layer changes in an AppKit representable view. // The Reactive Pattern that breaks on macOS .onChange(of: toggle) { newValue in withAnimation(.easeInOut(duration: 0.5)) { self.targetColor = newValue ? .systemBlue : .systemRed } } The Diagnostic Anomaly If you inspect context.transaction inside the updateNSView(_:context:) method during this lifecycle pass, SwiftUI reports that the transaction is animated: func updateNSView(_ nsView: NSView, context: Context) { // Prints 'true', indicating SwiftUI thinks it's animating print("Is Animated: \(context.transaction.animation != nil)") // Result: Snaps instantly. No animation occurs. nsView.layer?.backgroundColor = targetColor.cgColor } Why It Happens (The Double-Commit) It appears that on macOS, .onChange flushes a static layout transaction to the window layer immediately upon the state mutating. By the time the withAnimation block evaluates inside the closure, the AppKit backing layer has already processed a implicit setDisableActions(true) directive. The GPU pipeline for that transaction frame is effectively closed, despite what the context.transaction metadata claims. The Low-Level Workaround To force the AppKit bridge to respect the animation intent, I have to manually drop into Core Animation inside updateNSView and explicitly veto SwiftUI's action-disabling behavior: func updateNSView(_ nsView: NSView, context: Context) { CATransaction.begin() if context.transaction.animation != nil { // Explicitly override SwiftUI's implicit frame lock CATransaction.setDisableActions(false) CATransaction.setAnimationDuration(0.5) // Hardcoded fallback match } else { CATransaction.setDisableActions(true) } nsView.layer?.backgroundColor = targetColor.cgColor CATransaction.commit() } My Questions: Is this intentional behavior due to how AppKit's layer-backed architectures handle frame integrity vs. iOS's fluid layout engine? Has anyone found a way to bridge SwiftUI's Animation type curves (like .spring()) cleanly down into the CATransaction or NSAnimationContext layer without hardcoding durations inside updateNSView? Is there a purely "Reactive" paradigm that avoids mutating state at the primary action source (e.g., forcing a Button to own the animation logic) while maintaining fluid transitions on macOS?

Received a response from Quinn @ DTS on FB23017010 regarding the com.apple.spaces plist restructure in Golden Gate. He confirmed no public Spaces API exists and suggested the plist change may be treated as a compatibility bug. He recommended filing an Enhancement Request for a proper API. Two follow-up questions for AppKit engineers: (1) Which Feedback component gets an ER for a public Spaces management API in front of the right team — AppKit, CoreOS, or Mission Control? (2) Is there any timeline visibility on the compatibility bug determination for the Monitors key removal?"

We've been getting stack overflows in code we don't control, in the background AsyncRenderer thread in a chain of calls to updateInheritedViewAsync. But the stack is less than 200 calls deep, presumably because it's a background thread with a smaller stack limit. Is it possible to adjust AsyncRenderer's stack limit? Or otherwise, what limits should we be aware of to prevent running into this issue? com.apple.SwiftUI.AsyncRenderer: EXC_BAD_ACCESS (code=2, address=0x16f5ebe30) #0 0x000000019c6b4460 in function signature specialization <Arg[3] = Dead> of static SwiftUI.DisplayList.ViewUpdater.Model.merge(item: inout SwiftUI.DisplayList.Item, index: SwiftUI.DisplayList.Index, into: inout SwiftUI.DisplayList.ViewUpdater.Model.State) -> SwiftUI.DisplayList.ViewUpdater.Model.MergedViewRequirements () #1 0x000000019c7c2850 in SwiftUI.DisplayList.ViewUpdater.updateInheritedViewAsync(platform: SwiftUI.DisplayList.ViewUpdater.Platform, oldItem: SwiftUI.DisplayList.Item, oldParentState: Swift.UnsafePointer<SwiftUI.DisplayList.ViewUpdater.Model.State>, newItem: SwiftUI.DisplayList.Item, newParentState: Swift.UnsafePointer<SwiftUI.DisplayList.ViewUpdater.Model.State>) -> Swift.Optional<SwiftUI.Time> () #2 0x000000019c7c3ef0 in SwiftUI.DisplayList.ViewUpdater.updateInheritedViewAsync(platform: SwiftUI.DisplayList.ViewUpdater.Platform, oldItem: SwiftUI.DisplayList.Item, oldParentState: Swift.UnsafePointer<SwiftUI.DisplayList.ViewUpdater.Model.State>, newItem: SwiftUI.DisplayList.Item, newParentState: Swift.UnsafePointer<SwiftUI.DisplayList.ViewUpdater.Model.State>) -> Swift.Optional<SwiftUI.Time> () #3 0x000000019c7c3ef0 in SwiftUI.DisplayList.ViewUpdater.updateInheritedViewAsync(platform: SwiftUI.DisplayList.ViewUpdater.Platform, oldItem: SwiftUI.DisplayList.Item, oldParentState: Swift.UnsafePointer<SwiftUI.DisplayList.ViewUpdater.Model.State>, newItem: SwiftUI.DisplayList.Item, newParentState: Swift.UnsafePointer<SwiftUI.DisplayList.ViewUpdater.Model.State>) -> Swift.Optional<SwiftUI.Time> () #4 0x000000019c7c3ef0 in SwiftUI.DisplayList.ViewUpdater.updateInheritedViewAsync(platform: SwiftUI.DisplayList.ViewUpdater.Platform, oldItem: SwiftUI.DisplayList.Item, oldParentState: Swift.UnsafePointer<SwiftUI.DisplayList.ViewUpdater.Model.State>, newItem: SwiftUI.DisplayList.Item, newParentState: Swift.UnsafePointer<SwiftUI.DisplayList.ViewUpdater.Model.State>) -> Swift.Optional<SwiftUI.Time> () ... #147 0x000000019c7c364c in SwiftUI.DisplayList.ViewUpdater.updateInheritedViewAsync(platform: SwiftUI.DisplayList.ViewUpdater.Platform, oldItem: SwiftUI.DisplayList.Item, oldParentState: Swift.UnsafePointer<SwiftUI.DisplayList.ViewUpdater.Model.State>, newItem: SwiftUI.DisplayList.Item, newParentState: Swift.UnsafePointer<SwiftUI.DisplayList.ViewUpdater.Model.State>) -> Swift.Optional<SwiftUI.Time> () #148 0x000000019c7c2074 in SwiftUI.DisplayList.ViewUpdater.updateAsync(platform: SwiftUI.DisplayList.ViewUpdater.Platform, oldList: SwiftUI.DisplayList, oldParentState: Swift.UnsafePointer<SwiftUI.DisplayList.ViewUpdater.Model.State>, newList: SwiftUI.DisplayList, newParentState: Swift.UnsafePointer<SwiftUI.DisplayList.ViewUpdater.Model.State>) -> Swift.Optional<SwiftUI.Time> () #149 0x000000019c7c1a78 in renderAsync () #150 0x000000019c60fc68 in renderDisplayList () #151 0x000000019c612094 in protocol witness for SwiftUI.ViewGraphRenderHost.renderDisplayList(_: SwiftUI.DisplayList, asynchronously: Swift.Bool, time: SwiftUI.Time, nextTime: SwiftUI.Time, targetTimestamp: Swift.Optional<SwiftUI.Time>, version: SwiftUI.DisplayList.Version, maxVersion: SwiftUI.DisplayList.Version) -> SwiftUI.Time in conformance SwiftUI.ViewGraph : SwiftUI.ViewGraphRenderHost in SwiftUI () #152 0x000000019c7c0dd0 in renderAsync () #153 0x000000019c7be6c8 in SwiftUI.ViewGraphHost.displayLinkTimer(timestamp: SwiftUI.Time, targetTimestamp: SwiftUI.Time, isAsyncThread: Swift.Bool) -> () () #154 0x000000019c7beab8 in SwiftUI.ViewGraphDisplayLink.displayLinkTimer(__C.CADisplayLink) -> () () #155 0x000000019c7be5a8 in @objc SwiftUI.ViewGraphDisplayLink.displayLinkTimer(__C.CADisplayLink) -> () () #156 0x0000000192fdbb24 in CA::Display::DisplayLinkItem::dispatch_ () #157 0x0000000192fb9164 in CA::Display::DisplayLink::dispatch_items () #158 0x0000000192f91870 in display_timer_callback () #159 0x000000019256d4cc in __CFMachPortPerform () #160 0x000000019259d0b0 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ () #161 0x000000019259cfd8 in __CFRunLoopDoSource1 () #162 0x0000000192574c1c in __CFRunLoopRun () #163 0x0000000192573a6c in _CFRunLoopRunSpecificWithOptions () #164 0x0000000190533f54 in -[NSRunLoop(NSRunLoop) runMode:beforeDate:] () #165 0x000000018fb9a51c in -[NSRunLoop(NSRunLoop) run] () #166 0x000000019c7cd5b0 in function signature specialization <Arg[1] = Dead> of static SwiftUI.ViewGraphDisplayLink.asyncThread(arg: Swift.Optional<Any>) -> () () #167 0x000000019c7cd288 in @objc static SwiftUI.ViewGraphDisplayLink.asyncThread(arg: Swift.Optional<Any>) -> () () #168 0x000000018fbf321c in __NSThread__start__ () #169 0x00000001ef0d044c in _pthread_start ()

How does using the new +[UILookToScrollInteraction exclusionRegionInteraction]differ from setting a UIScrollView's lookToScrollAxes to an empty option set? Is UILookToScrollInteraction designed to be applied to scroll edge element containers?

Hi! I’m struggling a bit with data flows in SwiftUI. Most SwiftUI sample apps I’ve seen use one large app model / store and inject that into the environment. That works for small samples, but I’m not sure how this should scale in a real app where the data is naturally split into multiple models/services. For example, I may have separate types for things like: @Observable final class AuthModel { ... } @Observable final class MediaSourcesModel { ... } @Observable final class UsersModel { ... } final class HTTPClient { ... } Some of these only make sense once the user is logged in. For example, media sources, user data, and the HTTP client may all depend on the current user/session/token. What I’m struggling with is where these objects should be owned and created in a SwiftUI app. I’m trying to avoid creating them directly inside a view body, because that can recreate them as the view updates. I’m also unsure whether putting this setup in custom view initializers is the right direction, since SwiftUI views are lightweight and can be reconstructed. What is the recommended ownership / data-flow pattern for this kind of setup? More specifically, how should a SwiftUI app usually handle several separate models that depend on login state, without turning everything into one large global model? Thank you!

First of all, thank you for updating the sidebar visuals in macOS 27! However, in macOS 27, an NSSearchField subclass placed in a sidebar or inspector appears with the same Liquid Glass button-like styling as toolbar items and other buttons. This behavior seems specific to NSSearchField; for example, a plain NSTextField does not exhibit the same appearance. While this styling may be appropriate in a toolbar, it feels out of place for a search field embedded in a sidebar or inspector. This appearance makes the search field visually indistinguishable from adjacent buttons and reduces its affordance as a text input control. Is there a supported way to control or override the appearance of an NSSearchField placed in a sidebar or inspector in macOS 27, so that it uses a more traditional search field style instead of the Liquid Glass button-like appearance? As a point of reference, Xcode 27 Beta 1 on macOS 27 Beta 1 does not appear to apply the Liquid Glass–style appearance to search fields in its sidebar. This may be because those fields are not implemented as direct subclasses of NSSearchField; however, I believe it also suggests that the Liquid Glass style is not well suited to search fields in this context.

I am giving the user a view onto a selection of database records. There could be a handful of these, there could be 10,000 of them. At present I use a UITableView. Cells are therefore created or recycled on demand. When a cell is created, it is displayed with default "empty" contents and it sends a message to the server to request a record. When the record arrives, the cell is then able to change its own contents so that the record appears on the screen. There are of course various optimisations, such as cancelling a request if the cell goes offscreen before a reply is received; or delaying a request if it looks as if the cell will end up being off the screen once scrolling has stopped. All this happens with fixed-height cells. Accordingly the UITableView has all the data it needs to work out where every one of the 10,000 cells is. I now want to extend this to variable-height cells. That is: cells whose height depends on the content received from the database. Accordingly, when a cell receives its data it may find itself having to change its own size. Is this structure practicable with UITableView?

Can I build and ship Apple Intelligence features entirely in React Native, or do I need to adopt Swift for some or all of the Apple Intelligence APIs? If Swift is required, which specific capabilities cannot be accessed directly from React Native?

Good morning! Our app is currently a mix of UIKit and SwiftUI. All new code is SwiftUI and we’re gradually replacing old code but for now we have SwiftUI views in UIHostingControllers where needed. Our app is a dark color scheme regardless of the device light/dark setting. One issue we’ve have is that some view in the hierarchy of the UIHostingController seems to have a white background. This is not normally visible, but when sliding views on and off in navigation, there’s a hint of white showing at the edge of the view as it moves. It’s subtle but users have noticed. I thought I filed this bug some time ago but I can’t find it. Just wondering if you’re aware and if there’s any update.

macOS Tahoe fails to close NSWindows after display sleep, causing window accumulation and performance degradation We have a feedback open for this problem on Tahoe (FB21391882) as well as a DTS track. Our QA team has verified that this is still occurring with the Golden Gate Beta 1. I am wondering if this is going to be prioritized as an issue in Golden Gate, or if this is not going to be looked into any further. Honestly I am not sure this is the forum for this, but I was not sure where else to ask at WWDC this year due to the lack of 1-1 appointments.

We have a status item which works fine on macOS 26 and earlier, which has the following properties: Supports left-click to open main UI (a popover) Supports left-click (while open) to toggle (close) the main UI Supports right-click to show "app" menu (e.g. About, Quit) Supports a drop destination to accept files and folders, which then triggers the main UI for more interaction In macOS 27: left-click seems ok if we use expanded interface session, but otherwise broken left-click while open no longer toggles (event is missing?) right click is no longer operational, to the point that it seems the Menu Bar doesn't forward the event at all. Other (Apple-provided) items work fine, and expose new context menus Dragging now triggers Mission Control, which seems wrong given the destination was in the Menu Bar (FB23018381). Are these interactions now forbidden, and are there lists or documentation of the new rules? As an additional bug, it looks like popovers don't pick up appearance changes. The child scroll view claims to be in light appearance in the View Debugger, but is clearly showing the wrong background color, this is a new (as-yet unreported) issue. One last bug: expanded interface session seems to suppress the popover's animation when shown.

We are experience hundreds of long hitches when volumn is changed, it looks like app stuck on rendering. Is this resolved in iOS27? There is the callstack: Thread 0: 0 QuartzCore -[CALayer animationForKey:] + 172 1 QuartzCore -[CALayer animationForKey:] + 124 2 UIKitCore -[UIViewAnimationState _shouldAnimateAdditivelyForKey:onLayer:forView:] + 356 3 UIKitCore -[UIViewAnimationState actionForLayer:forKey:forView:] + 192 4 UIKitCore +[UIView(Animation) _defaultUIViewActionForLayer:forKey:] + 88 5 UIKitCore -[UIView(UIKitManual) actionForLayer:forKey:] + 328 6 QuartzCore -[CALayer actionForKey:] + 152 7 QuartzCore CA::Layer::begin_change(CA::Transaction*, unsigned int, objc_object*, objc_object*&) + 208 8 QuartzCore CA::Layer::set_bounds(CA::Rect const&, bool) + 348 9 QuartzCore -[CALayer setBounds:] + 132 10 QuartzCore -[CALayer setFrame:] + 408 11 UIKitCore -[UIView _backing_setFrame:] + 244 12 UIKitCore -[UIView(Geometry) setFrame:] + 348 13 UIKitCore -[_UISlideriOSVisualElement _layoutSubviewsForBoundsChange:] + 1144 14 UIKitCore -[_UISlideriOSVisualElement _setValue:andSendAction:] + 248 15 UIKitCore +[UIView(UIViewAnimationWithBlocks) _setupAnimationWithDuration:delay:view:options:factory:animations:start:animationStateGenerator:completion:] + 548 16 UIKitCore +[UIView(UIViewAnimationWithBlocks) animateWithDuration:delay:options:animations:completion:] + 48 17 UIKitCore -[_UISlideriOSVisualElement setValue:animated:] + 628 18 MediaPlayer -[MPVolumeSlider _updateVolumeAnimated:silenceVolumeHUD:] + 148 19 MediaPlayer -[MPVolumeController volumeControllerDataSource:didChangeVolume:silenceVolumeHUD:] + 104 20 MediaPlayer -[MPVolumeControllerSystemDataSource _notifyVolumeDidChage:silenceVolumeHUD:] + 84 21 MediaPlayer -[MPVolumeControllerSystemDataSource updateVolume:silenceVolumeHUD:] + 116 22 MediaPlayer __61-[MPVolumeControllerSystemDataSource _systemVolumeDidChange:]_block_invoke_2 + 260 23 libdispatch.dylib _dispatch_call_block_and_release + 32 24 libdispatch.dylib _dispatch_client_callout + 16 25 libdispatch.dylib _dispatch_main_queue_drain.cold.6 + 832 26 libdispatch.dylib _dispatch_main_queue_drain + 176 27 libdispatch.dylib _dispatch_main_queue_callback_4CF + 44 28 CoreFoundation __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16 29 CoreFoundation __CFRunLoopRun + 1944 30 CoreFoundation _CFRunLoopRunSpecificWithOptions + 532 31 GraphicsServices GSEventRunModal + 120 32 UIKitCore -[UIApplication _run] + 796 33 UIKitCore UIApplicationMain + 332

Hey Team, In my app there are bordered toolbar buttons with a button type of toggle. Before Liquid Glass, such a button with an on state would paint its template image in accent color. After removing UIDesignRequiresCompatibility, these buttons no longer show their state. What is the best practice to migrate these buttons to Liquid Glass? Thank, Ari

Previously, the Mac version of my app was built with Mac Catalyst. However, because using the menu bar was inconvenient, I started migrating the Mac version to a native Mac build. Later, I found that starting around macOS 26.4.1, the menu bar that used to appear with my original SwiftUI implementation suddenly stopped showing. As a result, I had to switch back and use an AppKit bridge instead. In addition, I noticed that many visual elements look very strange when built with Mac Catalyst, so I have to adjust each page one by one. I would like to know whether there is a guide for migrating from Mac Catalyst to native Mac, especially regarding style adaptation, so that I can follow the guide and make the necessary changes systematically. Finally, since one of SwiftUI’s advantages is multi-platform deployment, why can’t these styling issues be adapted automatically?

Good morning! Our app uses a dark color scheme regardless of light/dark mode. One issue we’ve had with Liquid Glass has been that buttons in the nav bar do an animation when views are pushed or popped, and the Liquid Glass elements appear to flash during those animations. Are you aware of this behavior? Is there a solution? I suspect that the buttons are mixing in some white even though our background is near black.

I've gotten diagnostics from a couple of my users experiencing a rare issue. The logs in the diagnostics clearly show that the view controller where the issue occurs gets viewDidLoad called twice, and then does not get viewWillAppear or viewDidAppear. This triggers a bug for me because the view controller loads the data it's meant to display in viewWillAppear. I can work around this by changing my data loading logic, but I'd like to know what the underlying issue is. Can anyone point me to some possible ways I could be triggering this weird UIKit behavior?