Two of my apps share data through an App Group. One uses canOpenURL to avoid generating data when the companion app isn’t installed. The other uses it to avoid displaying previously shared data after the first app is uninstalled, because tapping that data opens the first app. With canOpenURL deprecated in iOS 27, is there a supported way to check companion-app availability without launching it? Calling open or using a universal link would launch it; a flag in the shared container could remain after uninstall. Is continued use of canOpenURL appropriate here?

I’m experiencing a UI flickering issue in a SwiftUI application related to navigation and the .searchable modifier. I have the following navigation flow: Case 1: Event Dashboard ↓ Attendee List ↓ Back to Event Dashboard The Event Dashboard contains an event image at the top. The Attendee List has a navigation bar with a .searchable search field. When I navigate back from the Attendee List to the Event Dashboard, the event image briefly becomes smaller and then returns to its original size after approximately one second. Case 2: Event Dashboard ↓ Attendee List ↓ Attendee Detail The Attendee List contains .searchable, while the Attendee Detail screen does not. When navigating from the Attendee List to the Attendee Detail screen, the attendee profile image similarly becomes slightly smaller and then enlarges back to its original size. The behavior appears to be related to the navigation bar/search bar layout changing between screens. For example, the Attendee List currently uses: .searchable( text: $model.searchQuery, placement: .navigationBarDrawer, prompt: "Search" ) If I completely remove .searchable from the Attendee List, the flickering does not occur. I would like to understand whether this is expected SwiftUI behavior or a known issue with .searchable and navigation transitions. I am considering testing the Attendee List with ScrollView + LazyVStack instead of List to determine whether List is contributing to the issue.

Has anyone else observed an app entering the background when the user simply opens Notification Center on iOS 27? In our app, fully pulling down Notification Center triggers both UIScene.didEnterBackgroundNotification and UIApplication.didEnterBackgroundNotification. The user has not pressed the side button, gone to the Home Screen, or switched to another app. In the iOS 26 environments we checked, opening Notification Center only made the app inactive. User-visible impact and recording Our app currently treats background entry during an active medication reminder as leaving that reminder session: it closes the reminder screen and schedules a follow-up. As a result, merely checking Notification Center now triggers that existing behavior. Screen recording: https://drive.google.com/file/d/1KmXEKwg1vJpCWqe56IrC_iHaEC2aH_fc/view?usp=sharing The recording shows Notification Center being opened from the reminder screen, including a return to the app's main screen instead of the reminder screen. It also includes opening and dismissing Control Center, as well as going to the Home Screen and returning to the app. These are separate interactions, not one continuous Notification Center interaction. The video illustrates the visible impact; the lifecycle evidence below comes from separate logging. Environment and observations Physical device with the issue: iPhone 14 Pro, iOS 27.0 release build 24A435. We also observed it on an iOS 27 developer beta. Devices without the issue: iPhone 11 Pro running iOS 26.5.2 and iPhone 16 Pro running iOS 26.6. Opening Notification Center did not trigger background entry on either device. These comparisons involve different devices; we have not isolated the OS version as the only variable. App lifecycle: SwiftUI App + WindowGroup + @UIApplicationDelegateAdaptor. Multiple-scene support is disabled. The app uses AlarmKit for medication reminders. Verified build environments (simulator reproduction) Reproduction build Xcode iOS SDK Our app 26.4.1 (17E202) 26.4 Minimal standalone lifecycle apps 26.4.1 (17E202) 26.4 Minimal standalone lifecycle apps 27.0 RC (27A266a) 27.0 All three groups reproduced background entry when fully opening Notification Center on the iOS 27.0 simulator (24A434). The same SDK 26.4-built minimal apps remained inactive, without entering the background, on the iOS 26.4.1 simulator (23E254a). The behavior therefore also reproduces with apps built against the older SDK, not only with the iOS 27 SDK. Steps to reproduce in our app Open the app and leave it in the foreground. Swipe down from the top-left edge to fully open Notification Center. Do not tap a notification, lock the device, or switch apps. Observe the lifecycle notifications, then dismiss Notification Center to return to the app. On the affected iOS 27 device, the behavior differs between these actions: Action Observed behavior Fully open Notification Center App becomes inactive, then enters the background Open Control Center App becomes inactive, without background entry Enter the app switcher without selecting another app or going Home App becomes inactive, without background entry Go to the Home Screen App enters the background, as expected Lifecycle evidence This is a representative trace from earlier instrumented runs, separate from the screen recording above. Times are relative to the first event: +0.000s scene.willDeactivate +0.002s app.willResignActive +0.778s scene.didEnterBackground +0.780s app.didEnterBackground In subsequent instrumented runs on the iOS 27 release build, we also observed UIScene.activationState == .background after opening Notification Center. Our application's background handler is connected to the UIKit notification, rather than an onChange handler for SwiftUI's scenePhase: .onReceive( NotificationCenter.default.publisher( for: UIApplication.didEnterBackgroundNotification ) ) { _ in delegate.handleBackgroundEntry() } Separately, a diagnostic observer uses NotificationCenter.default.addObserver to record the UIKit application and scene notifications. The background events are therefore not inferred solely from our own session state or from the reminder screen disappearing. Questions Has anyone reproduced this on iOS 27? Reports of either reproduction or non-reproduction, including device model and OS build, would be helpful. Is background entry when fully opening Notification Center expected on iOS 27, or could this be a regression or an interaction with our app configuration? Is there a supported API or documented lifecycle distinction between opening Notification Center and actually leaving the app for the Home Screen or another app? Our standalone simulator comparisons reproduced the behavior with both SwiftUI and UIKit scene-based app lifecycles, including direct sceneDidEnterBackground callbacks. For context, this earlier Apple staff response describes Notification Center as making an app foreground-inactive. I also found this iOS 27 AVPlayer report about playback stopping after Notification Center is fully opened, but I do not know whether it has the same underlying cause. Any clarification from Apple or observations from other developers would be appreciated.

