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?

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.

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.

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.

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.

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.

I am taking the advice in https://developer.apple.com/videos/play/tech-talks/111462/ And using (in Obj C) navigationItem.additionalOverflowItems = UIDeferredMenuElement({ provider in provider(self.persistentOverflowItems()) }) This is quite fine as I already had menus on my barButtons. But the overflow menu doesn't match my color palette. It is white, and nothing else onscreen is. White = 100% on and draws the eye, whereas overflow should be the least important item on the screen. Thus, I should be able to color it. But with Glass, we can't set the bar tint and have it do anything useful. I can set the tint color of a .backItem. But I do not see a .overflowItem to set the TintColor of. I will be tempted to not use the system Overflow (as suggested in the video and there's usually an unspoken reason for so I'd like to use the system one, just not in white), and instead favor my own More button. Am I missing something or do I need to write a feedback?

Our app crashes when compiled with the iOS 27 beta 3 SDK and run as an iOS app on Mac, on both macOS 26 and macOS 27, as soon as a UISearchBar receives focus. The crash is due to this exception: *** Assertion failure in BOOL _screenBasedFocusUnsupported(void)(), UIScreen.m:3.725 Accessing the focus system through UIScreen is no longer supported. ( 0 CoreFoundation 0x000000018bea31c0 __exceptionPreprocess + 176 1 libobjc.A.dylib 0x000000018b91e91c objc_exception_throw + 88 2 Foundation 0x000000018e092644 -[NSMutableDictionary(NSMutableDictionary) initWithContentsOfFile:] + 0 3 UIKitCore 0x00000001c5dae8ec _screenBasedFocusUnsupported + 272 4 UIKitCore 0x00000001c5dae960 -[UIScreen _preferredFocusedWindow] + 24 5 UIKitCore 0x00000001c4ea3a60 -[UIScreen _mainSceneReferenceBounds] + 200 6 UIKitCore 0x00000001c4ea3914 -[UIScreen _mainSceneBoundsForInterfaceOrientation:] + 40 7 UIKitCore 0x00000001c5708134 +[UINavigationBar defaultSizeForOrientation:] + 76 8 UIKitCore 0x00000001c6222c88 -[_UISearchPresentationController _layoutPresentationWithSize:transitionCoordinator:] + 704 9 UIKitCore 0x00000001c622296c -[_UISearchPresentationController containerViewWillLayoutSubviews] + 84 10 UIKitCore 0x00000001c549304c block_destroy_helper.13 + 25112 11 UIKitCore 0x00000001c549344c block_destroy_helper.13 + 26136 12 UIKitCore 0x00000001c4ea26a8 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 1648 13 QuartzCore 0x0000000196103dbc _ZN2CA5Layer15perform_update_EPS0_P7CALayerjNS_17LayerUpdateReasonEPNS_11TransactionE + 460 14 QuartzCore 0x000000019610390c _ZN2CA5Layer17update_if_needed_EPNS_11TransactionENS_17LayerUpdateReasonE + 692 15 QuartzCore 0x0000000196035d2c _ZN2CA7Context18commit_transactionEPNS_11TransactionEdPd + 608 16 QuartzCore 0x0000000195e69520 _ZN2CA11Transaction6commitEv + 652 17 AppKit 0x0000000190fe116c __37+[NSDisplayCycle currentDisplayCycle]_block_invoke.7 + 44 18 CoreFoundation 0x000000018be34ad0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 28 19 CoreFoundation 0x000000018be34a10 __CFRunLoopDoBlocks + 396 20 CoreFoundation 0x000000018be33e54 __CFRunLoopRun + 2356 21 CoreFoundation 0x000000018bf06234 _CFRunLoopRunSpecificWithOptions + 532 22 HIToolbox 0x0000000198c1f560 RunCurrentEventLoopInMode + 320 23 HIToolbox 0x0000000198c228bc ReceiveNextEventCommon + 488 24 HIToolbox 0x0000000198dac14c _BlockUntilNextEventMatchingListInMode + 48 25 AppKit 0x00000001909163d0 _DPSBlockUntilNextEventMatchingListInMode + 228 26 AppKit 0x000000019026a084 _DPSNextEvent + 576 27 AppKit 0x0000000190dff96c -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688 28 AppKit 0x0000000190dff678 -[NSApplication(NSEventRouting) nextEventMatchingMask:untilDate:inMode:dequeue:] + 72 29 AppKit 0x000000019025d13c -[NSApplication run] + 368 30 AppKit 0x00000001902357b0 NSApplicationMain + 880 31 AppKit 0x000000019047c958 +[NSWindow _savedFrameFromString:] + 0 32 UIKitMacHelper 0x00000001aa2651bc UINSApplicationMain + 972 33 UIKitCore 0x00000001c4e1aed4 UIApplicationMain + 144 34 UIKitCore 0x00000001c548bda0 block_destroy_helper.31 + 8880 35 DigitalConcertHall.debug.dylib 0x0000000106e41bd8 $sSo21UIApplicationDelegateP5UIKitE4mainyyFZ + 128 36 DigitalConcertHall.debug.dylib 0x0000000106e41b4c $s18DigitalConcertHall11AppDelegateC5$mainyyFZ + 32 37 DigitalConcertHall.debug.dylib 0x0000000106e4afc0 __debug_main_executable_dylib_entry_point + 28 38 dyld 0x000000018b9ac4e4 start + 6992 ) I could not test with the iOS 27 beta 4 SDK due to this blocking issue: https://developer.apple.com/forums/thread/839012 However, when I tried to set up a simple sample project, I could not reproduce the issue. Does anybody know what might be causing this? I filed feedback FB24201508

