This is UIKit app, in Xcode 26.3 (but same issue in 16.4). I create (in IB) a segmentedControl, with 2 segments. I set the images that are stored in assets. They show properly in Xcode. But when running (26.1 simulator), they just show a black image. In Xcode                                                                           On simulator at runtime I've tried to set background to clear as well as tint, to no avail. What am I missing ?

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?

We are currently having an issue with our app hanging for some (not all) of our iOS 26.x users. The hang lasts long enough for the system to kill the app after a while. As of now we are unable to reproduce the issue on our own test devices, yet users dealing with the issue can produce it consistently. Looking at the stack traces we managed to retrieve, the hangup seems to occur in the layout rendering cycle of the navigation bar in the UINavigationController. The hangup doesn't happen at the exact same stack trace every time. But it always seems to be in the rendering cycle. Stack trace 1 Stack trace 2 Stack trace 3 Since the issue not reproducable in our own test environment it's hard to properly debug. The only adjustments to the navigationbar/navigationitem in our code is setting the title and a few bar buttons: self.navigationItem.title = NSLocalizedString("main_list_title", comment: "") let cancelItem = UIBarButtonItem(barButtonSystemItem: .stop, target: self, action: #selector(cancelListSelection)) let addPostItem = UIBarButtonItem(image: UIImage(named: "AddButton"), style: .plain, target: self, action: #selector(addItemTapped)) let extraMenuItem = UIBarButtonItem(image: UIImage(named: "ExtraButton"), style: .plain, target: self, action: #selector(extraItemTapped)) self.navigationItem.setLeftBarButton(cancelItem, animated: true) self.navigationItem.setRightBarButtonItems([addPostItem, extraMenuItem], animated: true) let previousButton = UIBarButtonItem(image: UIImage(named: "LeftArrow"), style: .plain, target: self, action: #selector(openPrevious)) let nextButton = UIBarButtonItem(image: UIImage(named: "RightButton"), style: .plain, target: self, action: #selector(openNext)) self.setToolbarItems([previousButton, nextButton], animated: true) And for one or two controllers the title is replaced by a UISegmentControl: let segControl = UISegmentedControl(items: ["1", "2", "3"]); segControl.selectedSegmentIndex = 0 segControl.addTarget(self, action: #selector(segmentValueChanged), for: .valueChanged) self.navigationItem.titleView = segControl Is anyone familiar with hangs at these particular stack traces and their cause?

Hello, Could someone from Apple clarify the support and behavior of the UIDesignRequiresCompatibility property? The UIDesignRequiresCompatibility documentation states that this property will be ignored for builds targeting iOS 27 or later. I have a couple of questions: Does "builds targeting iOS 27 or later" refer to an app that was built using Xcode 27 or later? iOS 27 is expected to be released in Fall 2026. Suppose that after iOS 27 is released, I create a new build using Xcode 26, with UIDesignRequiresCompatibility set to true, and install that build on an iOS 27 device. Will UIDesignRequiresCompatibility still be honored in this scenario, or will it be ignored and the app will use the Liquid Glass UI? Thanks!

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)

Our app is using react native and native swift code to build an iOS app. We have some screens in both sides need to be protected if user is trying to capture a screenshots of it. We are trying to workaround to implement this screen protection by using UITextField and set isSecureTextEntry = true But there are some issues that we are facing as below: App is hang after go back from a screen that's is protected When app go back from a protected screen there is a black screen show up when screen is transiting back If we do protect entire screen from React Native side, there are leaking memory in react native screen and it can not be free up Do we have any other solution to prevent screenshot or can we fix above issues and continue using UITextField to implement it?

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.)

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.

I have an app that uses UIToolbar and UIBarButtonItem, I create the bar button items using init(customView:), but I need them to be larger than the default toolbar item size, so I constrain the custom views to be larger, such as 50x50. Example: let button = UIButton(type: .system) button.translatesAutoresizingMaskIntoConstraints = false NSLayoutConstraint.activate([ button.widthAnchor.constraint(equalToConstant: 50), button.heightAnchor.constraint(equalToConstant: 50), ]) let item = UIBarButtonItem(customView: button) toolbar.items = [item] This worked on iOS 26 and would show a circular glass button. But on iOS 27 the button shows as an oval where the height seems capped at 44pt, and can't be made any taller. This has been an issue for all iOS 27 betas so far, and I've already filed this as a feedback (FB23641020). Has anyone else seen this issue or found a workaround?