struct ContentView: View { @State var searchText: String = "" var body: some View { TabView { Tab { NavigationStack { List { Text("Hello!") Text("Hello!") Text("Hello!") Text("Hello!") Text("Hello!") Text("Hello!") } .navigationTitle("Have a title") .searchable(text: $searchText, placement: .toolbar) .searchToolbarBehavior(.minimize) .toolbar { DefaultToolbarItem(kind: .search, placement: .topBarTrailing) } } } } } } In iOS 26, this worked no problem. In iOS 27, this leaves the search bar either unable to collapse (when pressing the close button) or in a broken state where it cannot be opened again.

Hi! I was checking around for any reports related to an issue with UIScrollEdgeElementContainerInteraction and the scroll edge effect. I have a UICollectionView with a view pinned at the top, using the .hard style for the top UIScrollEdgeEffect. This was working fine in previous iOS betas (adding the effect to the whole view that was pinned), but in the latest beta and the RC1 the edge effect is no longer applied when I add a UIScrollEdgeElementContainerInteraction to the view. Has anyone else experienced this? I’m wondering if this is a regression in the interaction between UIScrollEdgeElementContainerInteraction and UIScrollEdgeEffect, or if there is a new requirement for how the interaction needs to be configured.

In iOS 26, the mini keyboard bar does not consistently appear when typing with a hardware keyboard. This behavior differs from iOS 18, where the bar was always visible. See screenshots:

On macOS 27.0 (26A428) with Xcode 27.0, Apple's unmodified sample Building a document-based app with SwiftUI stops responding permanently when another process replaces an open document's file through NSFileCoordinator. AppKit reverts the document on the main thread, which then blocks in a semaphore wait inside SwiftUI: -[NSDocument relinquishPresentedItemToWriter:]_block_invoke_8 (in AppKit) -[NSDocument _revertToVersion:preservingFirst:error:] (in AppKit) -[NSDocument revertToContentsOfURL:ofType:error:] (in AppKit) URLPlatformDocument.read(from:ofType:) (in SwiftUI) _dispatch_semaphore_wait_slow (in libdispatch.dylib) No other thread is reading the document. In another app using Document, its DocumentReader was never called, and a document with unsaved changes hung the same way in URLPlatformDocument.write(to:ofType:for:originalContentsURL:). Reproduction (the sample plus a short script): https://github.com/DePasqualeOrg/swiftui-document-revert-hang Feedback report: FB24792850