Why is the UI orientation LandscapeRight instead of the expected Portrait? Video reproduction:

Hi, I would like to share an issue with UISearchBar's delegate method searchBarCancelButtonClicked on iOS 27 beta. On iOS 27 beta, when search bar is integrated into navigation bar’s items, tapping search cancel button doesn’t invoke UISearchBar’s delegate method searchBarCancelButtonClicked:. Steps to reproduce: Create UINavigationController with one UIViewController Set up searchController. Set searchController.searchBar.delegate, preferredSearchBarPlacement = .integratedButton, searchBarPlacementAllowsToolbarIntegration = false Tap the search button and type a query Tap the search cancel button Expected: On iOS 26, the searchBarCancelButtonClicked delegate method is called. Actual: On iOS 27 beta, the searchBarCancelButtonClicked delegate method is NOT called. On iOS 27 beta, if search bar is “stacked” or placed in the toolbar rather than the navigation bar, the bug does not reproduce. I’m using Xcode Version 27.0 beta 6 with latest available iOS 27 iPhone 17 Pro simulator (24A5423a). I reported the issue via Feedback Assistant with a minimal reproduction example and 2 videos comparing the behavior between iOS 26 and iOS 27 beta. Here is the report ID: FB24636315. Here is the minimal reproduction example: // SceneDelegate.swift import UIKit class SceneDelegate: UIResponder, UIWindowSceneDelegate { var window: UIWindow? func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) { guard let windowScene = scene as? UIWindowScene else { return } let window = UIWindow(windowScene: windowScene) window.rootViewController = UINavigationController(rootViewController: ViewController()) window.makeKeyAndVisible() self.window = window } } // ViewController.swift import UIKit final class ViewController: UITableViewController { private let allItems = (1...30).map { "Item \($0)" } private var items: [String] = [] private var cancelCount = 0 override func viewDidLoad() { super.viewDidLoad() items = allItems updateTitle() let searchController = UISearchController(searchResultsController: nil) searchController.searchBar.delegate = self navigationItem.searchController = searchController navigationItem.preferredSearchBarPlacement = .integratedButton navigationItem.searchBarPlacementAllowsToolbarIntegration = false tableView.register(UITableViewCell.self, forCellReuseIdentifier: "cell") } private func updateTitle() { title = "Cancel presses: \(cancelCount)" } override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int { items.count } override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell { let cell = tableView.dequeueReusableCell(withIdentifier: "cell", for: indexPath) cell.contentConfiguration = { var config = cell.defaultContentConfiguration() config.text = items[indexPath.row] return config }() return cell } } extension ViewController: UISearchBarDelegate { func searchBarCancelButtonClicked(_ searchBar: UISearchBar) { print("searchBarCancelButtonClicked(_:)") cancelCount += 1 updateTitle() items = allItems tableView.reloadData() } } Thank you in advance!

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

