Hello, In my app, I have a List with two sections. The first section contains favourited items. The second section contains all the items. I use a swipeAction to favorite / undo favorite an item. An item can be in the first section and in the second section. But when I use the swipeAction to perform the action, the row animation is conflicting with the List animation for insertion / removal (I think). It’s not synchronised and it leads to an ugly UX. GeometryGroup on the Section does not help. One solution is to delay the action so the swipe has enough time to go back to its original position but it’s hacky and depends too much on manual timing, etc. If I favorite / undo from a tap on the row (no swipe action), the animation is correct (obviously, as the row doesn’t need to animate to its original position). I experimented with a ScrollView + swipeActionsContainer() + swipeActions on iOS 27, and it works very nicely. But this solution only works for iOS 27 and my app targets iOS 18. So I would love to have a native implementation for iOS 18+ if possible. Am I missing something to get the correct animation with a List? You can check the attached code: https://gist.github.com/alpennec/f9de25cda29b515eb45af6b368a89ed8 Video: https://www.dropbox.com/scl/fi/sqitivihm4pbu8htxicap/ListSectionsSwipeActions.mov?rlkey=08wl708g82rmyy6nkf75725bv&st=0qb7rhdd&dl=0 I also filed a feedback with a video: FB23661327 Regards, Axel

What is the recommended architecture for a native iPadOS application that automatically creates an interactive external workspace on a connected display while preserving pointer interaction and allowing custom layouts?

viewSafeAreaInsetsDidChange system callback stopped firing on iOS 27 when compiled with iOS 26 SDK (Xcode 26). more context: whenever tabBar's minimize behaviour changes for example on scroll-down viewSafeAreaInsetsDidChange was being called correctly on iOS 26 but it stopped on iOS 27. when compiling on Xcode 27 it is being called correctly just callback stopped firing on iOS 27 when compiled with iOS 26 SDK (Xcode 26).

I would need to know which gender is used by the iOS system for speechSynthesis. I have tried let aVoice = AVSpeechSynthesisVoice() print(#function, #line, aVoice.gender.rawValue) But always get 0, for unspecified

Posting here in case other CarPlay developers are hitting the same thing, and to give Apple engineers a forum-side reference for the radar. Filed as FB22828125. Symptom In a CarPlay app using CPListTemplate, UIImage instances assigned to CPListItem.image start rendering as the system placeholder glyph after extended CarPlay use (several hours to a few days of cumulative session time). Text labels and accessory chevrons still render correctly — only the leading image is affected, and it affects every visible template surface at once. Known recovery Once the failure starts, it survives: Killing and relaunching the app Force-quitting and relaunching from CarPlay itself Disconnecting and reconnecting CarPlay The only known recovery is rebooting the iPhone. After reboot, the same code path renders correctly again — until the failure reoccurs. App-side ruling-out UIImage instances passed to CPListItem.image are non-nil at failure time (verified by assertions) Each template rebuild calls UIGraphicsImageRenderer afresh from UIImage(systemName:) — no caching of UIImage across rebuilds Images are baked via withTintColor(_:renderingMode: .alwaysOriginal) then rasterized, so CarPlay receives a finished bitmap rather than a template image relying on its tinting pipeline Same code path renders correctly on launch and for hours afterward — the input bytes are identical before and after the failure boundary Because the failure survives both the app process and the CPTemplateApplicationScene teardown, the corrupted state appears to live in an iOS system process rather than in the app or the CarPlay session. Question for the forum Is there a known workaround on the app side — a different image-supply API, or a way to force the CarPlay rendering pipeline to invalidate its cache without an iPhone reboot?

The context is partially expressed in an earlier post. In summary: There is an iOS App target that contains minimal code, only to load a Framework explicitly at runtime using dlopen and dlsym, instead of the usual load-time imports in Apple platforms. For iOS app (C++ (primary) and Swift), the entry point is a UIApplicationDelegate conformer class - AppDelegate, marked with @main. But the problem is, the AppDelegate class cannot remain in the App target, which has barely any logic. The App target is a thin loader. The AppDelegate contains some methods such as application(_:didRegisterForRemoteNotificationsWithDeviceToken:) that needs some logical processing, which is not present in the App target. Instead of using dlsym (to hand over to the Framework) for every AppDelegate event that doesn't have a broadcast notification, the thought was to move the AppDelegate class into the Framework, and the entry point in App target is now main.swift. This keeps the Framework clean and minimal with the following steps: Interop to C++ Explicitly loading the MachO binary inside the Framework using dlopen Loading the symbol using dlsym Invoking the Framework entry point Then, the Framework entry point in C++ creates the UIApplication class and the UIApplicationDelegate using UIApplicationMain(_:_:_:_:) method, which doesn't return as it transfers control to the UIApplicationDelegate. This is against the recommended @main entry point, but based on research, @main seems like syntactic sugar to avoid writing boilerplate code. But in my case, which needs to avoid instantiating the UIApplicationDelegate in the App target, using main.swift, even for an iOS app, is the best fit. I understand that main thread has to be returned back to the OS asap for processing user events etc., and the intent is to not execute the entire startup logic of the app in main thread. Wanted to confirm if this approach of using main.swift entry point is valid for iOS, iPadOS and tvOS apps too and in which case, these flows can converge to macOS, which is already using main.swift approach.

My app start up has became horrid. It takes 1 minute to open SQLlite database for my rust core. Impossible to work... I have Address Sanitizer, Thread Perf Checker and Thread Sanitizer disabled...

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.

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?

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

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!

In the WWDC 2026 sessions it was called out in code that the helper functions would still work, however they don't seem to be working either inside a UIViewRepresentable, nor as a UIKit View as below (also tried as a sheet, to no avail). Otherwise it works. Is there something else I'm missing? import SwiftUI import ImagePlayground @available(iOS 27.0, *) final class ImagePlaygroundPopupController: UIViewController { var sourceImage: UIImage var prompt: String var onComplete: (URL) -> Void var onCancel: () -> Void private var didPresent = false private var playgroundVC: ImagePlaygroundViewController? init( sourceImage: UIImage, prompt: String, onComplete: @escaping (URL) -> Void, onCancel: @escaping () -> Void ) { self.sourceImage = sourceImage self.prompt = prompt self.onComplete = onComplete self.onCancel = onCancel super.init(nibName: nil, bundle: nil) view.backgroundColor = .clear } required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } override func viewDidAppear(_ animated: Bool) { super.viewDidAppear(animated) guard !didPresent else { return } didPresent = true let vc = ImagePlaygroundViewController() vc.sourceImage = sourceImage vc.concepts = [.text(prompt)] vc.delegate = self playgroundVC = vc present(vc, animated: true) } } @available(iOS 27.0, *) extension ImagePlaygroundPopupController: ImagePlaygroundViewController.Delegate { func imagePlaygroundViewController( _ imagePlaygroundViewController: ImagePlaygroundViewController, didCreateImageAt imageURL: URL ) { imagePlaygroundViewController.dismiss(animated: true) { self.playgroundVC = nil self.onComplete(imageURL) } } func imagePlaygroundViewControllerDidCancel( _ imagePlaygroundViewController: ImagePlaygroundViewController ) { imagePlaygroundViewController.dismiss(animated: true) { self.playgroundVC = nil self.onCancel() } } } @available(iOS 27.0, *) struct ImagePlaygroundPopupView: UIViewControllerRepresentable { let sourceImage: UIImage let prompt: String let onComplete: (URL) -> Void let onCancel: () -> Void func makeUIViewController(context: Context) -> ImagePlaygroundPopupController { ImagePlaygroundPopupController( sourceImage: sourceImage, prompt: prompt, onComplete: onComplete, onCancel: onCancel ) } func updateUIViewController( _ uiViewController: ImagePlaygroundPopupController, context: Context ) {} }