When I drag and drop a file with flag "shouldAttemptToOpenInPlace: true", I was able to access the original file name in macOS 15. After upgrading to macOS 26, I can't access the original file name anymore. Instead, I got some useless file name such as ".com.apple.Foundation.NSItemProvider.gKZ91u.tmp". The app no longer works with these tmp filenames because it needs the orignal file name to do the file transfer. (Btw, this is a WinSCP like app on Mac platform) Could you please check and fix this issue? Thank you. FileRepresentation(contentType: .item, shouldAttemptToOpenInPlace: true)

I am developing an iPhone-only app with TARGETED_DEVICE_FAMILY set to iPhone only. The app supports Portrait orientation only by specifying UIInterfaceOrientationPortrait in UISupportedInterfaceOrientations. When I build the app with Xcode 27 RC and run it on an iPadOS 27 Simulator, the layout becomes incorrect when the iPad is rotated to an orientation other than Portrait. While investigating this issue, I found that adding UISupportedInterfaceOrientations~ipad to Info.plist and specifying all four orientations resolves the problem: UIInterfaceOrientationPortrait UIInterfaceOrientationPortraitUpsideDown UIInterfaceOrientationLandscapeLeft UIInterfaceOrientationLandscapeRight With this configuration, the app displays correctly when the iPad is rotated. However, since this is an iPhone-only app and TARGETED_DEVICE_FAMILY does not include iPad, I am unsure whether using UISupportedInterfaceOrientations~ipad in this situation is an appropriate and supported solution. My questions are: Is it valid to specify UISupportedInterfaceOrientations~ipad for an iPhone-only app? Is this key expected to affect an iPhone-only app when it runs on an iPad? Is the behavior I am seeing on iPadOS 27 expected, or should an iPhone-only Portrait app handle this situation differently? Adding UISupportedInterfaceOrientations~ipad resolves the issue in my testing, but I would like to confirm whether this is an appropriate configuration to use in a production app. Thank you.

Environment App built with Xcode 26.3 (iOS 26 SDK) Deployment Target: iOS 16+ Issue occurs only on devices upgraded to iOS 27. Works perfectly on iOS 26.x. Problem description: After end‑user upgrades their iPhone to iOS 27, a persistent stale frosted‑glass / blur rendering effect appears at the top area of screens. This symptom occurs both on native UITableView and inside WKWebView. No blur‑related code (UIVisualEffectView / backdrop‑filter) is added by our application. Layout frames, insets and contentOffset are all correct. Reproduction hints: The issue can be triggered after presenting then dismissing a WKWebView which loads H5 with overlay popup. Rendering state seems to leak to the whole app process. The leftover blur remains until push/pop the view controller. Is this an iOS 27 system bug, or do we need special adaptation for existing apps built with older Xcode 26.3 SDK? What is the proper workaround for apps compiled with Xcode26.3, since liquidGlassEffectEnabled is only available in iOS27 SDK and cannot be accessed in our current build environment.

I have Mac apps that embed “Helper Apps” inside their main bundle. The helper apps do work on behalf of the main application. The helper app doesn’t show a dock icon, it does show minimal UI like an open panel in certain situations (part of NSService implementation). And it does make use of the NSApplication lifecycle and auto quits after it completes all work. Currently the helper app is inside the main app bundle at: /Contents/Applications/HelperApp.app Prior to Tahoe these were never displayed to user in LaunchPad but now the Spotlight based AppLauncher displays them. What’s the recommended way to get these out of the Spotlight App list on macOS Tahoe? Thanks in advance.

