Hey All! Curious if others are seeing this where UIAlertController style action sheets (and to some extent Alert type) in iPad OS 27.0 B1 seem to be very buggy. By that i mean if you have an action sheet that has 20 items or some, half of them are not visible until you scroll or move the mouse over them (in simulator), and when tapping on them its a hit or miss if it triggers the delegate, sometimes it triggers on the first tap (click) or sometimes it takes 2 to 3 taps (clicks) to the delegate to trigger and the actioinsheet to dismiss. On initial look it seems iOS 27.0 B1 is working just fine, seems iPad Specific. While the list of the items not showing is only for action sheets, the 'sometimes' takes 2 to 3 taps (clicks) to select and item happens in both type ActionSheet and Alert. Sometimes it takes 2 to 3 taps to tigger an alert button etc. Both the above described issues happen on both device and simulator. Ive attached a video and a sample Proj to FB22998239. Hoping one of the UIKit Engineers can take a look, thanks for everything!

Experiencing an issue with UIContextualAction title text respecting the user's Dynamic Type / preferred content size category when Liquid Glass is active. It's setup using a UITableView with trailing swipe actions via trailingSwipeActionsConfigurationForRowAt. Under Liquid Glass, the contextual action buttons render as floating glass pills, but the title text within them remains at a fixed size regardless of the Dynamic Type setting. Increasing the preferred content size category to accessibility sizes has no visible effect on the action label font size. Any suggestions to make this scalable for dynamic font

I attach an ad in front of the main video using AVPlayerInterstitialEvent, and PiP works across the interstitial→content transition. I’ve noticed that some apps, while in Picture in Picture, show additional UI that: displays the remaining time of the interstitial item, and lets the user skip the interstitial item and switch to the main video. As far as I know, the AVPictureInPictureController window is system-drawn and can’t be customized by the developer. So my questions are: Is there an official/supported path to present this kind of UI (a remaining-time indicator and a skip control for the interstitial item) over the PiP window? If so, what is the mechanism — is it a system control that gets forwarded to a delegate, framework-provided interstitial UI, or When the interstitial is skipped this way, does the framework return to the primary item automatically, or does the app drive it? I’d really appreciate any insight intodone. Thanks!

I have an app that displays different content on a connected display (following this guide). It's working fine on iOS 26 but no longer is working in iOS 27 (both dev betas) + the latest SDKs. I tried to find any update notes but I couldn't find anything so I'm not sure if I'm doing something wrong or if it's an actual bug. I was able to simplify it down to the simplest case here: import SwiftUI // App Delegate to setup the scene delegate @main class AppDelegate: UIResponder, UIApplicationDelegate { func application(_: UIApplication, didFinishLaunchingWithOptions _: [UIApplication.LaunchOptionsKey: Any]? = nil) -> Bool { print("Calling didFinishLaunchingWithOptions") return true } func application(_: UIApplication, configurationForConnecting connectingSceneSession: UISceneSession, options _: UIScene.ConnectionOptions) -> UISceneConfiguration { print("Calling configurationForConnecting") let sceneConfig = UISceneConfiguration(name: nil, sessionRole: connectingSceneSession.role) sceneConfig.delegateClass = WindowSceneDelegate.self return sceneConfig } } // Scene delegate that sets up the view class WindowSceneDelegate: UIResponder, UIWindowSceneDelegate { var window: UIWindow? func scene(_ scene: UIScene, willConnectTo _: UISceneSession, options _: UIScene.ConnectionOptions) { print("Calling scene(willConnectTo:) with role \(scene.session.role)") guard let windowScene = (scene as? UIWindowScene) else { return } let window = UIWindow(windowScene: windowScene) if scene.session.role == .windowExternalDisplayNonInteractive { window.rootViewController = UIHostingController(rootView: ExternalDisplay()) } else { window.rootViewController = UIHostingController(rootView: ContentView()) } self.window = window window.makeKeyAndVisible() } } struct ExternalDisplay: View { var body: some View { Text("Other World!") } } struct ContentView: View { var body: some View { Text("Hello, world!") } } I also have my Info showing "Enable Multiple Scenes" set to true. I can screen mirror this app to my Mac (same result with an Apple TV). On iOS 26, on my iPhone, I'd see "Hello World!" and on the connected display, I'd see "Other World!". On iOS 27, this is no longer the case. On my connected display, I just see "Hello World". I'm trying to figure out if I've missed something or if this is a dev beta bug.

