I’m seeing inconsistent right-to-left behavior when using the new SwiftUI swipeActionsContainer() API with a ScrollView. The swipe-action buttons are positioned correctly according to the layout direction, but the gesture direction itself is not mirrored. Minimal reproducible example: import SwiftUI struct ContentView: View { var body: some View { ScrollView { LazyVStack { Text("Hello, World!") .padding() .frame(maxWidth: .infinity) .background(.blue.quinary) .swipeActions { Button(role: .destructive) { // Delete action } label: { Label("Delete", systemImage: "trash") } } } .padding() } .swipeActionsContainer() } } Steps to reproduce: Run the example using a left-to-right language such as English. Swipe the row from right to left. The trailing swipe actions appear correctly. Change the app language to Arabic. Swipe the row from left to right, which should reveal the trailing actions in an RTL layout. Nothing happens. Swipe from right to left instead. The actions appear, but from the correct visually mirrored edge. Expected behavior: Because the default swipe-action edge is .trailing, both the action placement and the gesture direction should follow the current layout direction: English/LTR: swipe from right to left. Arabic/RTL: swipe from left to right. Actual behavior: The action buttons visually respect the RTL layout, but the gesture recognizer still requires the LTR swipe direction. Environment: Xcode: 27.0 RC iOS: 27.0 RC Device: iPhone 17 Swift language version: Swift 6

I’m seeing a reproducible title-bar interaction issue on macOS 27 RC (26A428). This issue has been present since at least macOS 27 build 26A5416b (Developer Beta 6 / Public Beta 4) and is still reproducible on the Release Candidate, build 26A428. My System Settings → Desktop & Dock → Window title bar double-click action is configured to Fill. In several system apps with sidebars, including: Finder System Settings Reminders Feedback Assistant the right side of the title bar shows a visible rectangular region when the pointer hovers over it. The more important problem is that the middle portion of this region appears to intercept the title-bar double-click. Double-clicking there does nothing, while double-clicking very close to the top or bottom edge of the same region correctly triggers Fill. This makes the normal title-bar gesture surprisingly difficult to use because the center of the title bar is naturally where I would double-click. Interestingly, the sidebar area does not have this problem: double-clicking the top, middle, or bottom portions of the sidebar title-bar area all works normally. Feedback Assistant makes the behavior particularly easy to see because its left sidebar and rightmost pane behave normally, while the title-bar region above the middle pane exhibits the problem. Steps to reproduce: Set “Double-click a window’s title bar” to Fill in Desktop & Dock settings. Open Finder, System Settings, Reminders, or Feedback Assistant. Move the pointer over the right/content portion of the title bar until the rectangular hover region appears. Double-click around the center of that region. The Fill action does not occur. Double-click very close to the upper or lower edge of the same region. Fill works normally. I have reproduced this on macOS 27 RC build 26A428, including: a newly created macOS user account Safe Mode so it does not appear to be caused by migrated preferences, caches, login items, or third-party software. A screen recording demonstrating the exact hit-testing behavior was submitted through Feedback Assistant. Feedback: FB24462749 Is anyone else able to reproduce this? It looks as though some view or overlay in the new title-bar/toolbar area may be intercepting mouse events.

I've encountered crashes when trying to reorder items using the new reordering API. Fatal error: Unexpected identifier type. Expected UUID, got UUID To reproduce, simply run one of the 2 first tests and comment out the others: import SwiftUI @main struct MyApp: App { var body: some Scene { WindowGroup { ContentView() } } } struct Task: Identifiable { let id = UUID() var title: String } struct ContentView: View { @State private var tasks = [ Task(title: "Design Invoice"), Task(title: "Send Proposal"), Task(title: "Review Feedback"), Task(title: "Publish Update") ] @State private var showingPopover: Bool = false var body: some View { ScrollView { LazyVGrid( columns: [ GridItem(.adaptive(minimum: 100)) ] ) { ForEach(tasks) { task in // Test 1: This will crash when reordering if #available(iOS 26.0, macOS 26, *) { Text(task.title) .frame(maxWidth: .infinity) .padding() .background(.blue.opacity(0.1)) .clipShape(.rect(cornerRadius: 12)) } else { Text(task.title) .frame(maxWidth: .infinity) .padding() .background(.blue.opacity(0.1)) .clipShape(.rect(cornerRadius: 12)) } // Test 2: This will also crash Text(task.title) .frame(maxWidth: .infinity) .padding() .background(.blue.opacity(0.1)) .clipShape(.rect(cornerRadius: 12)) .popover(isPresented: $showingPopover) { Text("Popover") } // Test 3: This is ok Text(task.title) .frame(maxWidth: .infinity) .padding() .background(.blue.opacity(0.1)) .clipShape(.rect(cornerRadius: 12)) } .reorderable() } .reorderContainer(for: Task.self) { difference in tasks.apply(difference: difference) } } } } extension Array { mutating func apply<CollectionID: Hashable & Sendable>( difference: ReorderDifference<Element.ID, CollectionID> ) where Element: Identifiable, Element.ID: Sendable { // Find the source element that moved. guard let sourceIndex = firstIndex( where: { $0.id == difference.sources[0] } ) else { return } let movedElement = remove(at: sourceIndex) // Find the destination of that element. var destination: Int switch difference.destination.position { case let .before(value): guard let index = firstIndex( where: { $0.id == value } ) else { return } destination = index case .end: destination = endIndex } insert(movedElement, at: destination) } } I hope this is not just a limitation for the 27 release and is a bug that will be addressed in the next betas. Perhaps I'm just doing something wrong? In such case, thanks for pointing out what. FB23640379

Feedback submitted: FB24460699 The sample projects are attached to the feedback report. Environment:iOS27 Beta6; iPhone 17Pro Problem:I have encountered a consistently reproducible third-party custom keyboard layout issue in iOS 27.0 beta 1 through beta 6. The custom keyboard initially appears correctly. If I switch apps while the text input remains focused and the keyboard remains visible, and then return to the host app, the system adds a 17-point area above the custom keyboard extension. Steps to reproduce Install and enable a third-party custom keyboard. Switch to the sample custom keyboard and open the host app so that the text editor in the center receives focus. Do not dismiss the keyboard or remove focus from the editor. Return to the Home Screen or switch to another app. Return to the host app. A new blank area now appears above the custom keyboard content. I tested both a system-determined extension view height and an extension view explicitly constrained to 180 points. Both configurations produce exactly the same change. After the foreground transition, the following extension-side values remain unchanged: view.bounds inputView.bounds extension.window.bounds view.safeAreaInsets, which remains {0, 0, 0, 0} The requested 180-point extension height Only the system keyboard frame received by the host app increases by 17 points. I also drew a rounded pink boundary inside the transparent extension root view. When the issue occurs, the new area appears outside that boundary. I tested several third-party keyboards and reproduced the issue with all of them. This suggests that the behavior is caused by iOS rather than by my app. Questions On iOS 27, is it expected behavior for a custom keyboard to gain a 17pt top area after its host app returns from the background? If this is a system issue, is there any workaround that can be used until it is fixed?

Since iPadOS 18, UIDocumentViewController has contained a document browser that shows a white page with rounded corners against a background of your choice, with the app name and "Create Document" buttons on the page. For instance, when you launch Pages, you see a white rounded page rectangle against a background of swirly orange, with “Choose a Template” and “Start Writing” buttons on the white page. In Numbers, there’s a green swirly background. In apps built and run on iPadOS 27, however, the white page with rounded corners is entirely missing, making the browser screen very ugly, with the “New Document” button translucent directly against whatever background is set. This can be reproduced simply by creating a new iOS "Document App" in Xcode 27 and building on iPadOS 27. I assume this is a bug, since if you turn on exception breakpoints, you see the following exception breakpoint triggered during launch: Exception = (NSException *) "[<_UIDocumentLaunchViewController 0x10732b200> valueForUndefinedKey:]: this class is not key value coding-compliant for the key _pageContainerView." I have thus reported it as FB23418746. I am curious, though, whether it is a design decision to remove the page background on iPadOS 27, or whether I am missing some sort of setting in the UIDocumentViewController’s launch options for restoring the page. (I hope it’s not intentional, as I like the page, and without it, the black app name gets lost against darker or busier backgrounds.) (I did try to include screenshots showing the issue when I first went to post this message, but doing so resulted in my IP address being blocked access to the forums for a week because of the forums’ new security measures.)

I have CarPlay Video enabled for my account and App ID. I tested both my main app and a completely new minimal iOS app with a new Bundle ID. The minimal app only contains: UIApplicationDelegate CPTemplateApplicationScene configuration CPTemplateApplicationSceneDelegate A single CPListTemplate root Results: With com.apple.developer.carplay-audio only, CarPlay launches normally. When com.apple.developer.carplay-video is added, CarPlay opens a blank screen. No CarPlay callbacks are called: application(:configurationForConnecting:options:) CPTemplateApplicationSceneDelegate.templateApplicationScene(:didConnect:) CPApplicationDelegate.didConnectCarInterfaceController The signed app and embedded provisioning profile both contain com.apple.developer.carplay-video. Does CarPlay Video require an additional runtime allowlist, specific head unit support, a different scene configuration, or another entitlement beyond com.apple.developer.carplay-video?

I encountered a severe NSColorSampler failure on macOS 27.0 (26A5425a). After invoking: NSColorSampler().show { selectedColor in // Handle selected colour } the system colour sampler became stuck. The pointer disappeared and all mouse clicks were captured across macOS. Pressing Escape did not recover it. Quitting the host application also did not restore clicking. The Apple-owned process remained active after the application exited: /System/Library/Frameworks/AppKit.framework/Versions/C/XPCServices/ColorSampler.xpc/Contents/MacOS/ColorSampler Sending SIGTERM to that process had no effect. Force-terminating it with SIGKILL immediately restored mouse clicking. Environment: macOS 27.0, build 26A5425a MacBook Pro Mac16,8 Apple M4 Pro SwiftUI content hosted inside a borderless AppKit window Expected behaviour: selecting a colour, pressing Escape, or terminating the host application should cancel sampling and release all captured input. Actual behaviour: ColorSampler.xpc survives the host application and continues preventing all mouse clicks system-wide. Feedback Assistant report: FB24722293 Has anyone else reproduced this with NSColorSampler, particularly from a borderless AppKit window?

I’m testing simultaneous finger and Apple Pencil input with PencilKit and have reduced the behaviour to a minimal PKCanvasView. import SwiftUI struct ContentView: View { var body: some View { PencilCanvas() .ignoresSafeArea() } } struct PencilCanvas: UIViewRepresentable { func makeUIView(context: Context) -> PKCanvasView { let canvas = PKCanvasView() canvas.drawingPolicy = .anyInput return canvas } func updateUIView(_ canvas: PKCanvasView, context: Context) {} } On a physical iPad with Apple Pencil, I consistently see this behaviour: Start drawing with a finger and keep the finger moving. Touch the canvas with Apple Pencil. The active finger stroke immediately stops, while the Pencil can draw. The reverse order behaves differently: Start drawing with Apple Pencil and keep it moving. Touch/draw with a finger. The Pencil stroke continues rather than being cancelled. I’ve also confirmed that a newly created PKCanvasView reports isMultipleTouchEnabled == true, and explicitly setting it to true does not change the behaviour. Is simultaneous independent Apple Pencil and finger drawing supported by PKCanvasView when using .drawingPolicy = .anyInput? If so, is there a supported configuration or gesture-recognizer setting required to prevent the Pencil from cancelling an active finger stroke? Or is Pencil taking priority over an active finger drawing gesture expected behaviour in PencilKit?

A paged ScrollView loses its page when the window is resized on iPadOS 27: ScrollView(.horizontal) { HStack(spacing: 0) { ForEach(pages) { page in PageView(page).containerRelativeFrame(.horizontal) } } .scrollTargetLayout() } .scrollTargetBehavior(.paging) .scrollPosition(id: $selection) Expected: the selected page stays edge-aligned after the resize (as TabView(.page) does). Actual: The content offset is preserved in points, not pages — the view rests between pages. scrollPosition(id:) writes nil during the resize, so the selection can't be recovered from the binding. Both .paging and .viewAligned are affected. Repro project (broken ScrollView, TabView control, and workaround side by side, with live instrumentation): https://github.com/katebrr/PagedScrollResizeLab Why not TabView(.page): it has no API for scroll position/progress observation (our analytics depend on it), inter-page spacing, partial-width peeking pages, or pausing the swipe mid-gesture. Workaround (Workaround/View+ScrollPositionResize.swift in the repo): restore the last non-nil selection via scrollTo one Task.yield() after the resize. Works, but lands a frame late and relies on undocumented behavior. Questions: Is this behavior intended, or a bug? Is there a supported way to keep a paged ScrollView anchored to its page across resizes? Is there a more robust formulation than scrollTo after Task.yield()? Filed as FB24688033.

Right now, the traffic light buttons overlapped on my iPad app top corner on windows mode (full screen is fine). How do I properly design my app to avoid the traffic light buttons? Detect that it is iPadOS 26?

A regression has been introduced with SwiftUI Menu in iOS 27 betas (still present in beta 6). This regression prevents objects whose properties are bound to contained Menu items from being correctly deallocated. In the example below, Player was immediately deallocated when the surrounding ModalView was dismissed on iOS 26 (or below): import Observation import SwiftUI @Observable final class Player { var playbackSpeed: Double = 1 } struct ModalView: View { @State private var player = Player() var body: some View { Menu { Picker(selection: $player.playbackSpeed) { ForEach([0.5, 1, 1.5, 2], id: \.self) { speed in Text("\(speed, specifier: "%g×")").tag(speed) } } label: { Text("Speed") } .pickerStyle(.inline) } label: { Text("Menu") } } } This is not the case anymore on iOS 27 beta. The Player instance is not deallocated anymore. A dedicated feedback (FB24486991) has been opened.

I'm currently developing a new app and uses Menu in it. The Menu cannot display text color normally and after if collapses my second text also disappears for a short time. FB19221675 Does anyone has this same issue in iOS 26?

I found a SwiftUI presentation bug with multiple alerts and sheet presentations. I submitted a Feedback Assistant report too: Feedback ID: FB24621651 The issue is that a native SwiftUI alert dismisses immediately after appearing when it is presented from a view inside a nested sheet. Minimal hierarchy: TabView -> NavigationStack -> outer sheet -> NavigationStack -> detail view -> inner sheet -> alert The inner sheet contains a normal button: struct InnerSheetRoot: View { @State private var showAlert = false var body: some View { Button("Show Alert") { showAlert = true } .alert("Alert from inner sheet", isPresented: $showAlert) { Button("OK") {} } message: { Text("This alert should remain visible.") } } } Steps to reproduce Open the attached sample project. Select the Storage tab. Tap any storage row. In the outer sheet, tap Open Inner Sheet. In the inner sheet, tap Show Alert. Actual result The alert appears briefly and dismisses immediately. It may disappear before OK can be tapped. Expected result The alert should remain visible until the user taps OK. The issue disappears when I remove either the root TabView or the second NavigationStack. It also disappears when the inner sheet is removed. Environment: Xcode: Xcode 26.6 macOS: macOS 26.6.2 iOS: iOS 26.5 Device or simulator: iPhone Simulator Deployment target: iOS 26.0 Swift version: Swift 6 The example project and a screen recording are attached to the Feedback Assistant report, but they can also be found here. I would appreciate confirmation of whether this is a known SwiftUI presentation-host issue and whether there is a recommended way to present alerts from content inside nested sheets.

Having custom view inside safeAreaBar(edge: .top) breaking title. NavigationStack { VStack { List { CustomView() .listRowBackground(.customBackground) } .listStyle(.insetGrouped) .scrollContentBackground(.hidden) } .frame(maxWidth: .infinity, maxHeight: .infinity) .background(LinearGradient(...)) .toolbar { ToolbarItem(placement: .title) { Text("Test") } .safeAreaBar(edge: top) { Picker() .pickerStyle(.segmented) .padding([.horizontal, .bottom]) } .navigationTitle("Favorites") } } I have tried to replace .safeAreaBar with .safeAreaInset and then bug of large title is not anymore, but you are loosing blurry background when you scrolling. https://ibb.co/938zXbPV Its also affected in iOS 26, not just iOS 27

I'm seeing a Live Activity that's ended almost immediately after I'm creating it. I'm not ending the activity in my code, so something is happening at the system level. iOS version is 18.3.1. Looking at the logs for liveactivitiesd, I see that it was successfully created: default 12:57:34.837266-0800 liveactivitiesd Created activity: 22713DF6-E853-4B34-85FA-CD08D8FCA91B default 12:57:34.837639-0800 liveactivitiesd Starting activity: identifier: 22713DF6-E853-4B34-85FA-CD08D8FCA91B; createdDate: 2025-02-17 20:57:34 +0000; state: active; deviceIdentifier: local; resolvedContentSources: [ActivityKit.ActivityContentSource.process(target: <snip>), ActivityKit.ActivityContentSource.sync]; lastUpdateDate: 2025-02-17 20:57:34 +0000; endingOptions: nil default 12:57:34.858701-0800 liveactivitiesd Activity did start 22713DF6-E853-4B34-85FA-CD08D8FCA91B But then moments later, it's immediately ended: default 12:57:34.933963-0800 liveactivitiesd Ending activity 22713DF6-E853-4B34-85FA-CD08D8FCA91B for XPC participant content source <private> default 12:57:34.933983-0800 liveactivitiesd Stopping activity: 22713DF6-E853-4B34-85FA-CD08D8FCA91B default 12:57:34.934019-0800 liveactivitiesd Activity: identifier: 22713DF6-E853-4B34-85FA-CD08D8FCA91B; createdDate: 2025-02-17 20:57:34 +0000; state: active; deviceIdentifier: local; resolvedContentSources: [ActivityKit.ActivityContentSource.process(target: <snip>), ActivityKit.ActivityContentSource.sync]; lastUpdateDate: 2025-02-17 20:57:34 +0000; endingOptions: nil should be discarded now default 12:57:34.934442-0800 liveactivitiesd Activity discarded: 22713DF6-E853-4B34-85FA-CD08D8FCA91B Again, I'm not ending this activity in my code. I'll occasionally see this happen in my app, and the only solution I've found is to restart my device. Afterwards, everything seems fine. Is this a bug?

Environment iPadOS 26.0 / 26.1 (Simulator: iPad Air 11-inch (M3)) SwiftUI, NavigationView + .navigationViewStyle(.stack) (also reproduced conceptually with NavigationStack) iPad only Symptom I have a custom split-style layout built with a plain HStack: HStack(spacing: 0) { if showSidebar { Sidebar().frame(width: 80).transition(.move(edge: .leading)) } HStack(spacing: 0) { NavigationStack { MenuList() }.frame(width: 230) Divider() NavigationStack { DetailScreen() } // <- this bar is affected } } Toggling showSidebar inside withAnimation changes the x origin of the right-hand navigation container by 80pt. After that toggle, the Liquid Glass platter (capsule) behind the navigation bar's leading bar button item is drawn at its previous x position, while the button's glyph is laid out correctly. The capsule and the glyph are visually separated by roughly the amount the container moved. Hit testing follows the glyph, so it is purely a rendering/layout mismatch of the platter background. Inspecting the view hierarchy, _UINavigationBarPlatterView / _UINavigationBarPlatterGlassView report a frame that matches the pre-toggle geometry, i.e. the platter container is not re-laid-out when the hosting navigation bar's window-space origin changes without its size changing in a way that triggers a full bar layout pass. Condition It only happens on screens where the navigation bar has exactly one platter group — i.e. a leading item and no trailing items. As soon as the same screen also has a .topBarTrailing item (so UIKit builds two platters), the leading platter is positioned correctly after the toggle. What I tried .id(...) on the toolbar content to force a rebuild: no effect adding a zero-size / hidden trailing ToolbarItem: no effect calling setNeedsLayout() / layoutIfNeeded() on the UINavigationBar after the animation: no effect disabling the animation: no effect The only workaround I found is to opt the leading group out of the system platter entirely and draw my own: ToolbarItemGroup(placement: .topBarLeading) { button .frame(width: 44, height: 44) .glassEffect(.regular.interactive(), in: Circle()) } .sharedBackgroundVisibility(.hidden) This fixes the offset, but it has its own downside — see https://developer.apple.com/forums/thread/811012 — the manually drawn glass does not participate in the navigation push/pop morph the system platter does. Notes The reproduction appears to be sensitive to the exact geometry / device orientation: a reduced sample I built later did not reproduce it reliably, so I have not been able to attach a minimal project yet. If a DTS engineer wants one, I can keep reducing. Questions: Is a plain HStack-based sidebar (rather than NavigationSplitView) an unsupported configuration for the navigation bar platter, i.e. is the platter's position expected to be invalidated only on size changes? Is there a supported way to invalidate the platter layout manually? Is .sharedBackgroundVisibility(.hidden) + manual .glassEffect the recommended escape hatch here, or is it expected to break the push/pop transition?

Feedback Assistant Submission ID Reference : FB24634485 Attached is a sample code where after setting setlocale() to any of European languages or Russian language results in crash when calling NSAlert. Here is code snippet and crash log for reference. #import <Cocoa/Cocoa.h> int main(int argc, const char * argv[]) { @autoreleasepool { NSString* locale = @“fr_FR.UTF8"; setlocale(LC_ALL, locale.UTF8String); return NSApplicationMain(argc, argv); } } (IBAction)showAlertButtonTapped:(id)sender { NSAlert *alert = [[NSAlert alloc] init]; alert.messageText = NSLocalizedString(@"alert_title", nil); alert.informativeText = NSLocalizedString(@"alert_message", nil); alert.alertStyle = NSAlertStyleInformational; [alert addButtonWithTitle:NSLocalizedString(@"alert_ok_button", nil)]; [alert runModal]; } Crashlog

Hi, I noticed some unexpected layout behavior with Button in SwiftUI: the apparent horizontal padding/inset of a Button seems to change depending on the length of its text label. Here is a minimal example: VStack { Button { } label: { Text("我是一段很长的文字") .lineLimit(nil) .frame(maxWidth: .infinity, alignment: .leading) .border(.red) } Button { } label: { Text("我是一段") .lineLimit(nil) .frame(maxWidth: .infinity, alignment: .leading) .border(.red) } } .frame(width: 100) .border(.red) In Preview, the outer VStack has a fixed width of 100pt, and both Button labels use: .frame(maxWidth: .infinity, alignment: .leading) The red border around each Text shows that the label itself is receiving the expected available width. However, the two Buttons appear to have different horizontal insets between the Button's edge and the Text's edge, even though both Buttons are inside the same VStack and have the same layout configuration. In other words, the Button's apparent internal padding seems to depend on the intrinsic width / length of the label: ┌────────────────────┐ │ ┌──────────────┐ │ │ │ Long text │ │ │ └──────────────┘ │ └────────────────────┘ ┌────────────────────┐ │ ┌────────────┐ │ │ │ Short text │ │ │ └────────────┘ │ └────────────────────┘ What I find particularly confusing is that the label itself has: .frame(maxWidth: .infinity) so I would expect both Button labels to occupy the same available width. I'm trying to understand whether this is expected behavior of the default Button style or a consequence of SwiftUI's layout proposal/intrinsic-size system. Specifically: Why does the Button's apparent horizontal padding change based on the label's text length? Does the default Button style intentionally use the label's intrinsic/ideal size when determining its content inset? Is there an official SwiftUI API to specify a fixed horizontal content inset/padding for a Button, independent of the label's intrinsic size? If I want both Buttons to have exactly the same internal horizontal padding, what is the recommended SwiftUI approach? Is there a way to make the Button give its label the full proposed width before applying its own default styling/insets? I'm aware that I can implement a custom ButtonStyle, but I'm specifically wondering whether there is an existing SwiftUI API or modifier intended for controlling this behavior while retaining the system Button style. I'm seeing this behavior in recent versions of SwiftUI and would appreciate any clarification on the intended layout behavior and the recommended solution. Thanks!

Calling AppStore.requestReview(in:) with a valid, foreground-active UIWindowScene never presents the rating/review sheet on iOS 27 Simulator. The identical code works correctly on iOS 26 and earlier Simulator runtimes. Repro: if let windowScene = UIApplication.shared.connectedScenes .compactMap({ $0 as? UIWindowScene }) .first(where: { $0.activationState == .foregroundActive }) { AppStore.requestReview(in: windowScene) } Fresh Simulator install (Erase All Content and Settings first, to rule out the 3-per-365-day throttle). Run on iOS 27 Simulator → no sheet appears, no error, no console output. Run the identical build on iOS 26 Simulator → sheet appears as expected. Also tried: The SwiftUI @Environment(.requestReview) action (RequestReviewAction) instead of the UIKit windowScene call — same result, no prompt on iOS 27 Simulator. Ruled out an Xcode/Simulator-runtime version mismatch: reproduces both with an older Xcode + separately-downloaded iOS 27 runtime, AND with the matching Xcode 27 beta + its bundled iOS 27 Simulator. Checked the iOS 27 beta release notes — no mention of requestReview/StoreKit review prompt changes. Environment: Xcode [fill in version/beta] iOS 27 Simulator (beta [fill in]) Simulator device: [e.g. iPhone 16] Expected: Review prompt presents (subject to the documented frequency limit), matching iOS 26 behavior. Actual: No prompt, no error, on both the UIKit and SwiftUI review-request APIs.

Feedback: FB24659815. I have submitted a screen recording and screenshot through Feedback Assistant. In GGame, quickly swiping back after opening a game home page with the system SwiftUI zoom transition leaves the destination navigation title, back button, settings button and history button over the visible lobby for about one second. During that interval, lobby content does not respond to taps or scrolling, while the tab bar still works. Steps to reproduce: Open the game lobby. Tap a game icon to enter its home page using zoom. Immediately swipe right to return, attempting to interrupt the incoming animation. When the lobby reappears, immediately try to tap or scroll its content and observe the navigation controls. Expected: once the return transition finishes, the destination controls disappear and the visible lobby accepts taps and scrolling. Interrupted entry and cancelled interactive return should remain supported. Current investigation environment: iPhone 16 Pro, iOS 27.0 Seed 7 (24A5430a), Xcode 27 beta 4. The supplied owner recording shows the visual symptom across Connect Four, Chinese Chess and Chess; the exact build used in those original attachments has not been independently verified. The app uses NavigationStack, matchedTransitionSource and navigationTransition(.zoom(...)). It also has application-side navigation-bar visibility, transition-state and gesture coordination. We have not isolated the exact symptoms in a minimal project without that logic, so the root cause remains unconfirmed. Potentially related discussions: https://developer.apple.com/forums/thread/796805 https://developer.apple.com/forums/thread/802908 Those reports primarily describe disappearing source views that remain tappable. Our issue involves lingering destination controls and temporarily unresponsive root content. I am opening a separate thread to track these differences. Has anyone observed this specific combination? Could the SwiftUI/navigation team check FB24659815 and advise whether this is a framework issue or an application-side lifecycle/gesture interaction? We would appreciate a fix or supported workaround that preserves the system zoom animation and interactive cancellation. The temporary loss of lobby interaction makes this especially disruptive.