When upgrading an app from iOS 18 to iOS 26, some labels in a toolbar menu get wrapped unexpectedly. The issue can be reproduced through the sample below, which contains this label : "Envoyer une réaction" On iPhone with iOS 18, the label is displayed on 1 line. But on iPhone with iOS 26, the label is displayed on 2 lines. No improvement was obtained through these modifiers : .lineLimit, .frame and .fixedSize . . How to avoid this unnecessary label wrapping that disrupts the readability ? . . import SwiftUI struct SampleView: View { var body: some View { NavigationStack { Color.clear .toolbar { ToolbarItem { Menu { Button(action: {}) { Label("Envoyer une réaction", systemImage: "envelope") } } label: { Image(systemName: "ellipsis") } } } } } } #Preview { SampleView() }

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?

Transitions inside ScreenTime Report is not working if phone locked when app is opened. It is starts working only after terminate and open the app.

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!

To make a toolbar button that has the maximum width, I proceed as shown below with iOS 26. The appearance of the button is as expected, but its behavior is incorrect. The action is not triggered when tapping within the button, but outside its text. How to make the action triggered when tapping anywhere within the button ? import SwiftUI struct SampleView: View { var body: some View { NavigationStack { Text("") .toolbar { ToolbarItem(placement: .bottomBar) { Button(role: .confirm, action: self.action) { Text("Action") } .frame(maxWidth: .infinity) } } } } private func action() { print("Action Triggered !") } } #Preview { SampleView() }

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.

In my UIKit apps, collection view cells that have a context menu gain an Ask Siri item in iOS 27 without me doing anything. In my SwiftUI app I have a LazyVGrid containing a ForEach of CellView which is a Button that has a contextMenu, yet there’s no Ask Siri button in the context menu. What determines whether or not it will be added? What do I need to do to allow the system to add it?

Dear Apple Developer Support, I am developing and maintaining an iOS application. In iOS 26, we understand that setting UIDesignRequiresCompatibility to true in the Info.plist file allows an app to opt out of the Liquid Glass design. However, we also understand that during WWDC25 Platforms State of the Union, Apple stated: "We intend this option to be removed in the next major release." We would appreciate clarification on the following points. Questions Should the phrase "next major release" be interpreted as iOS 27? Is it currently Apple's plan to make UIDesignRequiresCompatibility unavailable or remove it in iOS 27? Or is the statement above only an intended direction, with the actual removal schedule still subject to change? If there is any publicly shareable information regarding the future availability or deprecation timeline of UIDesignRequiresCompatibility, could you please provide it? Background We develop and maintain a business application that contains a large number of custom screens and UI components. Adapting the entire application to the Liquid Glass design system will require significant design review, implementation effort, and testing. As a result, the future availability of UIDesignRequiresCompatibility is a critical factor in our development planning and resource allocation. For this reason, we would greatly appreciate any guidance you can provide regarding Apple's current plans for this compatibility option. Thank you for your time and assistance. Best regards, Toshiyuki

It seems like macOS 27 beta 2 has some issues with NSStatusItem buttons added to the menu bar - this creates difficulties for some menu bar extra apps. NSStatusItem buttons does not receive mouse hover/movement events - FB23329983 On macOS 27, views inside an NSStatusItem button no longer receive hover or mouse-movement events. The same code works correctly on macOS 26. What I tried: An NSTrackingArea attached to a subview of NSStatusBarButton An NSTrackingArea attached directly to the status-bar button Replacing NSStatusItem.view with a custom view Embedding an NSHostingView and using SwiftUI onHover/onContinuousHover NSStatusItem button highlight cannot be set programmatically. - FB23330269 The following code no longer has any effect (does not provide the highlight capsule): NSStatusItem.button?.highlight(true) NSStatusItem window occlusionState no longer reflects hidden menu bar visibility - FB23349447 The following no longer works: statusItem.button?.window?.occlusionState.contains(.visible) These changes may be related to some of the touch related changes or maybe it's about how menu items are now seemingly more "managed" in a way that their position, visibility may change in a way that is transparent/undetectable to the app.

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?

When cacluclating directions for .cycling, the returned route has directions.routes.first!.transporttype == .automobile if I follow the example What do I do wrong? Is this a bug? Tested on macOS 26 and iOS simulator 26

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

Hello, To support adaptive layouts on iOS27 I want to display the sidebar on landscape iPhone app windows. (Like in the old days of the iPhone 6 Plus... >.>) It appears that TabView ignores attempts to force it into sidebar mode even in the "Resize mode" of the device manager. Am I holding it wrong? Is this a bug? Apple is not clear about how their components should be behaving to support adaptive layouts, and if rumors are true, it will be important come this fall.

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}

Hi folks, there's currently a known issue in TipKit due to which it won't show popover tips on buttons that are inside a SwiftUI ToolbarItem. For example, if you try this code, the popover tip will not appear: ToolbarItem { Button(action: {...}) { Label("Tap here", systemImage: "gear") } .popoverTip(sampleTip) } There's an easy workaround for this issue. Just apply a style to the button. It can be any style. Some examples are bordered, borderless, plain and borderedProminent. Here's a fixed version of the above code: ToolbarItem { Button(action: {...}) { Label("Tap here", systemImage: "gear") } .buttonStyle(.plain) // Adding this line fixes the issue. .popoverTip(sampleTip) } Hope this helps anyone running into this issue.

I need to display verse so that if a line exceeds the right margin, it is continued on the next line but indented. In UIKit this is easy by using NSParagraphStyle and headIndent and firstLineHeadIndent. But none of this is available on SwiftUI on the Apple Watch, which marks a big step back compared to WatchKit. Is there any way to display text indented in this way? I attach two screenshots, one with the indentation and one without. The one with indentation is far more readable!

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)