Hey, I am implementing a "Select All" functionality and experiencing a crash because of running out of memory when having a lot of cells. Calling .selectItem(at:animated:scrollPosition:) on 10k cells need 1.5GB and 20k needs 7GB (crashes on a real device). After selection is completed, memory goes down to normal levels. This broken both on iOS 18.5 and 26.5. Minimal example: https://github.com/martonfarago/collectionViewMemoryTest Is this a know issue? Is there another, maybe more efficient way of selecting all cells? M

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?

I have not yet completed the migration to scene delegate. If I still build with Xcode 26, will my app continue to launch on iOS 27 even if I release updates (still built with Xcode 26) after the iOS 27 release?

Description: I am encountering critical issues with PHPickerViewController using the "Zero-Permission" configuration. The behavior differs significantly between iOS 17 and iOS 26.4, but both prevent successful image selection. Observed Behaviors: On iOS 26.4 (iPhone 17 Pro Max): The PHPicker UI fails to render the photo grid entirely. Upon initialization, the system UI displays an "Unable to load photo" alert, preventing users from even viewing or selecting images. On iOS 17: The picker UI loads, but after the user selects an image and adds it, the subsequent itemProvider.loadObject call consistently fails, returning an error and preventing our app from retrieving the image data. Current Implementation: var config = PHPickerConfiguration() config.filter = .images config.selectionLimit = pickLimit // Problematic logic: if ABTestManager.shared.isPHPickerCurrent { config.preferredAssetRepresentationMode = .current } let pickerVC = PHPickerViewController(configuration: config) pickerVC.delegate = self user device Images: What I have tested: I have been using preferredAssetRepresentationMode = .current in my AB tests. I have not yet tested .compatible mode, as my application logic requires access to high-fidelity assets. However, the current behavior suggests a regression or a fundamental incompatibility with how the system handles image containers for high-end hardware (e.g., iPhone 17 Pro Max) in the out-of-process picker. Supporting Documentation: Minimal Reproducible Project: [Attached] Logs: [Attached sysdiagnose logs] My Questions: Is the "Unable to load photo" UI failure on iOS 26.4 a known limitation for certain high-resolution asset types when using .current mode? Are there specific handling requirements for NSItemProvider when the system fails to resolve the image data in .current mode on older iOS 17 devices? Given that these failures occur in a "Zero-Permission" context, are there specific metadata or image processing constraints I should be aware of to prevent the picker from entering a "failed" state?

I have a UITabBarController with multiple tabs. From the second tab's UINavigationController, I push a detail view controller (DetailVC). Architecture and execution flow: DetailVC is responsible for its own navigation lifecycle. When a button is clicked in DetailVC, it calls navigationController?.popToRootViewController(animated: true) to pop back to the root view controller of the second tab (let's call it RootVC). In RootVC's viewWillAppear, it checks the state and executes tabBarController.selectedIndex = 0 to switch to the first tab. Here is a simplified simulation: In DetailVC: @IBAction func switchButtonClicked(_ sender: UIButton) { // Step 1: Pop to root of second tab's navigation stack navigationController?.popToRootViewController(animated: true) // Step 2: The RootVC will handle this in viewWillAppear DispatchQueue.main.async { guard let windowScene = UIApplication.shared.connectedScenes.first(where: { $0.activationState == .foregroundActive }) as? UIWindowScene, let window = windowScene.windows.first(where: { $0.isKeyWindow }), let tabBarController = window.rootViewController as? UITabBarController else { return } // This simulates RootVC's viewWillAppear logic // In production, RootVC would set this when it appears tabBarController.selectedIndex = 0 } } Execution order: DetailVC → popToRootViewController(animated: true) → Navigation stack pops to RootVC → RootVC.viewWillAppear is called → Inside viewWillAppear, tabBarController.selectedIndex = 0 is executed → Switch to first tab The problem: On iOS 18 below, this works perfectly — the transition to the first tab is seamless. On iOS 18 and above, the selected index does switch to 0 correctly, but the tab bar rendering is noticeably delayed — it takes approximately one second to appear after the root view of the first tab has already loaded. My questions: Has Apple changed the timing of when viewWillAppear and selectedIndex changes are committed to the render pipeline in iOS 18? Specifically, does viewWillAppear now allow the view to lay out and render before the selectedIndex change takes effect? Given this architectural pattern (popToRootViewController → RootVC.viewWillAppear → selectedIndex change), what is the recommended approach to ensure the tab switch happens before RootVC's view is rendered? Given the complexity of our existing codebase and the number of features tied to this navigation flow, I'd strongly prefer to preserve this architectural pattern rather than refactoring the entire communication mechanism between DetailVC and RootVC. I'm looking for a robust, iOS 18-compatible solution that preserves the existing separation of concerns (DetailVC manages navigation, RootVC manages tab state via viewWillAppear) while eliminating the visible flash of the second tab's root view controller. Thank you for your insights!