Is there a way to change the resolution in View Areas? It only has 800 x 480 but this is a small screen, there are much larger screens for CarPlay. What I'm missing? This is the CarPlay Simulator app from the Additional Tools for Xcode I'm aware of the Xcode Simulator where you can test different screen sizes but I wonder if CarPlay Simulator app supports that too Thank you

I’d like Swift Charts to support pinch-to-zoom, with the data beneath the pinch staying in place and smooth integration with scrolling and selection. This is useful whenever someone wants to explore a chart: zoom into a heart-rate spike, inspect a price change, or investigate a burst of energy consumption without losing their place. Apple Health uses preset time ranges to change the level of detail. Those are useful shortcuts, but they don’t always match the interval someone wants to explore. Pinching would complement them by letting users zoom directly into whatever catches their attention—a familiar interaction from maps and photos that feels natural for charts too. I’ve implemented a workaround using MagnifyGesture, chartXVisibleDomain, and chartScrollPosition. It mostly works, but keeping the pinch anchored requires continuously adjusting the scroll position, which causes chart jumps and visual glitches—even with animations disabled. Native support should handle that coordination, let developers configure zoom limits, and work alongside existing chart gestures. Developers could then offer smooth, interactive charts without each having to solve the same gesture and anchoring problems. I’ve attached a sample project demonstrating the workaround and its limitations. Would native pinch-to-zoom help your app too? I’d be interested in your use cases and any limitations you’ve encountered. I’ve filed this as FB24785962; if you submit related feedback, please reference it and describe your own use case. Sample Project

Hello, I found a difference in application lifecycle behavior between iPadOS 26.5 and iPadOS 27 beta when the app is running in the foreground and the iPad top button is pressed to put the device into sleep. Test condition Device: iPad App state: app is running in foreground (active) Action: press the top button once to put the device to sleep Observed via UIApplicationDelegate lifecycle callbacks Observed behavior iPadOS 26.5 The following callbacks are called in this order: applicationWillResignActive applicationDidEnterBackground iPadOS 27 beta The following callbacks are called in this order: applicationWillResignActive applicationDidBecomeActive applicationWillResignActive applicationDidEnterBackground Expected behavior I expected the lifecycle sequence on iPadOS 27 beta to be the same as, or at least consistent with, iPadOS 26.5 when the device is put to sleep from the foreground app state. In particular, I did not expect applicationDidBecomeActive to be called during the transition to sleep/background. Question Is this changed behavior expected in iPadOS 27 beta, or could this be a bug in the beta? If this is expected, could you clarify the intended lifecycle behavior when the top button is pressed and the device transitions to sleep? Thank you.

When I click on a table row, the focus cannot be changed from a TextField to the table. This is a bug in macOS 27 because the focus can be changed from a TextField to the table in macOS 26. Temp workaround: Click a different window, such as Finder or Safari Click the table in my app. The focus can be changed from a different app to the table in my app. Note: Table with focus: the table row is highlighted in blue. Table without focus: the table row is highlighted in grey.