Emoji are very convenient to be used instead of image, directly as String. In some cases, a variation to show them rotated (but still as String, not converted as image) would be useful. Examples may be arrows or flags if you need to show them floating from the top and not from the side of the pole. And I would declare: flag = "🇺🇸" or So the question; is it possible to generate new emoji as rotated initial emojis ? Or better, do such extensions already exist.

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 ?

I'm seeing what appears to be different UISceneAppIntent behavior between iOS and Designed for iPad on macOS, and I'd like to confirm whether this is expected. I'm working on an iOS app that defines an AppIntent conforming to UISceneAppIntent from the AppIntents framework. The intent is handled by a scene delegate conforming to both UIWindowSceneDelegate and AppIntentSceneDelegate. On iOS, everything works as expected: If the app is launched for the first time from Shortcuts, the intent is available via connectionOptions.appIntent in scene(_:willConnectTo:options:). If the app is already running, scene(_:willPerformAppIntent:) is called. However, when running the same iOS app on macOS in Designed for iPad mode, the behavior is different: If the app is launched from Shortcuts, connectionOptions.appIntent is always nil in scene(_:willConnectTo:options:). If the app is already running, scene(_:willPerformAppIntent:) is never called, even though the application is successfully activated. Is this expected behavior? I noticed that the AppIntents framework explicitly marks both AppIntentSceneDelegate and UISceneAppIntent as unavailable on macOS: @available(iOS 26.0, tvOS 26.0, *) @available(macOS, unavailable) @available(watchOS, unavailable) public protocol AppIntentSceneDelegate : UISceneDelegate Since the app is running on macOS in Designed for iPad mode and still uses the iOS binary, I wasn't sure whether these scene-based APIs are expected to work in this environment or whether they are intentionally unsupported. Has anyone from Apple or the community been able to confirm whether this behavior is by design, or whether it should be considered a bug? I'd appreciate any clarification.

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

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)

Hi everyone, I'm experiencing a weird visual glitch with PickerStyle(.segmented) placed inside a ToolbarItem(placement: .principal). When navigating between views or switching segments, the text doubles/overlaps temporarily during the transition animation (as shown in the screen recording).