UIKit application. I have a UISegmentedControl which displays flags, using the emoji for the text of the segment (SegmentedControl defined in stroryboard). Depending app is in Portrait or Landscape, the segmented control is displayed vertically or horizontally. When horizontal, nothing to do, direct display from stroryboard, works as expected. When vertical (Portrait), I have to rotate the UISegmentedControl π/2. And To get the flags properly oriented, I rotate each image -π/2. That works fine when compiling with Xcode 16.4. But when compiling with Xcode 26.3, rotation of segments do not work. Here is the illustration, compile on target simulators 26.2 in both cases (3rd image explained below):                             Xcode 16.4           -               Xcode 26.3 subviews rotated   -     removed subviews rotation Now the code. I subclassed UISegmentedControl to draw at will. class SegmentedControlRotable: UISegmentedControl { @IBInspectable var vertical : Bool = false // IBInspectable is now ignored override func draw(_ rect: CGRect) { if vertical { self.transform = CGAffineTransform(rotationAngle: CGFloat.pi / 2.0) for subview in self.subviews { subview.transform = CGAffineTransform(rotationAngle: -CGFloat.pi / 2.0) // reverse rotate // 3rd picture: this line commented out. } } else { // does no change self.transform = CGAffineTransform(rotationAngle: 0.0) for subview in self.subviews { subview.transform = CGAffineTransform(rotationAngle: 0.0) } } } // More code with touchesEnded, works OK in both cases } In fact, with Xcode 26, segments are always drawn on an horizontal line. l I noticed that the structure of self.subviews is different. 19 subviews in Xcode 16, 12 in Xcode 26. I removed the rotation of subviews, and it's OK. Just flags are now vertical (as illustrated above). What do I miss ? How to rotate the subviews in Xcode 26 ?

In iOS 27, willTransition(to:with:), registerForTraitChanges(), and other mechanisms to monitor size classes do not change when an iPhone interface is resized. Only viewWillTransition(to:with:) is invoked with a new size. And this only happens on the iPhone: the iPad continues to work as it has in the past. It appears that this is intended behavior. That is not to say that it's intuitive behavior. Many experienced developers are encountering the "horizontal size is always compact" behavior and immediately thinking "this must be a beta bug": https://fatbobman.com/en/posts/from-size-class-to-available-space/ But it's not. I get that the new size class behavior is expressing static device semantics and is no longer a dynamic size indicator. The problem is that the tools we have been using to build layouts for the past decade use size classes as dynamic sizing indicators. Storyboards can contain variations that specify whether a constraint is used for regular or compact widths/ heights. Developers have used this ability to automatically adjust layouts as the size classes change. In one case, I use this capability to adjust a top-over-bottom layout in a portrait configuration to a side-by-side in a landscape configuration: switching centering, leading/trailing, and aspect ratios to fit the available size. I suspect that many developers who have taken the time to create a unique layout for an iPad are doing something similar. (Ironically, the folks who treated an iPad as a big iPhone are the ones least affected by this change.) When iPadOS got the ability to resize interfaces (as UIScene windows), I made sure that the automatic size class contraints worked correctly and made adjustments as necessary. That work now has to be discarded and switched over to something more universal. If this is truly the intended behavior going forward, time needs to be invested in updating the tooling behind automatic constraint variations: There should be warnings when the storyboard is compiled. I have dozens of automatic contraints embedded in the storyboard: and they're hard to find (each subview has its own contraints, so it's a manual traversal of a huge tree). There should be runtime warnings that your code that inspects size classes won't be executed. This was the biggest "what the hell is going on?" when trying to resize the interface the first time. At a higher level, Apple engineers have described what is happening. They have not explained why the iPhone is behaving differently than an iPad. And that's the root of this whole situation being unintuitive. We've got no clue. And developers without a clue are unlikely to adopt a new technology. It's essential that Apple explains this change in more detail. Yes, you're going to have to obfuscate it and make us read between the lines, but it's got to be done. (Everyone understands the changes regarding mainScreen wink wink, for example.) A reply in this thread would be a good place to start this explanation.

