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.

See existing post here: https://developer.apple.com/forums/thread/803378 When I add a UIScrollEdgeElementContainerInteraction to a view at the top of a scroll view, the blur effect doesn't always fill the full bounds of the view. The behavior changed a bit from 26.0 to 26.1 and then again in 27.0 seed 1. It depends on what subviews are there, and particularly (at least between 26.1 and 26.5) if there's a UIVisualEffectView with a glass effect. FB20756572

Hoping to get some clarification here around how the Liquid Glass opt-out via the UIDesignRequiresCompatibility Info.plist flag works with iOS 27. During the Platforms State of the Union at least year's WWDC, it was mentioned that this flag wouldn't be respected on iOS 27. Is this a case where it's not respected for any app that's downloaded from the App Store regardless of if they were compiled against the iOS 27 SDK, or does this only apply for apps compiled with the iOS 27 SDK (and thus any app compiled with an older SDK would still get the previous design styling)?

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?

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!

In the SwiftUI group lab, an engineer mentioned that there were new ways to customize SwiftUI screen transitions. They mentioned there is a crossfade, which I see in the docs, but they also mentioned other customizations. Did they misspeak, or are there custom screen transitions? I'd love a modern, SwiftUI replacement for custom presentation controllers from UIKit!

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

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?

Hi What would be the best way to achieve clustering on MapKit within SwiftUI? We're building a decentralized commerce auction platform that is currently live in Switzerland with 3'500 live auctions that can be discovered on a map. We're now running into the issue that the map gets cluttered, when zooming out and haven't been able to find a way to cluster We moved back to UIKit, where clustering works, but UIKit has other drawdowns. So ideally there is a way to handle it within SwiftUI without having to wrap UIKit or move back entirely to UIKit. Thanks for any help or suggestions! Developer Documentation https://developer.apple.com/documentation/mapkit/mapkit-for-swiftui Julius Ilg AuctionShack