In all iOS 27 Beta 1-8 UIViewControllerAnimatedTransitioning is broken, it shows black screen when a new screen is opened. This Transitioning works correctly on previous iOS (<27) versions. Check out the attached file with example of source code. Example.txt This bug needs to be fixed ASAP, as it will affect a large number of users upon the public release of iOS 27. Visual demonstration: iOS 27 with broken transition iOS 26 works correctly

Hello, After building with the iOS 26 SDK, a table-view swipe action created with UIContextualAction is displayed as a circular Liquid Glass button instead of the rectangular action used on earlier iOS versions. This is how my code look UIContextualAction *action = [UIContextualAction contextualActionWithStyle:UIContextualActionStyleNormal title:@"" handler:^(UIContextualAction *action, UIView *sourceView, void (^completionHandler)(BOOL)) { completionHandler(YES); }]; action.backgroundColor = UIColor.systemPurpleColor; action.image = [UIImage imageNamed:@"my_action_image"]; UISwipeActionsConfiguration *configuration = [UISwipeActionsConfiguration configurationWithActions:@[action]]; configuration.performsFirstActionWithFullSwipe = NO; return configuration; Has anyone found a supported workaround that does not require a completely custom swipe implementation? This occurs only with the new iOS 26 appearance. The same implementation displays correctly on earlier iOS versions. Thank you.

I have an application that needs to make a USSD call, but on some devices the * and # don't work on the dialer, on others it does. if let phoneNumber = ussdNumberTextfield.text { let encoded = "telprompt:\(phoneNumber)".addingPercentEncoding(withAllowedCharacters: .urlQueryAllowed)! if let url = URL(string: encoded) { if application.canOpenURL(url){ DispatchQueue.main.async { self.application.open(url, options: [:]) { success in } } } } }

Summary On iOS 27 the top scroll edge effect of a UITableView is sized around the UIRefreshControl as an edge element, but appears to key on the control's presence in the scroll view rather than its current height. After endRefreshing(), the control collapses to zero height but stays attached, and the effect region keeps reserving a refresh-control's worth of space. The first row stays blurred and dimmed even though it is scrolled fully clear of the navigation bar. Environment iOS 27 (beta), iPhone Xcode 27.0.0 Beta 4 UIKit, UITableView inside a UINavigationController Reproduces with the default edge effect style and with an explicit .soft Steps to reproduce Push a UITableViewController with a UIRefreshControl onto a navigation stack. Ensure content extends under the navigation bar (default for UITableViewController). Pull to refresh and let the refresh end. Observe the first row after the refresh control has retracted. Expected Once the control retracts, the edge effect returns to its pre-pull height and the first row renders crisply. Actual The region stays roughly one refresh-control height too tall and the first row stays blurred. Row positions are unaffected — content offset and adjustedContentInset are correct. Only the extent of the effect is wrong. It corrects itself on the next push/pop. Two probes that isolate it These narrow the cause to the control's presence rather than a general staleness: Re-assigning tableView.topEdgeEffect.style after endRefreshing(), including on a later runloop turn, does NOT correct the region. The style is not what is stale. Detaching the control DOES correct it immediately: tableView.refreshControl = nil So the region is measured from the control being in the hierarchy, and is never re-measured when the control merely collapses. Secondary issue A UIRefreshControl that has been detached is inert if the same instance is re-assigned: tableView.refreshControl = nil tableView.refreshControl = sameInstance // never triggers again A freshly constructed UIRefreshControl must be assigned instead. This is not documented and looks like a second bug. Minimal sample Attached. A UITableViewController with a refresh control and a "Push" bar button that pushes and pops an empty view controller, so the incorrect region and the post-navigation correction can be compared in one run. Related FB20756572 reports the same "edge-effect extent is stale until the next navigation" behaviour for UIScrollEdgeElementContainerInteraction sizing, and notes a change in iOS 27 seed 1. That report received no reply.

Hi. I've noticed that on iOS 27 the UITabBarItem badge goes behind the tab image during tab selection. Here is a little screen recording of a simple Storyboard project with just a UITabBarController and two child UIViewControllers. On the left is iOS 26.5 and on the right is iOS 27.0 beta 6. While filled icons look more or less ok, the outline icons look the most concerning with this new behaviour. So, the question is whether this is a bug or a feature?