I'm building an app with a UISplitViewController as the base, with the main content being a UITabBarController. I'm targeting iOS 26+ and using UIKit. I've customised the tabbar on iOS to have a different font family and size, and used some custom images. Running the same app on iPad, the tabbar moves to the top of the screen, ignores ALL the appearance proxy settings and strips out the images. Its now just giant floating text. Also noticed in portrait mode when the side bar from the split view is open, it compresses the width of the tab bar down to only show 2 elements at a time, with this weird custom scroll thing to move to the rest of the tabs. If the text wasn't so massive, maybe it could fit more. I really hate every inch of this thing. Its looks ugly and functions bizarrely. Why does it ignore all the tabbar appearance settings, and how can I customise it to add icons back with smaller text? Ideally I don't want to use one of the hacks to force it to think its compact mode to bring back the old tabbar, as i'm relying on traits already to fix some SplitView annoyances and don't want those to break. But would love to have the old tab bar style. Are there any settings or toggles that I can use?

I work on a universal app that targets both iPhone and iPad. Our iPad app currently requires full screen. When testing on the latest iPadOS 26 beta, we see the following warning printed to the console: Update the Info.plist: 1) `UIRequiresFullScreen` will soon be ignored. 2) Support for all orientations will soon be required. It will take a fair amount of effort to update our app to properly support presentation in a resizable window. We wanted to gauge how urgent this change is. Our testing has shown that iPadOS 26 supports our app in a non-resizable window. Can someone from Apple provide any guidance as to how soon “soon” is? Will UIRequiresFullScreen be ignored in iPadOS 26? Will support for all orientations be required in iPadOS 26?

For a UIKit app based on scenes (UIScene), is it safe to reference UserDefaults in code that is executed from UIApplicationDelegate/application(_: didFinishLaunchingWithOptions:) ? I've read that in iOS 15, there were undocumented scenarios involving app prewarming that would cause UserDefaults reads to fail within a window of time after device reboots, as described at https://christianselig.com/2024/10/beware-userdefaults/ The failure mode is that an app would be released, and months later, a small fraction of users would report failures consistent with UserDefaults reads unexpectedly returning nil, causing a loss of data. The user experience is bad, and debugging this behavior is then challenging because of how rarely it occurs. Apple's https://developer.apple.com/documentation/uikit/app_and_environment/responding_to_the_launch_of_your_app/about_the_app_launch_sequence#3894431 seems to suggest that prewarming only executes an app "up until, but not including when main() calls UIApplicationMain(_:_:_:_:), but https://stackoverflow.com/questions/71025205/ios-15-prewarming-causing-appwilllaunch-method-when-prewarm-is-done documents that UIApplicationDelegate/application(_: didFinishLaunchingWithOptions:) has in fact been observed executing during app prewarming in scene-based apps. So, my question: In an app based on scenes, if I'd like to reference UserDefaults within UIApplicationDelegate/application(_: didFinishLaunchingWithOptions:), when is it safe to do this? I'm guessing the answer is one of these: Never. Only in apps that don't support scenes. Only in iOS 16 or later. Only in IOS 17 or later. Is it guaranteed safe to reference UserDefaults in UIWindowSceneDelegate/scene(_:willConnectTo:options:) or later? Is there documentation from Apple regarding this issue? Thank you.