While testing a native SwiftUI app on macOS 27.0 beta (26A5421a), built with Xcode 27.0 beta (27A5209h), we observed toolbar button groups briefly dimming when a custom sidebar animated open or closed. Filed as FB24782376. Our layout uses an HStack with a .bar sidebar background, animated sidebar width/offset, scrollable detail content, and a persistent root toolbar. The toolbar includes sidebar/add and play/edit/delete groups plus a separate terminal button. The change that removed the measured transition in this app was: .toolbar { // Existing toolbar items } .toolbarBackgroundVisibility(.hidden, for: .windowToolbar) This hides the automatic full-width toolbar backdrop. In our configuration, the standard native glass backgrounds around toolbar buttons remain. It changes the toolbar background design, so test it against your own content, appearance settings, and supported macOS versions. What we measured Read-only NSView/CALayer instrumentation showed a toolbar-wide hosting layer receiving a CATransition of type fade, lasting 0.25 seconds. Toolbar items stayed enabled, button instances stayed stable, and individual view/presentation-layer opacity remained 1. A keyboard-triggered comparison also kept the app/window active, key, and main throughout. Forcing the background visible, restricting the sidebar material’s safe-area extent, and isolating sidebar state below the toolbar-owning view did not remove the transition. Hiding the automatic toolbar background did. With standard SwiftUI buttons and the original layout restored, the hidden-background version recorded no toolbar animations on both opening and closing (91 samples per transition). These are app-side samples, not pixel-by-pixel proof or an independent minimal reproduction. This is a tested workaround for our configuration and a suspected system rendering interaction, not an Apple-confirmed diagnosis or a universal fix for toolbar flicker. We have not established behavior on other macOS versions. Related reports, not confirmed duplicates Toolbar jitter when toggling a sidebar (2022): intermittent movement of a share button during sidebar toggles, with another developer reporting similar behavior. Toolbar flashes above a translucent sidebar (2021): brief white flashes during periodic updates in full screen. Both predate this macOS 27 observation and have different triggers or appearances. They do not establish the same root cause. API reference: Apple’s toolbarBackgroundVisibility documentation. If you see a similar brief dimming on this configuration, comparing automatic versus hidden toolbar background visibility may help narrow it down. Please include your OS build, layout, and whether the comparison changes the symptom when filing feedback.

Feedback ID: FB23086400 On iOS 27 beta 1, .scrollEdgeEffectStyle(.soft, for: .top) on a List underneath a custom .safeAreaBar(edge: .top) no longer renders the progressive fade-blur. The top edge is fully transparent — scrolled rows pass under the bar with no visual treatment at all, as if scrollEdgeEffectDisabled() had been applied. What I've verified so far: .hard renders correctly in the exact same hierarchy; only .soft is affected. The same binary works correctly on iOS 26.x Xcode preview. I'm building with Xcode 26.3 (iOS 26 SDK). Minimal reproduction: import SwiftUI struct EdgeEffectRepro: View { enum Style: String, CaseIterable, Identifiable { case automatic, soft, hard var id: Self { self } var value: ScrollEdgeEffectStyle { switch self { case .automatic: .automatic case .soft: .soft case .hard: .hard } } } @State private var style: Style = .soft @State private var useSystemBarOnly = false var body: some View { NavigationStack { List(0..<60, id: \.self) { i in Text("Row \(i)") .frame(maxWidth: .infinity, alignment: .leading) .listRowBackground( i.isMultiple(of: 2) ? Color.orange.opacity(0.45) : Color.teal.opacity(0.45) ) } .scrollIndicators(.hidden) .scrollEdgeEffectStyle(style.value, for: .top) .safeAreaBar(edge: .top) { if !useSystemBarOnly { VStack(spacing: 8) { HStack { Text("Custom Top Bar") .font(.system(size: 28, weight: .bold)) Spacer() } HStack { Text("Second row (e.g. date range picker)") .font(.caption) .foregroundStyle(.secondary) Spacer() } } .padding(.horizontal) } } .safeAreaInset(edge: .bottom) { VStack(spacing: 8) { Picker("Edge effect style", selection: $style) { ForEach(Style.allCases) { Text($0.rawValue).tag($0) } } .pickerStyle(.segmented) Toggle("System bar only (control group)", isOn: $useSystemBarOnly) .font(.caption) } .padding() .background(.regularMaterial) } .navigationTitle("EdgeEffect Repro") .navigationBarTitleDisplayMode(.inline) } } } Steps: run on iOS 27 beta 1, set the picker to soft, scroll rows under the bar. Expected: fade-blur as on iOS 26. Actual: fully transparent. Switch to hard: renders fine.

Hi! I've encountered strange bug in iOS 26. The MultiDatePicker component exhibits unreliable behavior when attempting to deselect previously chosen dates. Users often need to tap a selected date multiple times (e.g., tap to deselect, tap to re-select, then tap again to deselect) for the UI to correctly register the deselection and update the displayed state. This issue does not occur on iOS 18 or Xcode 26 previews, where MultiDatePicker functions as expected, allowing single-tap deselection. The bug only occurs on physical device or simulator. I can't lie, I have multidatepicker as crucial component in my larger app and can't really find a solution to this. Has anyone encountered this problem before? Here is the code to replicate the issue: import SwiftUI struct ContentView: View {     @ State private var selectedDates: Set = []     var body: some View {         NavigationStack {             Form {                 Section {                     MultiDatePicker("Select Dates", selection: $selectedDates)                 } header: {                     Text("MultiDatePicker Bug Test")                 }                 Section {                     Text("Selected Dates Count: (selectedDates.count)")                     ForEach(Array(selectedDates).sorted(by: {                         Calendar.current.date(from: $0)! < Calendar.current.date(from: $1)!                     }), id: .self) { dateComponent in                         if let date = Calendar.current.date(from: dateComponent) {                             Text(date.formatted(date: .long, time: .omitted))                         }                     }                 } header: {                     Text("Current State of Selected Dates")                 }             }             .navigationTitle("Date Picker Bug")         }     } } #Preview {     ContentView() }

Hello, Is there any way to implement a "Reveal in Files App" feature in UIKit - the equivalent of AppKit's NSWorkspace.activateFileViewerSelecting(_:)? (Use case: users can open open files in my app that get added to a "Recents" list, and I'd like to make it so they can quickly jump to these files in Files app to see where they are located.) As far as I can see, there is nothing like this in UIKit, with UIApplication.open(url:...) being the closest, but that opens the given URL in the app associated with it. UIDocumentBrowserViewController has a reveal method, but that's for a browser view built in as the root view controller in your app, not for jumping to documents in Files app. A post from two years ago here suggests this isn't possible, but I have seen this feature in a couple of apps (iA Writer and Textastic), so perhaps there's something that has been added since that I've missed. Many thanks for any pointers or suggestions.