On iOS 26 (reproduced on both Simulator and iPhone), the system share sheet (UIActivityViewController) displays the row of activity/app icons at a greatly oversized scale. The app's approximate hierarchy is like UIWindow.rootViewController → a plain container UIViewController → UITabBarController → an embedded container child → UINavigationController → the visible screen. When the share sheet is presented from a view controller inside such an hierarchy, the icons are oversized. When the same UIActivityViewController, with the exact same activity items, is presented from a full-screen modal view controller (modalPresentationStyle = .fullScreen / .overFullScreen), the icons render correctly. Is this a bug of iOS 26+? On iOS 27 the behaviour is the same.

On iPadOS 26.x, multiple users of our iPad app report that handwriting English words with Apple Pencil (Scribble) into a text field produces garbled output full of accented / non‑English characters instead of the English letters they wrote. Example of what shows up when a user handwrites a normal English word: -4ęśïćïá. Those accented letters (Polish / Spanish / French‑style diacritics: ę ś ï ć á) are not what the user wrote. Key facts from the reports Happens only on iPadOS 26.x — not seen on earlier iPadOS versions. Happens only with Apple Pencil / Scribble handwriting. Typing into the same field with the on‑screen keyboard is fine. The same users say Scribble works normally in other apps. The affected field is restricted to English‑only input; when that English‑only restriction is turned off, Scribble recognizes the handwriting correctly again. So the trigger appears to be Scribble writing into an English‑restricted field on iPadOS 26. No third‑party keyboards or input methods are involved. Steps (as reported by users) iPad on iPadOS 26.x with an Apple Pencil. Open the spelling/answer screen that has an English‑only input field. Handwrite an English word with the Pencil. The field fills with accented gibberish instead of the word. Question Is this a known iPadOS 26 Scribble regression? Is anyone else seeing garbled / accented output when Scribble writes into an English‑restricted text field? Any workaround short of removing the English‑only restriction? Environment Multiple end users, all on iPadOS 26.x (exact builds / iPad models being collected). I'm the developer and haven't been able to reproduce locally yet, so this is based on user reports.

I’ve been investigating a noticeable animation hitch when interactively dismissing a sheet over a SwiftUI screen with moderate complexity. This was not the case on iOS 18, so I’m curious if others are seeing the same on iOS 26 or have found any mitigations. When dismissing a sheet via the swipe gesture, there’s a visible hitch right after lift-off. The hitch comes from layout work in the underlying view (behind the sheet) The duration scales with the complexity of that view (e.g. number of TextFields/layout nodes) The animation for programmatic dismiss (e.g. tapping a “Done” button) is smooth, although it hangs for a similar amount of time before dismissing, so it appears that the underlying work still happens. SwiftUI is not reevaluating the body during this (validated with Self._printChanges()), so that is not the cause. Using Instruments, the hitch shows up as a layout spike on the main thread: 54ms UIView layoutSublayersOfLayer 54ms └─ _UIHostingView.layoutSubviews 38ms └─ SwiftUI.ViewGraph.updateOutputs 11ms ├─ partial apply for implicit closure #1 in closure #1 │ in closure #1 in Attribute.init<A>(_:) 4ms └─ -[UIView For the same hierarchy with varying complexity: ~3 TextFields in a List: ~25ms (not noticeable) ~20+ TextFields: ~60ms (clearly visible hitch) The same view hierarchy on iOS 18 did not exhibit a visible hitch. I’ve tested this on an iOS 26.4 device and simulator. I’ve also included a minimum reproducible example that illustrates this: struct ContentView: View { @State var showSheet = false var body: some View { NavigationStack { ScrollView { ForEach(0..<120) { _ in RowView() } } .navigationTitle("Repro") .toolbar { ToolbarItem(placement: .topBarTrailing) { Button("Present") { showSheet = true } } } .sheet(isPresented: $showSheet) { PresentedSheet() } } } } struct RowView: View { @State var first = "" @State var second = "" var body: some View { VStack(alignment: .leading, spacing: 12) { Text("Row") .font(.headline) HStack(spacing: 12) { TextField("First", text: $first) .textFieldStyle(.roundedBorder) TextField("Second", text: $second) .textFieldStyle(.roundedBorder) } HStack(spacing: 12) { Text("Third") Text("Fourth") Image(systemName: "chevron.right") } } } } struct PresentedSheet: View { @Environment(\.dismiss) private var dismiss var body: some View { NavigationStack { List {} .navigationTitle("Swipe To Dismiss Me") .toolbar { ToolbarItem(placement: .topBarTrailing) { Button("Done") { dismiss() } } } } } } Is anyone else experiencing this and have any mitigations been found beyond reducing view complexity? I’ve filed a feedback report under FB22501630.

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

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).

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

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?