My iPhone App has requirement to be locked to portrait, except on certain screens like when showing a video player or other content. What is the best SwiftUI way to do this?

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)?

The primary column sidebar in iPadOS 26 has a 10pt padding (not sure if we can access this value programmatically) which we hard-coded for edge inset calculations of the secondary view. It appears this padding is still present with the new design. Can we derive this property reliably somehow?

For developing an iOS fully-featured code editor (i.e line numbers + color pass for syntax highlighting + collapsible sections + debug markers/highlights) what would be the best strategy for iOS 27? UITextView with new viewport control delegate Custom TextKit2 UIView Custom TextKit1 UIView (this was the recommendation I got as of WWDC25)

I added images to all NSMenuItems in my app on macOS 26. Now, with macOS 27 beta 1, most of them are no longer displayed, which seems to be the behavior of NSMenuItem.ImageVisibility.automatic. However, this only happens for images initialized with NSImage(systemSymbolName:accessibilityDescription:). Images initialized with NSImage(named:) are still shown, despite the visibility setting being .automatic. What would be an approach that is consistent for all app-contributed NSMenuItems while still respecting the system default? Even more, how would one set image visibility to also address possible future system settings that decide on menu-item image visibility? As a side note, the documentation for NSMenuItem.ImageVisibility has no description for .automatic, and the documentation for .hidden and .visible seems wrong or misleading (or I'm misunderstanding): .hidden: The item image should always be visible. Note that in some cases, AppKit may still hide the image, overriding this preference. .visible: AppKit should choose whether the item’s image is visible, considering the system configuration.

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

How do I make the sheet occupy the full screen width and bottom when I customize the height of the sheet using presentationDetents?

I get lots of glitches in display of Swift Charts on my iPhone running iOS 27. Works fine on simulator though. Am I the only one?

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

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?

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?

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.

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

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 :)

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?