I have an iPad app which is trying to support document renaming in the title bar. For IOS 17+ I set the renameDelegate to the document instance and it works fine. For IOS 16 I need to create an actual delegate, but no matter how I structure the code it fails with a permission error: Rename failed: “original_file_name” couldn’t be moved because you don’t have permission to access “Desktop”. It seems to always happen accessing the parent directory. I have tried using the file coordinator as well with the same result. It seems impossible to implement unless the callback contains a security permissioned url for the parent directory. Is there anyway to make this work in IOS 16 in the sandbox? Do I have to create my own rename functionality using a FilePicker? Seems like this should be built in like it is in MacOS, or even IOS17+ Here is the code: extension DocumentWindow : UINavigationItemRenameDelegate { func navigationItem(_ navigationItem: UINavigationItem, didEndRenamingWith title: String) { guard let doc = document else { return } let oldURL = doc.fileURL let newURL = oldURL.deletingLastPathComponent() .appendingPathComponent(title) .appendingPathExtension(oldURL.pathExtension) if newURL == oldURL { return } let access = oldURL.startAccessingSecurityScopedResource() defer { if access { oldURL.stopAccessingSecurityScopedResource() }} do { try FileManager.default.moveItem(at: oldURL, to: newURL) } catch { print("Rename failed: \(error.localizedDescription)") } // // // 1. Jump to a background queue to avoid the deadlock // DispatchQueue.global(qos: .userInitiated).async { // let coordinator = NSFileCoordinator(filePresenter: doc) // var error: NSError? // // // coordinator.coordinate(writingItemAt: oldURL, error: &error) { outOld in // do { // // 2. Perform the actual rename // try FileManager.default.moveItem(at: outOLD, to: newURL) // } catch { // print("Rename failed: \(error.localizedDescription)") // } // } // // if let error = error { // print("Coordination error: \(error.localizedDescription)") // } // } } // 2. Optional: Validation (e.g., prevent empty names) func navigationItem(_ navigationItem: UINavigationItem, shouldEndRenamingWith title: String) -> Bool { return !title.trimmingCharacters(in: .whitespacesAndNewlines).isEmpty } }

Anyone else seeing this? I reported the regression back in March 2025 and have no reply from Apple. My apps are Obj-C, in case it matters. DESCRIPTION After updating to iOS 18.3.x, | noticed a regression in the title menu behavior of my UlDocumentViewController-based shipping apps on the App Store [1]: Instead of displaying the document icon supplied by the app, the share menu item displays a placeholder icon instead, and iconservicesagent error messages are emitted in the log stream [2]. STEPS TO REPRODUCE Install one of the apps from note [1] below. Launch the app, tap the document/title menu at top center of the screen, and observe first menu item. RESULTS Expected: App-provided document icon displayed to left of first menu item ("W-1" or "W68" document icon). Actual: Placeholder icon displayed. REGRESSION Occurs: iOS 18.3 (iPad) iOS 18.3.1 (iPhone) iOS 18.3.2 (iPhone) Does Not Occur: iOS 18.2,18.3 Simulator iOS 18.0-18.2? [| no longer have a device with < 18.3 to confirm regression point] NOTES: [1] WOZNIAC-1 <https://apps.apple.com/us/ app/wozniac-1/id6474085354> and WOZNIAC-68 <https://apps.apple.com/us/app/ wozniac-68/id6736677781>. [2] When the problem occurs, the following log messages are omitted: Error returned from iconservicesagent image request: <|STagIcon: 0x30299c040> Tag: alvm, Class: public.filename-extension, Base type: public.item - <|SImageDescriptor: Ox300dd5860> - (37.00, 48.00)@3x v:40000 1:5 a: 0:0:0:0 t:() b:0 s:2 ps:0 digest: 0D3223D0-9AЕ3-3B19-A081-ACACE55691B7 error: Error Domain=NSOSStatusErrorDomain Code=-609 "Client is disallowed from making such an icon request" UserInfo={NSLocalizedDescription=Client is disallowed from making such an icon request}

Issue Description: On iOS 26 and later, a CoreGraphics crash occurs when rendering images using -[UIImage drawInRect:blendMode:alpha:]. Based on the call stack, the crash happens inside CoreGraphics. Under what circumstances does the function upscale_provider_get_bytes_at_position_inner in the stack get called? When attempting to reproduce locally, this code path is never reached even when scaling images. Steps to Reproduce: There are a large number of crash reports in production, but the issue cannot be reproduced locally/offline. Expected Results: Explain under what conditions calling -[UIImage drawInRect:blendMode:alpha:] will reach the upscale_provider_get_bytes_at_position_inner logic. Ideally, provide a code example or demo. Provide the root cause of the crash and a workaround/mitigation. Current Behavior: Calling -[UIImage drawInRect:blendMode:alpha:] causes intermittent crashes in production. Xcode Version Used: Xcode Version 26.0 (17A324)

UIKit app can not edit an event using EKEventEditViewController in iOS 27 Betas. The Done tick button at the top does not work after editing an event. Also does not work if EKEventViewController is first used to display the event. Then the "Edit" tapped to display the EKEventEditViewController. Anyone else seeing this?

All system colors are displayed incorrectly on the popover view. Those are the same views present as a popover in light and dark mode. And those are the same views present as modal. And there is also a problem that when the popover is presented, switching to dark/light mode will not change the appearance. That affected all system apps. The following screenshot is already in dark mode. All those problem are occured on iOS 26 beta 3.

Hi there, not sure anyone encountered the same situation, we rolled out our feature and we found that flag is all false for all the users in Brazil.. super weird.. anyone has any idea?