Thank you very much for your detailed response and valuable recommendations. At this stage, our application is still built using Xcode 26 and the iOS 26 SDK. Our primary priority right now is to validate runtime behavior for our existing binary running on iPhone Duo. We fully understand that full‑featured support for iPhone Duo requires Xcode 27 plus Scene lifecycle adoption, and we plan to implement those adaptations incrementally in future releases. What we want to clarify specifically: aside from the expected black bars introduced by system compatibility mode, do our existing patterns raise functional bugs or layout risks on iPhone Duo when built with Xcode 26? The legacy patterns we are concerned about are: Window creation via init(frame:), where frame is derived from UIScreen.main.bounds, without adopting SceneDelegate lifecycle. Manual non‑AutoLayout layouts that read UIScreen.main.bounds directly to obtain view width. Whether viewWillTransitionToSize:withTransitionCoordinator: will still fire on fold/unfold state changes under this Xcode‑26‑built compatibility mode. We would like to distinguish which of these usages must be fixed even for our Xcode‑26‑built release, versus which ones are safely handled by system compatibility and can remain unchanged for the time being. We are trying to decide whether urgent compatibility patches are required for our current Xcode 26 build. Thank you again for your support.

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.

iOS Version: iOS 27 Beta Xcode: Xcode27 Beta 2 I have a custom UITabBar subclass. The tab bar items are visible and selectable, and the selected state works, but the title color in the normal state is always rendered as white, even though I set a different normal title color. Simplified code let normalColor = UIColor.gray let selectedColor = UIColor.orange let bgColor = UIColor.black let font = UIFont.systemFont(ofSize: 10, weight: .semibold) let appearance = UITabBarAppearance() appearance.configureWithOpaqueBackground() appearance.backgroundEffect = nil appearance.backgroundColor = bgColor appearance.shadowColor = .clear let itemAppearance = appearance.stackedLayoutAppearance itemAppearance.normal.titleTextAttributes = [ .font: font, .foregroundColor: normalColor ] itemAppearance.selected.titleTextAttributes = [ .font: font, .foregroundColor: selectedColor ] itemAppearance.normal.iconColor = normalColor itemAppearance.selected.iconColor = selectedColor appearance.stackedLayoutAppearance = itemAppearance appearance.inlineLayoutAppearance = itemAppearance appearance.compactInlineLayoutAppearance = itemAppearance tabBar.standardAppearance = appearance if #available(iOS 15.0, *) { tabBar.scrollEdgeAppearance = appearance } tabBar.backgroundColor = bgColor tabBar.isTranslucent = false The problem: The selected title/icon color works. The normal title color is ignored and stays white. This happens after moving to the newer tab bar appearance behavior / Liquid Glass environment. Question: Is there any additional configuration required for UITabBarAppearance so that the normal UITabBarItem title color is respected? Could unselectedItemTintColor, tintColor, scrollEdgeAppearance, or Liquid Glass behavior override normal.titleTextAttributes?

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

Background We are currently building our app with Xcode 26 and the iOS 26 SDK. We want to verify the runtime behavior on iPhone Duo. We have three questions: We haven't adopted SceneDelegate lifecycle management yet. We create the window using init(frame:), with the frame value taken from UIScreen.main.bounds. Will this implementation cause any issues on iPhone Duo? For all non-Auto Layout layouts, we fetch view width by reading UIScreen.main.bounds. Do we need to rewrite all these code points? Will this lead to layout exceptions when the device switches between folded and unfolded states? We observed the system handles fold/unfold compatibility, but black bars appear in both states. Can our app keep consistent view dimensions in both modes? Will viewWillTransitionToSize:withTransitionCoordinator: fire to trigger re-layout when switching between folded and unfolded states?

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.

I’m seeing in issue on iOS 27 with TextKit 1 backed UITextViews where grammar checking makes part of the text disappear. For TextKit 2 views, there's a blue underline and a shimmer effect that's applied to the text when a grammatical error is detected. For TextKit 1 views the underline appears but instead of the shimmer effect, the text just disappears. Steps to reproduce: Create a UITextView using TextKit 1: UITextView(usingTextLayoutManager: false) Fill it with a very long document (makes the bug easier to reproduce). Type a phrase that triggers a grammar correction, such as “self aware”. Wait for the system to suggest “self-aware”. The blue underline appears but the two words disappear. I've found a partial workaround by overriding NSLayoutManager.drawGlyphsForGlyphRange and calling CGContextSetFillColorWithColor on the affected range, but this isn't great. Filed as FB24319258. Has anyone else encountered this on the iOS 27 betas? Would appreciate any guidance.

Hi, it seems there's an issue with back button on iOS 27 when it has a custom title defined and the title is forced to collapse in runtime due to other items taking space in the header. I have the following setup in the header of the second screen in a stack: a back button that displays custom title and 2 rightBarButtonItems. There is a toggle that adds the third item to rightBarButtonItems or removes it. This forces to hide the back title or display it again. I expect the button to resize as needed and go back to previous state as needed, without flashing, and correctly respond to presses at all times. What actually happens: I repeat the action multiple times (up to 5 times should be enough), the back button goes blank and unresponsive. There is only the glass background present, which does correctly resize. I filed the issue in Feedback Assistant: ID FB24801640 Is there a way to workaround this?

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.

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:

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.

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’m developing a keyboard extension and noticed this weird issue. When I switch from normal keyboard to custom keyboard there is a faint overlay duplicate of the custom keyboard that comes from the top which makes the switching not seamless and I can’t seem to find the cause of this issue. I initially thought it had to do with the fact that it’s communicating with my app to get the latest data and check for edits but it’s not the case here. when I screen record it doesn’t appear as faint overlay, it appears as the keyboard becoming taller than usual and then sizing down to expected height. iOS26.6.2

I’m having an annoying floating keyboard bug on my iPad Pro M4 using ipados27, it won’t let me move the keyboard all the way down or up the screen it’s like it’s stuck within a 16:9 letter box. It seems to sometimes work on the Home Screen and let me move it down all the way but if I go to the app screen or any app and use the keyboard it will spring it back up and won’t go back in the place I want it. I also noticed that there is no animation for the keyboard being dismissed as well. It simply will disappear within a split second. It’s very janky as even when I pull up the keyboard while in a windowed app that allows my home bar to show, the keyboard will cause the home bar to be hidden away even though the keyboard won’t even hover on the location of where the home bar is. It just hides it away, it seems that the region its allowed and where it’s detected within the system is being misinterpreted. The disappearing bug is newer it started on ipados27 but the restrictive keyboard has been an issue since like iPadOS 17 or 18. Another bug I’ve had for years is the virtual trackpad feature that’s inside the touch accommodations accessibility options. This feature is only on the iPad sadly, but I would find or think that it would be super useful especially when I have a secondary monitor attached to the iPad but it refuses to work at all when another monitor is connected. Not that it works without another monitor attached. It is completely unusable as it doesn’t scroll and gets stuck, the windowing management for the app I have open gets priory over my interactions on the trackpad leading to me resizing the window instead of the trackpad moving the mouse if I click on a corner too far. All in all it’s a completely useless feature and I have tried everything in the book to fix it myself and even report the issue but this has been broken since I got my first iPad. Please try the feature out and see what I mean, nothing works other than moving the old version of the mouse cursor, no scrolling, no right clicking, and of course no gestures including 3/4 finger app switching or pinching in or out to zoom or two finger slide.

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?

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 } } } } }