We are seeing an intermittent launch-time crash that increased sharply starting with iOS 18.4. The affected app version is 1.4.8, which uses the UISceneDelegate-based lifecycle. The primary UIWindow is created and managed for the UIWindowScene provided to the scene delegate. The OS-version distribution is very specific: iOS 18.3: no significant occurrence iOS 18.4 through the tested iOS 18.x releases: the crash occurs iOS 26: no occurrence observed This comparison uses the same application binary. Therefore, the issue appears to be specific to the iOS 18.4–18.x UIKit/FrontBoard implementation rather than a general behavior on all newer iOS versions. The crash occurs on the main thread: EXC_BREAKPOINT (SIGTRAP) 0 FrontBoardServices -[FBSScene _sendUpdate:].cold.1 + 244 1 FrontBoardServices -[FBSScene _sendUpdate:].cold.1 + 244 2 FrontBoardServices -[FBSScene _sendUpdate:] + 1156 3 FrontBoardServices -[FBSScene _updateClientSettings:] + 552 4 FrontBoardServices -[FBSScene updateClientSettingsWithBlock:] + 124 5 UIKitCore -[FBSScene(UIApp) updateUIClientSettingsWithBlock:] + 168 6 UIKitCore __39-[UIWindow _noteOverlayInsetsDidChange]_block_invoke + 248 7 UIKitCore -[_UIAfterCACommitBlock run] + 72 8 UIKitCore -[_UIAfterCACommitQueue flush] + 168 9 libdispatch.dylib _dispatch_call_block_and_release + 32 10 libdispatch.dylib _dispatch_client_callout + 16 11 libdispatch.dylib _dispatch_main_queue_drain.cold.5 + 812 12 libdispatch.dylib _dispatch_main_queue_drain + 180 13 libdispatch.dylib _dispatch_main_queue_callback_4CF + 44 14 CoreFoundation __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16 15 CoreFoundation __CFRunLoopRun + 1980 16 CoreFoundation CFRunLoopRunSpecific + 572 17 GraphicsServices GSEventRunModal + 168 18 UIKitCore -[UIApplication _run] + 816 19 UIKitCore UIApplicationMain + 336 Another observed variant contains: -[FBSScene _sendUpdate:].cold.1 + 244 Some reports continue through: _UIApplicationFlushCATransaction _UIUpdateSequenceRun while others continue through the main dispatch queue. These reports appear to belong to the same crash family because they share the following path: UIWindow _noteOverlayInsetsDidChange → FBSScene updateUIClientSettingsWithBlock: → FBSScene _updateClientSettings: → FBSScene _sendUpdate: → SIGTRAP The crash occurs during cold launch, immediately after the root tab bar controller begins its first appearance. In affected launches, the last application-side lifecycle marker we observe is: MSKMainTabBarViewController.viewWillAppear(_:) The process then terminates while UIKit is flushing the first appearance-related Core Animation transaction. No later application-side lifecycle marker is observed before termination. We are treating viewWillAppear(_:) only as the last observable application-side marker. We do not assume that it directly causes the crash, because the failing UIWindow client-settings update is deferred until after the Core Animation commit. There are no application frames in the crashing portion of the stack, and the app does not call any private API. The affected app version has already adopted the UISceneDelegate lifecycle, so this does not appear to be caused by the legacy UIApplicationDelegate-only compatibility lifecycle. We have also observed the same FBSScene update path during a normal, non-crashing launch. The fatal reports differ in that FrontBoardServices triggers SIGTRAP inside _sendUpdate: or its compiler-generated cold path. Because the client-settings update is deferred, the crash report does not identify which UIWindow operation, overlay-insets change, or FBSScene client setting originally produced the rejected update. Has anyone encountered this exact FBSScene / _noteOverlayInsetsDidChange crash specifically on iOS 18.4–18.x? In particular: Is this a known UIKit or FrontBoardServices regression introduced in iOS 18.4? Was this behavior changed or fixed in iOS 26? Which UIWindow or FBSScene client setting can cause this internal assertion? Is there a supported way to identify the UIWindow responsible for the rejected update? Are there known launch-time restrictions involving multiple UIWindows, key-window transitions, overlay insets, status-bar updates, or first-appearance transactions? Is there a recommended diagnostic profile, breakpoint, or logging option for capturing the original producer of the deferred update?