Since iOS 27, showing a system permission alert no longer deactivates the app. On iOS 26, sceneWillResignActive / applicationWillResignActive arrive about 0.05–0.1 s after ATTrackingManager.requestTrackingAuthorization. On iOS 27.0, 27.0.1 and 27.2 they don't arrive at all while the prompt is up, and SwiftUI's scenePhase stays .active. Apps that pause on resign, like games (Unity's iOS player pauses only on applicationWillResignActive), keep running behind the prompt: tutorials start, and timers and audio keep going. Minimal repro (plain UIKit with UIScene, fresh install so the status is .notDetermined): private var askedForTracking = false func sceneDidBecomeActive(_ scene: UIScene) { print("sceneDidBecomeActive") guard !askedForTracking else { return } askedForTracking = true DispatchQueue.main.asyncAfter(deadline: .now() + 3) { print("requesting ATT") ATTrackingManager.requestTrackingAuthorization { status in print("ATT finished: \(status.rawValue)") } } } func sceneWillResignActive(_ scene: UIScene) { print("sceneWillResignActive") }iOS 26.6: 3.27s requesting ATT 3.35s willResignActive 16.81s ATT finished: authorized 17.24s didBecomeActiveiOS 27.2: 3.21s requesting ATT 16.88s ATT finished: authorized 17.32s willResignActive 17.33s didBecomeActiveSo on iOS 27 the only lifecycle events are a resign/active pair about 0.44 s after the answer. What we found: The camera and notification permission alerts behave the same. It doesn't depend on the SDK the app is linked against, or on the thread making the request. SpringBoard's log shows the systemModalAlert deactivation assertion being added, but on iOS 27 the updateAllScenesForBand - Assertion added update never reaches the app's scene. The pending reason is only applied on the next unrelated scene update, such as a notification banner arriving, the screen dimming, an unlock, or the alert being dismissed. Taps outside the alert, a Control Center swipe or a home-indicator drag don't trigger it. Filed as FB25446786, with a sample project, delay sweeps on iOS 26 vs 27 (simulator and device) and a sysdiagnose. Is anyone else seeing this? And is there a supported way to know a permission alert is on screen until it's fixed? If you're affected, please file a Feedback and mention FB25446786; duplicates help.

Affected devices (all show the same problem): 1x iPhone 17 Pro Max 2x iPhone 18 Pro Max 1x iPhone 18 Pro Many demo iPhones at several Apple Stores Current iOS version: 27.2 Issue: Vertical scrolling inside apps frequently stutters and drops frames. It happens in many, many apps, including Apple's own App Store and Apple Store apps. During a normal flick-and-decelerate scroll, the content repeatedly freezes for one or more frames and then jumps forward. Because this reproduces on four of my own devices and on many Apple Store demo units, I believe it is a widespread, system-level issue, not a defect of a single device or my settings. Impact: I have been living with this for more than six months. I use my iPhone heavily every day, and the constant stutter has made using it genuinely distressing. Everything else about iPhone feels excellent, which makes this problem even harder to accept. Steps to reproduce: Open the App Store app (or almost any app with a scrolling list). Scroll with a normal flick and let it decelerate. Observe repeated hitches during the scroll. Measurements: I filmed the screen with a second iPhone at 4K 120 fps and measured content movement frame by frame: iPhone 18 Pro Max, third-party video feed: about 4 hitches per second of scrolling, about 4% of frames dropped, mostly single-frame drops. iPhone 18 Pro Max, third-party social app list: about 11 hitches per second, about 12% of frames dropped, at a regular rhythm every 6-8 frames. About a third of the stalls last 2-3 frames, and the content does not catch up afterwards. iPhone 17 Pro Max, third-party comment list: about 5 hitches per second, about 8% of frames dropped, including several full freezes of 50-75 ms. Expected: Smooth 120 Hz scrolling, as ProMotion is designed to deliver. Is Apple aware of this issue? I am happy to provide videos, frame-by-frame data, or sysdiagnose logs.

I'm creating a custom keyboard by subclassing UIInputView. This is set as a text field's inputView property. This is a simple keypad similar to the standard numeric keypad keyboard. In fact, my UI lets the user switch between the standard numeric keypad and my custom input view. Given this it would be very nice if my custom input view was the same height as the standard keypad. If there a proper way to subclass UIInputView such that its height is the same "standard" height as the numeric keypad when run on any iOS device from iOS 17 through 27.3? I do not want to have to hardcode dozens of heights for every model iPhone and iPad, not to mention the 5 different heights you get on the iPhone Duo. I've tried various combinations of setting allowsSelfSizing to true and false along with returning a height of UIView.noIntrinsicMetric in intrinsicContentSize as well as not setting intrinsicContentSize at all. The closest result is when allowsSelfSizing is set to false. In that case my custom input view's height is somewhat similar to the standard keypad but in some cases it's off by 20-30 points roughly. Has anyone implemented a custom UIInputView that gets the standard keyboard height without hardcoding device specific heights?

When using a background color for a UINavigation controller it seems the header does not extend to the top of the device for iPhone Duo when its closed in portrait mode. See screenshot. It should fill the entire 'status' bar up to top of device, Landscape correctly works, its just Portrait. Any thoughts on if this is 'expected' behavior? Seems odd to not just extend the navbar alll the way to the top.

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

Hi everyone: I'm experiencing an issue in iOS 26. I've implemented a custom ViewController. It's super simple to edit images with flip, crop, zoom in, and zoom out. My question is that it seems very strange to me. It works without problems in iOS 17.5 and iOS 18. However, when I try to run it with iOS 26, the entire ViewController seems disabled; it doesn't recognize touches or anything. When I checked the UI hierarchy, I saw a strange FloatingBarContainerView overlaying the entire ViewController. I searched the documentation for information about this view, but I couldn't find anything. Any help on how to hide or remove this view in iOS 26? This hasn't been implemented anywhere.

I’m investigating an issue with simultaneous Apple Pencil and finger input on iPad. Apple Pencil + finger input works correctly while the Pencil user’s hand/palm is off the display. However, when drawing naturally with Apple Pencil with the palm resting on the display, an existing finger drawing contact elsewhere on the screen can be cancelled and then stop receiving input for several seconds. Pencil input continues normally throughout. Initially I suspected PencilKit, but I’ve reproduced the underlying behaviour below PencilKit/SwiftUI. Instrumenting UIKit at UIApplication.sendEvent shows the finger touch being cancelled and, in some cases, no further events for that finger for ~4–5 seconds while Pencil MOVED events continue to arrive normally. Everything delivered to the application is accounted for, so this appears to occur before our drawing/rendering code. Is this expected behaviour from the iPad’s Pencil/palm rejection? More specifically: Is there any supported way to tell UIKit that an existing finger contact should remain intentional while Pencil + palm contact is present? Is palm rejection configurable at this level? Is there another public input API we should be using for this scenario? We’re currently testing UIEvent.coalescedTouches(for:) to determine whether additional genuine finger samples are available during these apparent gaps, but haven’t completed that test yet. Any guidance on whether this interaction is expected to be supportable through public UIKit APIs would be appreciated.

Has anyone else run into this issue? If you present a view controller and set its isModalInPresentation property to true, then when you try to drag down the view controller (which can't be dismissed), the view controller's content on the side of the vertical toolbar is shifted inward. This happens on a closed iPhone Duo. Even the title shifts if the vertical toolbar is on the left side. To replicate, create a Swift/UIKit project. Edit the main storyboard by deleting the default view controller scene and add a navigation controller (and its default root view controller). Set the class for the root view controller to ViewController. Then replace the default ViewController.swift code with the following: import UIKit class ViewController: UITableViewController { override func viewDidLoad() { super.viewDidLoad() let modal = UIBarButtonItem(systemItem: .add, primaryAction: .init(handler: { _ in let vc = ViewController() vc.title = "Some Modal" // If the following is true, dragging the modal view controller // down results in the table margins being shifted on whichever // side has a vertical toolbar. This happens on the iPhone Duo // when closed in either portrait or landscape. Whichever side // has the vertical toolbar gets shifted. // When the iPhone Duo is open the modal appears in a form sheet // and it does not demonstrate the issue. // The navigation title is also affected when the iPhone Duo is // closed and in landscape with the vertical toolbar on the left. // If the following is false, dismissing the modal by dragging it // down does NOT result in any change in the table's margins. vc.isModalInPresentation = true // false let nc = UINavigationController(rootViewController: vc) self.present(nc, animated: true) })) navigationItem.rightBarButtonItem = modal } } extension ViewController { override func numberOfSections(in tableView: UITableView) -> Int { 2 } override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int { 4 } override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell { // Some simple table cells to demonstrate the margin shift let cell = tableView.dequeueReusableCell(withIdentifier: "cell") ?? UITableViewCell(style: .value1, reuseIdentifier: "cell") cell.textLabel?.text = "Some Text" cell.detailTextLabel?.text = "Value" cell.accessoryType = .disclosureIndicator return cell } } Build and run the app with Xcode 27.1 and run it on an iPhone Duo (simulated or real). Tap the + icon to display the modal view controller (just another instance of ViewController). Now try to drag down the modal view controller. Notice the margin shift if the Duo is closed. There is no margin shift is the Duo is open or if isModalInPresentation is set to false. This has been reported as FB25221160.

There have been report several issues with this configuration in very old iOS versions. From iOS 27 it seems to be a problem again, or? Assume you have a tab bar controller that contains one ore move navigation controllers. These navigation controllers have one view controller that adds buttons to the navigaton controller's toolbar. Running the app on an iPad, everything works well. Running it on an iPhone, the toolbar is hidden below the tab bar. Is there any workaround to fix this? PS: A simple scene file is attached that shows the issue.

We're adding an option to our Unity SDK that gives a game a native launch screen: a launch storyboard (set through UILaunchStoryboardName) showing a full-screen image from an asset catalog. What we see On a clean install, the new launch screen shows as expected. When the same device installs an update over the existing app (tested through TestFlight), the previous launch screen keeps showing. Launching the app several times does not change it. Deleting the app, restarting the device and reinstalling shows the new launch screen straight away. We checked the build itself: the compiled storyboard, the image in Assets.car and the Info.plist keys are all correct, so this looks like the system's launch screen snapshot cache. We assume App Store updates behave the same way. What we're considering On the first launch after an update, the app would delete the cached launch screen snapshots in its own container (Library/SplashBoard), so the system regenerates them and the new launch screen shows on the next launch. This only uses public file APIs inside the app's own sandbox. But Library/SplashBoard is not documented anywhere, so we'd rather ask before shipping it. Questions Is deleting Library/SplashBoard from the app's own container a supported or acceptable practice, or could it cause problems (with the system, or in a future iOS version)? Is there a supported way to make iOS refresh a cached launch screen after an app update? If not, is the expected behaviour simply that the system refreshes the snapshot at some point? Is it documented when that happens (for example after a reboot, or after a certain time)? If clearing the folder isn't recommended, we won't ship it. Updating players would just keep the old launch screen until iOS refreshes it. Thanks!

On the unfolded iPhone Duo simulator, I can reach Settings through the toolbar overflow in landscape. After I rotate to portrait and open the floating sidebar, Settings disappears from both the toolbar and the available menus. I’ve seen this on iOS 27.1 and 27.2. I also reproduced it in a standalone UIKit app on iOS 27.2 and attached the Xcode project to Feedback Assistant report FB25402191. The standalone sample uses a two-column UISplitViewController with a UINavigationController in each column. The primary view controller assigns five actions to toolbarItems once in viewDidLoad, with Settings last. All five use the default visibility priority. The app makes no changes to its toolbar items during rotation. Steps to reproduce Fully unfold the simulated device and rotate to landscape with the detail pane’s vertical toolbar on the right. Widen the sidebar until all five buttons, including the Settings gear, appear in its bottom toolbar. Narrow the sidebar to about 280 points. Four buttons remain along the bottom. Open the ellipsis menu in the detail pane and tap Settings to confirm the action works. Keeping the device unfolded, rotate 90 degrees left into portrait. Tap the sidebar button to reveal the floating sidebar. I expected Settings to remain reachable through an overflow menu if the gear couldn’t fit. Instead, the floating sidebar shows four buttons, and neither pane offers an overflow menu containing Settings. The Settings item is still present in the primary view controller’s toolbarItems array. Rotating back to landscape makes it reachable again. Has anyone reproduced this on a physical iPhone Duo? Is there a supported way to keep an overflowed primary toolbar action accessible when the sidebar changes from a side-by-side column to a floating panel?

Two things I've seen using the iPhone Duo simulator. I'm updating a venerable Objective-C app that dates back to iOS 4, but has been updated to be perfectly functional and appearance-appropriate on iOS 26. I'm building using the 21.1 beta SDK in Xcode 27.1 beta. TL;DR version: (1) my toolbar items vanish in vertical mode except while being tapped or dragged; and (2) the nav bar has an opaque, fixed background even as its title scrolls with underlying content. Has anyone else seen these oddities, and any ideas as to how I can fix 'em? First, with the Duo opened and taller than wide, the nav and tab bars in my app appear horizontally, as I would expect them to. But in any other pose or orientation, the bars adopt a vertical display, and aside from the left edge, their items are invisible: When I tap or drag on them, they become visible: When I stop tapping or dragging, they vanish again. Why do the vertical items go invisible, and how can I keep 'em always visible? Second, my scrolling view lies under the nav bar (in z-order) but extends to the top of the screen. If I scroll the view, it moves up onscreen, behind the opaque nav bar, although the nav bar's title scrolls up, too: If I go "far enough", the title scrolls off completely and the view's contents are visible full-height, but with the nav bar's background remaining. If I don't scroll that far, the title reappears when I stop, and the area above the nav bar goes opaque white, too, covering the content: Is it possible to disable the scrolling behavior on the nav bar title? (I'll just position my scrolling view to start below it spatially.) Alternatively, how can I turn off the background opacity? I've tried setting the background to clearColor and opacity to false... nav.navigationBar.backgroundColor = [UIColor clearColor]; nav.navigationBar.opaque = false; ...but these had no effect. Help me Obi-Wan Kenobi, you're my only hope...

I am implementing support for iPhone Duo, and have seen this in many places: Apps built with the iOS 27.1 SDK or later are optimized for iPhone Duo. Apps will extend to use the full display, with toolbars and tab bars appearing vertically below the status bar. (from https://developer.apple.com/iphone-duo/prepare/) But when I build my application in Xcode 27.1, in both the simulator, and on the Duo hardware, my application is not extending to the full-width of the screen when built for iOS 27.1. There are black bars on both the left and right. When I debug the view hierarchy, I do not see the black bars, which indicates to me this is happening at the OS level, not as a result of my constraints. Note that there are no black bars in portrait mode, or on the front screen. In my project settings, only the iPhone Orientation "Portrait" is checked, but I don't want to check Landscape orientations there, because the application does not look good in landscape on a standard iPhone aspect ratio. Are those checkboxes required to remove the black bars? (Checking them does appear to do so, but again, this is quite problematic for the current design of the application.) Thanks in advance for any insights or help you can provide!

We are seeing a crash when attempting to display the Japanese Kana keyboard (日本語－かな) in our iPhone-only app running on an iPad with iPadOS 27.0.1. The keyboard displays successfully in our app on iPadOS 26 and iPadOS 27.0. We also reproduced a similar crash in other iPhone-only apps downloaded from the App Store on the affected iPad. We have not yet confirmed whether those apps crash with the same exception. Our app logs the following exception: *** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[__NSArrayM insertObject:atIndex:]: index 15 beyond bounds [0 .. 2]' *** First throw call stack: ( 0x19fab7190 0x19f834380 0x19fa45734 0x1aee9f5bc 0x1aee3dc14 0x1aee3cb30 0x1aee3c4d4 0x1aee3ab0c 0x1a433798c 0x1a44a4120 0x1a449bd5c 0x1a42148c8 0x1a42143fc 0x1a4239d7c 0x1a421203c 0x1a3fc1338 0x1a3d12e0c 0x1a3d11ed0 0x1a52784ec 0x1a3d11abc 0x1a4115238 0x1a3d436d4 0x1a3d43a80 0x1a44eea14 0x1aabb8ef8 0x1a517161c 0x1a5152450 0x1a5153388 0x1a41f20c4 0x1a49e3fec 0x1a426598c 0x1a42657fc 0x1a4265580 0x1a3d62b30 0x1a3d62984 0x1a95c4dac 0x1a994fb68 0x1a95c5514 0x1a95c287c 0x1a95d2608 0x1a3d6841c 0x1a3d6a298 0x1a4263874 0x1a3d60bdc 0x1a3ce8d78 0x1a3ce7b88 0x1a3ce7928 0x2d1482bc0 0x19fa78c20 0x19fa78b94 0x19fa5a268 0x19fa59384 0x19fa5a7f4 0x249e6ff24 0x1a3d381cc 0x1a9d27404 0x1a9d20b50 0x1a9d20a10 0x109042dc4 0x109042e04 0x19f8ab5b8 ) libc++abi: terminating due to uncaught exception of type NSException Steps to reproduce: Enable the Japanese – Kana keyboard in the iPad’s keyboard settings. Open an affected iPhone-only app on an iPad running iPadOS 27.0.1. Tap a text input field and attempt to display the Japanese Kana keyboard. The app crashes. We suspect this may be a regression involving iPhone compatibility mode on iPad and the Japanese Kana keyboard, but we have not yet identified the failing component in a symbolicated stack trace. We have submitted a report through Feedback Assistant: FB24985530. Has anyone else encountered this behavior? Are there any known workarounds we can apply in the app while this is being investigated?

On a physical iPhone Duo running iOS 27.1 and later, the system dictation button is placed inside the system keyboard, next to the space bar. Because the button belongs to the system keyboard layout, it isn't available while a third-party keyboard is active. On other iPhone models, the dictation button appears separately from the keyboard, so it stays available with third-party keyboards. On iPhone Duo, our users have no way to start dictation without switching back to the system keyboard. The iPhone Duo Simulator shows the button at the far right, which doesn't match the physical device, so this can't be evaluated accurately in the Simulator. As far as I can tell, there is no public API that lets a keyboard extension start system dictation, so we can't work around this from the extension. My questions: Is this placement intended on iPhone Duo? Is there a supported way for a keyboard extension to offer dictation on this device? If not, are there plans for a separate system dictation button, as on other iPhone models, or a public API for keyboard extensions? I've filed this as FB[number]. If you develop a keyboard extension and see the same issue, please file your own report and reference this number.

Under macOS 27 using Mac Catalyst for a UIKit-based app, If you present a view controller with a table view as a form sheet or page sheet, row reordering fails to function. You can drag a row as expected but the blue movement bar never appears and if you drop the row it simply returns to its original location. The exact same view controller presented as a popover works just fine. The exact same view controller not presented as a modal (such as the app's root controller) works just fine. This is a serious bug affecting existing applications and being reported by paying customers. This has been reported as FB25038883 which includes a simple sample app demonstrating the issue.

Environment Xcode 27.1 iOS 27.1 iPhone Duo simulator UIKit app built with the iOS 27.1 SDK Issue On iPhone Duo, the background of a system-managed UINavigationBar does not extend completely to the top edge of the window. The navigation bar is configured using UINavigationBarAppearance with an opaque blue background. However, a horizontal white strip remains above the blue navigation bar. I also post a feedback: FB24859353 Questions Is this expected behavior on iPhone Duo? What is the recommended way to style this top region? Should apps add a custom background underlay outside the UINavigationBar bounds? Could this be an iOS 27.1 or iPhone Duo simulator issue? Minimal reproduction code: import UIKit final class DemoTabBarController: UITabBarController { override func viewDidLoad() { super.viewDidLoad() viewControllers = NavigationBarStyle.allCases.map { style in let content = DiagnosticsViewController(style: style) let navigationController = UINavigationController(rootViewController: content) navigationController.tabBarItem = UITabBarItem( title: style.title, image: UIImage(systemName: style.symbolName), selectedImage: nil ) style.apply(to: navigationController.navigationBar) return navigationController } } } enum NavigationBarStyle: CaseIterable { case systemDefault case appearance case legacy var title: String { switch self { case .systemDefault: return "Default" case .appearance: return "Appearance" case .legacy: return "Legacy" } } var symbolName: String { switch self { case .systemDefault: return "iphone" case .appearance: return "paintbrush" case .legacy: return "clock.arrow.circlepath" } } func apply(to navigationBar: UINavigationBar) { switch self { case .systemDefault: break case .appearance: let appearance = UINavigationBarAppearance() appearance.configureWithOpaqueBackground() appearance.backgroundColor = .demoBlue appearance.shadowColor = nil appearance.titleTextAttributes = [.foregroundColor: UIColor.white] navigationBar.tintColor = .white navigationBar.standardAppearance = appearance navigationBar.compactAppearance = appearance navigationBar.scrollEdgeAppearance = appearance case .legacy: navigationBar.tintColor = .white navigationBar.barTintColor = .demoBlue navigationBar.backgroundColor = .demoBlue navigationBar.setBackgroundImage(Self.solidImage(color: .demoBlue), for: .default) navigationBar.shadowImage = UIImage() navigationBar.isTranslucent = false navigationBar.titleTextAttributes = [.foregroundColor: UIColor.white] } } private static func solidImage(color: UIColor) -> UIImage { return UIGraphicsImageRenderer(size: CGSize(width: 1, height: 1)).image { context in color.setFill() context.fill(CGRect(x: 0, y: 0, width: 1, height: 1)) } } } private extension UIColor { static let demoBlue = UIColor(red: 0.0, green: 0.46, blue: 0.70, alpha: 1.0) }

Sometime pre-iOS 26 it was possible to use a SplitViewController so that on iPhone you saw the master as a side menu (e.g. hamburger), and the detail full screen. While on iPad you would see the master displayed in a sidebar that could be closed, with the detail fullscreen. This has changed, using a SplitViewController on iPhone now forces you into having 2 fullscreen screens, with a push/pop layout and a back button. In situations where you want the detail screen to open first, this results in users opening the app to find a back button already presented, despite having not navigated anywhere. They must "return" to a screen they never saw. I really despise this layout and find it to be quite a UX issue. But given the new iPhone Duo, using the SplitViewController is now one of the easiest ways to maintain the necessary responsiveness needed, forcing us to accept this behaviour on regular iPhones. Can we PLEASE get the old functionality back, where we can explicitly state on iPhone that the master will always be displayed as a menu?

My App saves files using the UIDocumentPickerViewController. This works from iOS 17 to 26. Usually, you have a file with a given name in your sandbox, which you can then export via the pickerVC. In the pickerVC you change the name. In iOS 27 the file name is greyed-out and you can't change it here. The file can be exported only with the pre-given name. Is this a new behaviour or bug in iOS 27?

As reported in FB25363417: A UIKit based app running on macOS 27.2 (or macOS 27.0.1) via Mac Catalyst no longer has functioning state restoration. Upon app restart, there is no NSUserActivity being provided to the scene in the UISceneDelegate method scene(_:willConnectTo:options:). This can be tested with Apple’s own sample app “Restoring your app’s state”. Just update the sample project with support for a Mac Catalyst build. Using Xcode 27.2 on a Mac with macOS 27.0 or 27.2, build and run the Mac Catalyst version of the app. The main screen appears with a list of products. Select any product so you see details of the product. Quit the app. Run the app again. Note that you are not returned to the previously selected product detail screen. Instead, you just see the main list of products. If you run the same app and perform the same steps on a Mac running macOS 26.x, then when the app is restarted, you correctly get returned to the previously selected product detail screen. The problem is being caused by no NSUserActivity being passed into the scene delegate on app startup. While running the app on a Mac with macOS 27.x, put a breakpoint on the initial guard statement in scene(_:willConnectTo:options:) and you will see there is no activity on app restart. This is impacting paid customers of my existing app since upgrading to macOS 27. They no longer get returned to the app’s previous state when restarting the app. It is expected that state restoration should work on macOS 27 just as well as it does under macOS 26 in an app built with Mac Catalyst.