FB24767077 After programmatically setting the ID to B, manually paging back to A causes the binding to update to A and then unexpectedly back to B. The view hangs between pages while SwiftUI attempts to animate toward the stale B target. The issue occurs only when an app built with Xcode 27 runs on iOS 27. It does not occur in: Xcode 27 build running on iOS 26 Xcode 26 build running on iOS 27 Xcode 26 build running on iOS 26 Steps to reproduce: Launch the minimal reproduction project Tap “Set B” to assign B directly to the scrollPosition(id:) binding Swipe right to return to page A Expected result: After paging from B back to A, the scroll position remains A once the pager settles. Actual result: The binding emits A followed by B, even though page A is the visible, settled page. The resulting stale B value causes the animation to hang between pages. Code: struct ContentView: View { @State private var selectedPage: Page? = .a var body: some View { VStack { HStack { Button("Set B") { selectedPage = .b } Text("Selected: \(selectedPage?.rawValue ?? "nil")") } PagerView(selectedPage: $selectedPage) } .onChange(of: selectedPage, initial: false) { _, newValue in print("selectedPage: \(newValue?.rawValue ?? "nil")") } } } struct PagerView: View { @Binding var selectedPage: Page? var body: some View { ScrollView(.horizontal) { LazyHStack(spacing: .zero) { ForEach(Page.allCases) { page in Text(page.rawValue) .font(.largeTitle) .frame(maxWidth: .infinity, maxHeight: .infinity) .background(page.color) .containerRelativeFrame(.horizontal) } } .scrollTargetLayout() } .frame(height: 300) .scrollIndicators(.hidden) .scrollPosition(id: $selectedPage) .scrollTargetBehavior(.paging) .animation(.default, value: selectedPage) } } enum Page: String, CaseIterable, Identifiable { case a = "A" case b = "B" case c = "C" var id: Self { self } var color: Color { switch self { case .a: .red.opacity(0.2) case .b: .green.opacity(0.2) case .c: .blue.opacity(0.2) } } }