Summary On iOS 27, tabBarController(:shouldSelect:) — the long-standing UITabBarControllerDelegate method accepting a UIViewController — is no longer invoked when the user taps a tab inside a SwiftUI TabView. Tab selection now routes exclusively through tabBarController(:shouldSelectTab:), the UITab-based variant introduced in iOS 18. Impact Any code that relies on tabBarController(_:shouldSelect:) to: Intercept or prevent tab switches Detect tab reselection Propagate tab-change events to other subsystems (e.g., a JavaScript bridge in a hybrid app) ...will silently stop working on iOS 27. There are no compiler warnings, no deprecation notices, and no runtime assertions — the method simply is no longer called. This affected react-native-bottom-tabs, a widely used open-source library, causing all tab screens beyond the first to render as blank/white after any tab tap (see: https://github.com/callstack/react-native-bottom-tabs/issues/529). The workaround is to implement tabBarController(_:shouldSelectTab:) Reproduction Create a SwiftUI TabView with 3+ tabs. Set a UITabBarControllerDelegate on the underlying UITabBarController. Implement tabBarController(_:shouldSelect:) — e.g., to log or prevent selection. Run on iOS 26 → delegate method fires correctly. Run on iOS 27 Beta → delegate method is never called. Request / Questions Is this an intentional behavioral change for iOS 27? If so, it constitutes an undocumented, silent API break for any code targeting UITabBarControllerDelegate. The old method still compiles and links without any warning. Will tabBarController(_:shouldSelect:) be formally deprecated with a corresponding compiler warning so developers can find and migrate affected call sites? Is tabBarController(_:shouldSelectTab:) now the exclusive interception point on iOS 27, even for apps that haven't fully migrated to the new UITab-based API? We'd appreciate any official guidance so libraries and apps can ship iOS 27-compatible binaries with confidence. Environment Xcode 26.5 / 17F42 iOS 27 Beta Reproducible in both UIKit and hybrid (React Native) contexts

Bug 1 strange little square↗ Bug 2 Sometimes half of the time would disappear so maybe the time is under the things on the right

On Xcode 27, the compiler incorrectly errors when a @State variable definition is placed on multiple lines. The code compiles without any issues on Xcode 26 and is valid Swift. The issue is fixed if the var definition is placed on a single line. The following code produces issues: @State internal var bodyText = "Hi" However, the code below works: @State internal var bodyText = "Hi" The issue is reproducible in any new project with a simple view: import SwiftUI import Playgrounds @main struct MyApp: App { var body: some Scene { WindowGroup { ContentView() } } } struct ContentView: View { @State internal var bodyText = "Hi" var body: some View { Text(bodyText) .padding() } } #Preview { ContentView() } The expected behavior is for valid Swift code to not trigger compiler error. Filed FB23044343

It seems like the automatic edge effect defaults to hard in iOS 27 and soft on iOS 26. Designing for both of these is actually quite difficult - especially since hard edge effects don't work with pinned views in LazyVStack. Is there a way to set the global default to soft for an app?

Looking through iOS 27, one thing I don't really like overall is that they brought back the toolbar background with the tint on the top of the screen. I actually really enjoyed how it looked in iOS 26. Is there a way to revert that with a .toolbar function?

I've got an iOS app with a custom top toolbar view that uses a UIScrollEdgeElementContainerInteraction to achieve the iOS 26 progressive blur background. It's over top of a web view, and I've set the top edge effect style on its scroll view to .hard so the toolbar's edges are more defined. I'm noticing that the blur doesn't extend fully to the bottom edge of the toolbar, and I'm curious to know if this is a bug or expected behavior. If the latter, what exactly are the details of what's expected? What determines the bottom extent of the blur? I've got this result in a sample project on iOS 26.0. The white border is the label, and the red border is the title bar view itself. Note that the Daring Fireball logo visible inside the bounds of the bar view, and is cut off at the bottom edge of the label. This is the code from the demo app that produced the screenshot. let config = WKWebViewConfiguration() let webView = WKWebView(frame: .zero, configuration: config) self.view.addSubview(webView) webView.translatesAutoresizingMaskIntoConstraints = false webView.topAnchor.constraint(equalTo: self.view.topAnchor).isActive = true; webView.bottomAnchor.constraint(equalTo: self.view.bottomAnchor).isActive = true; webView.leftAnchor.constraint(equalTo: self.view.leftAnchor).isActive = true; webView.rightAnchor.constraint(equalTo: self.view.rightAnchor).isActive = true; webView.scrollView.topEdgeEffect.style = .hard webView.load(URLRequest(url: URL(string: "https://daringfireball.net")!)) let barView = UIView() self.view.addSubview(barView) barView.translatesAutoresizingMaskIntoConstraints = false barView.topAnchor.constraint(equalTo: self.view.topAnchor).isActive = true; barView.leftAnchor.constraint(equalTo: self.view.leftAnchor).isActive = true barView.rightAnchor.constraint(equalTo: self.view.rightAnchor).isActive = true let edgeEffect = UIScrollEdgeElementContainerInteraction() edgeEffect.scrollView = webView.scrollView edgeEffect.edge = .top barView.addInteraction(edgeEffect) barView.layer.borderColor = UIColor.red.cgColor barView.layer.borderWidth = 1 let titleLabel = UILabel() barView.addSubview(titleLabel) titleLabel.translatesAutoresizingMaskIntoConstraints = false titleLabel.leftAnchor.constraint(equalTo: barView.leftAnchor).isActive = true titleLabel.rightAnchor.constraint(equalTo: barView.rightAnchor).isActive = true titleLabel.bottomAnchor.constraint(equalTo: barView.bottomAnchor, constant: -20).isActive = true titleLabel.topAnchor.constraint(equalTo: barView.safeAreaLayoutGuide.topAnchor, constant: 8).isActive = true titleLabel.textAlignment = .center titleLabel.text = "Title Here" titleLabel.layer.borderColor = UIColor.green.cgColor titleLabel.layer.borderWidth = 1

Hi, I am using the CPPointOfinterestTemplate and wanted to change the trailingNavigationBarButtons when the user navigate to detail screen(This is done with the help of didSelectPointOfInterest delegate function). However i could not find any documentation on resetting the trailingNavigationBarButtons when the user click on the "X"/Close button on the details screen. Can you explain if there is any way i can handle my

I have an NSTextView subclass and implements drag and drop for custom draggable data, so I override -writablePasteboardTypes and add my own type as described in the header file: // Returns an array of pasteboard types that can be provided from the current selection. Overriders should copy the result from super and add their own new types. @property (readonly, copy) NSArray<NSPasteboardType> *writablePasteboardTypes; Now my textview also accepts the drop. Drag and drop can be used to move the custom data to a different location in the text view's character range. Like grabbing a block of text and moving it. So I accept the drop in -readSelectionFromPasteboard:type: I have a variable I cache at the start of dragging like: _myDraggingItem = // Set at the start of dragging. Then when I accept the drop I just use _myDraggingItem to move it to the drop location in the text view. I don't need to actually serialize the entire object and write it on the pasteboard I can just use _myDraggingItem to move from the source location to destination location. This is local only drag and drop. it works, except when the mouse leaves the text view briefly during the dragging session. This is because I override NSTextView's - (void)cleanUpAfterDragOperation // If you set up persistent state that should go away when the drag operation finishes, you can clean it up here. Such state is usually set up in -dragOperationForDraggingInfo:type:. You should probably never need to call this except to message super in an override. - (void)cleanUpAfterDragOperation; So documentation indicates -cleanUpAfterDragOperation is for clean up after drag operation finishes so I nil out _myDraggingItem here. But -cleanUpAfterDragOperation is getting called from [NSDragDestination _draggingExited]. -draggingExited: means the drag location moved outside the view it does not mean that the dragging session is over. The drag can move back inside the view after briefly exiting, so this isn't a usable place to clean up state tied to the dragging session as the header file indicates. I must override -draggingEnded: instead. If that sounds like a bug let me know.

If the main app requires sign-in, what’s the recommended pattern for sharing auth/session state with widget or watch extensions so users aren’t prompted to log in again when tapping a widget?

For complications that display data from the iPhone app, is pushing updates from the phone still the right model, or should complications fetch independently on the watch when connectivity is available?