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?

When a widget opens a specific screen in the main app, what’s the best way to pass structured state — like an item ID, date, and scroll position — so navigation works on cold launch and doesn’t conflict with an existing navigation stack?

For data that changes throughout the day, like weather or schedules, what’s the most reliable refresh strategy for WidgetKit: timeline policies, background tasks, push notifications, or user-driven reloads?

If the main app isn’t fully SwiftUI, but you also ship native SwiftUI widget extensions, watch complications, and a watchOS app, what’s the recommended way to share models, formatting, and chart logic across those targets without duplicating code?

Hello, After adapting Liquid Glass for iOS 26.5, I encountered an issue: the leftBarButtonItem(s) shift right, leaving a large space on the left after launching and dismissing the camera. I tried adding a negative spacer and setting leading space, but neither worked. This only happens when launching the camera; it does not occur during photo selection.

Hi :-) I need some advice to fix the following issues in SwiftUI. I don't have the source code myself, but I'd like to help the programmer fix the problem quickly. So I'm looking for a few lines of Example-Code that I can show these Code-Lines to help resolve this quickly. 1. "Jumping shadow" when swiping => The Shadow under the Genre.Buttons jumps when you swipe through them. 2. Liquid Glass Flicker => The Liquid Glass EDGE on a poster or on the buttons flickers (abruptly disappear) when switching from one page to another Can someone help me? Bets regards, Christian :)

in iOS26.4, after installing the app for the first time, opening the app and clicking on the UITextField input box will trigger the system to pop up the network permission application interface. This issue did not exist before iOS 26.3, only in iOS 26.4. This is a fatal bug where the network permission request box should not pop up when the developer has not called the network related API.

It appears that on all recent versions of macOS when adding a new InputSource in /Library/Input Methods (or modifying an existing one there) the user needs to logoff and log back in in order for Keyboard/Input Sources in System Settings and Input Menu in menu bar to pick up the changes. Is there a way to avoid this? That is, some notification to send or API to call to tell both of these "hey, things might have changed on disk, please re-read the info, and update the UI". 🙂