According to our crash analytics, the application crashes when trying to share a PDF file in the UIDocumentInteractionController. This crash takes place on iOS 26+ only. Based on analytics, user sessions end when the pdf file is opened in the UIDocumentInteractionController. We couldn't reproduce it on a physical device or a simulator. Can you please help with a fix or at least workaround for this issue? What's your opinion for bug localization (application or framework)? Crash log is attached below. CoreFoundation __exceptionPreprocess + 164 libobjc.A.dylib objc_exception_throw + 88 CoreFoundation -[__NSArrayM insertObject:atIndex:] + 1276 ShareSheet __79-[SHSheetActivityItemsManager loadItemProvidersForRequest:activity:completion:]_block_invoke + 972 ShareSheet __79-[_UIShareServiceActivityProxy _loadItemProvidersFromActivityItems:completion:]_block_invoke + 88 ShareSheet __74+[UIActivity _loadItemProvidersFromActivityItems:withCacheURL:completion:]_block_invoke_4 + 352 libdispatch.dylib _dispatch_call_block_and_release + 32 libdispatch.dylib _dispatch_main_queue_drain.cold.5 + 812 libdispatch.dylib _dispatch_main_queue_drain + 180 CoreFoundation __CFRunLoopRun + 1944

We are experiencing an issue with a few end users where the UIAlertController's UIView is rendered with a (for the lack of a better word) "shattered" effect (see attachments). It appears to be happening only occasionally which makes me think it's a bug with iOS 26 and/or hardware issue. I'm posting here hoping to get some type of guidance on a workaround or if this is already a known issue (I have not been able to find instances of this particular issue online). Has anyone experienced or seen others experience this issue? Does anyone know of a workaround or can confirm this is a bug with iOS 26? Thanks in advance.

Hello, I'm a bit new to iOS development, so this could be something I've overlooked, but I've tried a bunch of things on my own and with the help of Copilot, as well as some senior engineers here at my company. I let AI summarize what the problem is, what I've tried, what doesn't work, and also some information on the system: Problem: UITabBarAppearance Custom Colors Ignored - All Diagnostics Show Correct Configuration Environment: iOS Deployment Target: 13.4 Xcode: Latest (26.4.1 as of writing) Device/Simulator: Both affected Language: Swift UI: UIKit with Storyboards Description: Tab bar selected item displays system default colors (gray in light mode, white in dark mode) instead of my custom named color from asset catalog. System colors like .systemBlue work correctly, but custom asset catalog colors are completely ignored. Expected behavior: Selected tab bar item should display BlueTVColor2 (RGB 0, 0.173, 0.38 in light mode; RGB 0, 0.569, 1.0 in dark mode) Actual behaviour: Selected tab bar item displays gray/white/black system defaults What I've Verified Works Correctly: Color resolution: let color = UIColor(named: "BlueTVColor2") print(color) // Resolves correctly print(color?.resolvedColor(with: .init(userInterfaceStyle: .light))) // RGB(0, 0.173, 0.38) print(color?.resolvedColor(with: .init(userInterfaceStyle: .dark))) // RGB(0, 0.569, 1.0) Asset Catalog Configuration: BlueTVColor2.colorset has both light and dark variants template-rendering-intent: template set on all tab bar images All images use .alwaysTemplate rendering mode (verified at runtime) UITabBarAppearance Configuration (Although I've also tried just directly in the storyboard, it didn't work, the below is in code-behind): override func viewDidLoad() { super.viewDidLoad() let selectedColor = UIColor(named: "BlueTVColor2")!.resolvedColor(with: traitCollection) let normalColor = UIColor.redTVColor.resolvedColor(with: traitCollection) let appearance = UITabBarAppearance() appearance.configureWithOpaqueBackground() let itemAppearance = UITabBarItemAppearance() itemAppearance.selected.iconColor = selectedColor itemAppearance.selected.titleTextAttributes = [.foregroundColor: selectedColor] itemAppearance.normal.iconColor = normalColor appearance.stackedLayoutAppearance = itemAppearance appearance.inlineLayoutAppearance = itemAppearance appearance.compactInlineLayoutAppearance = itemAppearance tabBar.isTranslucent = false tabBar.standardAppearance = appearance if #available(iOS 15.0, *) { tabBar.scrollEdgeAppearance = appearance } tabBar.tintColor = selectedColor tabBar.unselectedItemTintColor = normalColor } Runtime Diagnostics Confirm Everything is Set Correctly: Appearance selected iconColor: RGB(0, 0.569, 1) // Correct Tab bar standardAppearance selected iconColor: RGB(0, 0.569, 1) // Correct Tab bar tintColor: RGB(0, 0.569, 1) // Correct Tab bar unselectedItemTintColor: RGB(1, 0.259, 0.271) // Correct All tab bar item images: Rendering mode = 2 (.alwaysTemplate) // Correct Settings persist through viewDidAppear // Correct Yet the UI displays system default gray/white/black colors. What I've Tried (All Failed): Deprecated selectedImageTintColor property (returns nil when standardAppearance is set) Both configureWithDefaultBackground() and configureWithOpaqueBackground() Dynamic colors vs resolved fixed colors Configuring all layout appearances (stacked, inline, compactInline) Setting isTranslucent = false Re-applying appearance in viewDidAppear with delayed dispatch Manually re-applying template rendering mode to images at runtime Removing storyboard color configuration entirely Changing global accent color build setting System colors (.systemBlue) work fine; only custom asset catalog colors fail Additional Context: This is a legacy project originally created around 2013-2015, migrated to modern Swift/iOS (not everywhere, major parts are still using objc, UIKit/Storyboard) When I set tabBar.tintColor = .systemBlue it works perfectly The color BlueTVColor2 is used successfully elsewhere in the app (also if setting it as the background of the UITabBar, it works, just not as a tint for the icons/text) Storyboard has no selectedImageTintColor set (removed during debugging) No UITabBar.appearance() proxy calls anywhere in codebase Deployment target is iOS 13.4 (when UITabBarAppearance was introduced) Pre iOS 26.0, the adding of the tint color to the UITabBar worked as intended, so this has come as a result of the update to iOS 26.0 in some way Comparison with Working Test Project: Created a fresh iOS project with same setup - custom asset catalog colors work perfectly in tab bar with identical UITabBarAppearance configuration. Question: Why would UITabBarAppearance properties show correct colors in diagnostics but render with system defaults? Is there a known issue with asset catalog named colors in UITabBarAppearance on iOS 13.4+? Could legacy project settings interfere with modern appearance API? Any insights would be greatly appreciated. I'm running out of ideas and this seems like either a framework bug or some undocumented interaction between asset catalogs and tab bar appearance. Code Sample: I can't release much code besides just things I've worked on, so hopefully this full description of the problem and everything I've tried can help illuminate the issue at hand. I've tried all of the above and probably more the past week and can't make heads or tails of where the issue is located. The best I can come up with right now is some sort of compatibility issues but I have no way of determining where it is that I should investigate and fix.

Is there a safeAreaInsets equivalent that only tracks system bars (tab bars, status bars, side bars, toolbars, and navigation bars) and is not affected by notches? I'm asking this because the iPadOS tab bar can appear either on the top, bottom, or left (modally or non-modally) in various configurations, including sidebarAdaptable and when the window size is small on iPadOS; the tab bar's frame is not really reliable in this case, and while the safe area insets works, it also includes the notches / rounded window corners...

Please show me where I’ve gone amiss in MacCatalyst and UIScenes with regard to the macOS green zoom/fullscreen button. Originally the MacCatalyst App used a secondary AppKit bundle for its NSWindow work, but at some point in time AppStore Connect complained about this secondary bundle which prevented new App uploads. To continue receiving green button notifications I switched to UINSWindow. That worked. Now that I’m forced to use UIScenes I’m in a pickle: a click on the green button forces an automatic jump to fullscreen, nothing I can do about it AFAIK. A poor, poor compromise would be to disable the green button but I have no idea how even to do that. I’d like my App to exist in two states, any suggestions? Thanks.

Over the last two weeks, I’ve had sporadic reports from users who suddenly have a corrupt image in the database for my app. It’s only affecting a few users and may possibly have been fixed with iOS 26.4.1 (I’m not sure). In any case, this started suddenly with the release of iOS 26.4 - our app has not been changed in several months. But I wanted to share what’s happening in case others are experiencing this. My app lets users import photos from the camera roll, photo albums, etc. Once the user has selected an image, the app saves this to a SQLite3 database using “image.heicData()”. For the four or five users who have been affected by this problem, the heicData call returns successfully, with a non-nil Data value. But the image itself is corrupt and unreadable. When the user tries to later open a screen containing the image, the app crashes. I’ve had to manually guide each user through tracking down and removing the affected item or items to resolve it, which is a bad experience for them and time-consuming for us. Our app crashes when it tries to read the image (using “UIImage(data: heicData)”). All users who have this problem have had an ExcUserFault file in their crash reports with our app name in it. It's not possible to symbolicate this file but i've included an excerpt at the bottom of this post: I was able to extract some raw data saved when this error occurs. When you run “file corrupt_image.heic”, you get: AmigaOS bitmap font "rtypheic", fc_YSize 0, 35001 elements which definitely doesn’t seem right. On a valid HEIC file, i get: ISO Media, HEIF Image HEVC Main or Main Still Picture Profile Is anyone else experience this? Or does anyone else have any suggestions about what could be happening? I submitted feedback FB22667639 about this. ExcUserFault example Exception Type: EXC_GUARD Exception Subtype: GUARD_TYPE_USER Exception Message: namespc 7 reason_code 0x0000000000000009 Exception Codes: 0x6000000000000007, 0x0000000000000009 Termination Reason: Namespace LIBXPC, Code 9, XPC_EXIT_REASON_FAULT Thread 0: 0 ??? 0x231fa997c 0x180000000 + 2985990524 1 ??? 0x197eb98b4 0x180000000 + 401316020 2 ??? 0x197ec4e04 0x180000000 + 401362436 3 ??? 0x197ec5ea0 0x180000000 + 401366688 4 ??? 0x19066bdb8 0x180000000 + 275168696 5 ??? 0x19066b968 0x180000000 + 275167592 6 ??? 0x19b5c19a4 0x180000000 + 459020708 7 ??? 0x19b5cfa2c 0x180000000 + 459078188 8 ??? 0x19b5cf838 0x180000000 + 459077688 9 ??? 0x197ec7c74 0x180000000 + 401374324 10 ??? 0x197ec991c 0x180000000 + 401381660 11 ??? 0x1bd74222c 0x180000000 + 1031021100 12 ??? 0x1bd744ba4 0x180000000 + 1031031716 13 ??? 0x1bd730e18 0x180000000 + 1030950424 14 ??? 0x1bd7458f8 0x180000000 + 1031035128 15 ??? 0x1bd730e18 0x180000000 + 1030950424 16 ??? 0x1bd731ae4 0x180000000 + 1030953700 17 ??? 0x1bd73bdac 0x180000000 + 1030995372 18 ??? 0x1bd73b6ac 0x180000000 + 1030993580 19 ??? 0x1e23283b0 0x180000000 + 1647477680 20 ??? 0x1e23278c0 0x180000000 + 1647474880

When I set up a toolbar item group with multiple options and set the controlGroupStyle as .palette, and when one of the options are supposed to present a view controller, I get the following error Attempt to present <UINavigationController: 0x101813200> on <ProjectName.HomeTabBarViewController: 0x10701bc00> (from <UINavigationController: 0x107821000>) which is already presenting <_UIContextMenuActionsOnlyViewController: 0x1035c19d0>. So basically the context menu we see is under the hood a view controller that is being presented. Is there a right way of fixing it, or is it maybe something that will be fixed by Apple? This is how I set up the ToolbarItemGroup on SwiftUI and the view model ultimately presents another UINavigationController that has a UIHostingController as its view controller: .toolbar { ToolbarItemGroup(placement: .topBarTrailing) { Button("ft_commons_edit".localised, systemImage: "pencil") { viewModel.didTapEditAction() } Button("ft_commons_delete".localised, systemImage: "trash") { viewModel.didTapDeleteAction() } } label: { Image("edit-icon") .resizable() .frame(width: 24.0, height: 24.0) } } .controlGroupStyle(.palette) This is how the view looks like when presentation fails: As a workaround, I found two options that work well. I’d like to share them and ask for recommendations, just to make sure they won’t cause any unexpected issues later on: Option 1: Access the top most visible view controller and attempt presenting on it This requires the following extension: extension UIViewController { func topMostViewController() -> UIViewController { if let presentedViewController = self.presentedViewController { return presentedViewController.topMostViewController() } else if let navigationController = self as? UINavigationController, let topViewController = navigationController.topViewController { return topViewController.topMostViewController() } else if let tabBarController = self as? UITabBarController, let selectedViewController = tabBarController.selectedViewController { return selectedViewController.topMostViewController() } else { return self } } } Then called as: navigationController.topMostViewController().present(exerciseEditingNavController, animated: true) Option 2: Call dismiss before attempting to present anything This also works fine, even without any delay, the menu is first dismissed and presentation works fine afterwards, code example: navigationController.dismiss(animated: true) navigationController.present(exerciseEditingNavController, animated: true) I feel like Option 1 would be the better choice, because if this context menu is ever no longer treated as a view controller and direct presentation starts working, Option 1 would still behave correctly by presenting from the topmost visible view controller. Option 2, on the other hand, could introduce a bug by dismissing an unrelated view controller if the context menu is no longer represented as a view controller at that point. I would appreciate any advice from anyone who has experienced this, or from Apple developers. Thanks

Hi everyone, I found what looks like a picker issue on iOS 26 in the Clock app’s Timer screen, and I’m also seeing what appears to be the same behavior in UIPickerView in my own app. What I’m Doing I’m testing the Timer picker in the built-in Clock app. When I swipe very quickly on the hours component, trying to reach the maximum value together with minutes and seconds: 23 hours 59 minutes 59 seconds I noticed that the picker does not always land on the expected final value. I’m seeing a very similar issue with UIPickerView as well, especially in: public func pickerView(_ pickerView: UIPickerView, didSelectRow row: Int, inComponent component: Int) When swiping very quickly to the end, the selected/logged row can be inconsistent with the final visible value. Expected Behavior When swiping quickly and stopping at the end, the Timer should correctly select: 23 hours, 59 minutes, 59 seconds Likewise, in UIPickerView, didSelectRow should reflect the actual final selected row/value after the wheel settles. Actual Behavior (iOS 26) If I swipe quickly enough on the hours component, when the picker reaches: 23 hours, 59 minutes, 59 seconds it appears to count from 22 hours instead of 23 hours. So the final selected duration is effectively off by one hour, even though the wheel visually reaches the maximum end position. I’m facing the same kind of issue with UIPickerView too. In particular, inside: public func pickerView(_ pickerView: UIPickerView, didSelectRow row: Int, inComponent component: Int) when performing a very fast swipe, the reported row may behave unexpectedly near the end of the range. Additional Notes I reproduced this in the Clock app Specifically on the Timer screen The issue happens when the swipe velocity is high enough I also face the same issue with UIPickerView in my own app Question Has anyone else seen this behavior in iOS 26? Is this a known UIPickerView / wheel-picker issue, or a regression in the Timer picker logic? Any guidance would be appreciated. Thanks! P.S. I do have a video showing the issue, but I can’t upload it here. If someone could let me know the best way to share it, I’d appreciate it.

I’m seeing a rendering issue with UITabBarController on iOS 26 (Liquid Glass), and I’d like to confirm whether others can reproduce this or have a workaround. Summary If a UITabBarController is recreated while it is fully hidden behind a fullscreen modal, the tab bar renders incorrectly after dismissal. Selected tab becomes nearly invisible Unselected tabs appear to show both selected and unselected tint colors Looks like multiple rendering states are composited incorrectly This only happens with: iOS 26 (Liquid Glass enabled) UIKit UITabBarController It does not reproduce with SwiftUI TabView. Minimal Reproduction Code This is a complete, minimal example: import UIKit // MARK: - Root class RootViewController: UIViewController { private var tabBar: UITabBarController? private var modalPresented = false override func viewDidLoad() { super.viewDidLoad() installTabBar() } override func viewDidAppear(_ animated: Bool) { super.viewDidAppear(animated) // Present once on first appear, simulating an app-launch login flow. if !modalPresented { modalPresented = true presentModal() } } private func installTabBar() { let tab = UITabBarController() tab.viewControllers = [ makeTab(title: "Tab 1", systemImage: "1.circle"), makeTab(title: "Tab 2", systemImage: "2.circle"), ] tabBar = tab addChild(tab) view.addSubview(tab.view) tab.view.frame = view.bounds tab.didMove(toParent: self) } private func makeTab(title: String, systemImage: String) -> UIViewController { let vc = UIViewController() vc.view.backgroundColor = .systemBackground vc.tabBarItem = UITabBarItem(title: title, image: UIImage(systemName: systemImage), tag: 0) return vc } private func presentModal() { let modal = ModalViewController() modal.onDismiss = { [weak self] in // Recreate the tab bar while it is still fully hidden by the modal. // This seems to trigger incorrect Liquid Glass rendering. self?.tabBar?.willMove(toParent: nil) self?.tabBar?.view.removeFromSuperview() self?.tabBar?.removeFromParent() self?.installTabBar() // ← created while invisible self?.dismiss(animated: true) } modal.modalPresentationStyle = .fullScreen present(modal, animated: true) } } // MARK: - Modal class ModalViewController: UIViewController { var onDismiss: (() -> Void)? override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .systemBackground let button = UIButton(type: .system) button.setTitle("Dismiss", for: .normal) button.titleLabel?.font = .preferredFont(forTextStyle: .title2) button.addTarget(self, action: #selector(dismissTapped), for: .touchUpInside) button.translatesAutoresizingMaskIntoConstraints = false view.addSubview(button) NSLayoutConstraint.activate([ button.centerXAnchor.constraint(equalTo: view.centerXAnchor), button.centerYAnchor.constraint(equalTo: view.centerYAnchor), ]) } @objc private func dismissTapped() { onDismiss?() } } Expected Behavior The tab bar renders normally with correct Liquid Glass appearance: Selected tab is clearly visible Unselected tabs show only inactive tint Actual Behavior Selected tab becomes nearly invisible Unselected tabs show a mix of selected + unselected tint The issue resolves after backgrounding and returning to foreground Observations / Workarounds The issue does not reproduce if: The tab bar is recreated after dismissal: self.dismiss(animated: true) { self.installTabBar() } Using SwiftUI TabView Using a presentation style that does not fully cover the screen (.pageSheet, etc.) Question Has anyone else encountered this? Is there a recommended workaround besides delaying creation until after dismissal? It seems like Liquid Glass rendering may not initialize correctly when the view is attached while fully obscured, but I’m not sure if this is expected behavior or a bug.

Invalid parameter not satisfying: targetNode [UIGestureGraphEdge initWithLabel:sourceNode:targetNode:directed:] How to locate this crash?

Apps that try to access the contents of the pasteboard cause a system prompt to appear asking the user "AppName" would like to paste from "OtherAppName" Do you want to allow this? Don't Allow Paste Allow Paste This prompt does not appear if you implement a UIPasteControl and the user taps it to signal intent to paste, but this control cannot be placed into a UIMenu. I read this could be achieved with UIAction.Identifiers like .paste or .newFromPasteboard but the prompt still appears with the following code. What's the trick? override func viewDidLoad() { super.viewDidLoad() title = "TestPaste" view.backgroundColor = .systemBackground let imageView = UIImageView() imageView.translatesAutoresizingMaskIntoConstraints = false imageView.contentMode = .scaleAspectFit imageView.clipsToBounds = true view.addSubview(imageView) NSLayoutConstraint.activate([ imageView.topAnchor.constraint(equalTo: view.topAnchor), imageView.leadingAnchor.constraint(equalTo: view.leadingAnchor), imageView.trailingAnchor.constraint(equalTo: view.trailingAnchor), imageView.bottomAnchor.constraint(equalTo: view.bottomAnchor) ]) navigationItem.rightBarButtonItem = UIBarButtonItem(title: "Add", image: UIImage(systemName: "plus"), menu: UIMenu(children: [ UIAction(identifier: .paste) { _ in imageView.image = UIPasteboard.general.image } ])) }

Dear Apple Support team, I'm reaching out about an issue we're facing in our iOS audio host app on iPad. Keyboard shortcuts from an external hardware keyboard (Bluetooth) work perfectly until we load an AUv3 plugin, then the host suddenly loses all keyboard focus, and key commands stop responding completely. To give you more context: this affects every DAW that supports AUv3. I've tested it in Logic Pro for iOS, Camelot Pro, and AUM. The problem starts right after instantiating any AUv3, causing the keyboard to lose focus and preventing key commands from working. Before that, keyboard events reach our UIView without issues. Notably, this doesn't happen on iOS versions before iOS 26. I've verified it works perfectly on iOS 17 and iOS 18. You can see the full discussion and steps to reproduce in this JUCE forum thread: https://forum.juce.com/t/keyboard-focus-lost-and-keycommands-stop-working-after-instantiating-an-auv3-in-a-juce-based-host-on-ios/68497/5. It seems potentially related to AUv3 sandboxing or iOS UIView focus management. I would really appreciate your help with any insights, known issues, or workarounds. Thanks, Samuele

I am currently migrating an app from the classic UITableViewDataSource to UITableViewDiffableDataSource. In certain complex cases, I find myself needing to toggle between the UITableViewDataSource and UITableViewDiffableDataSource on a single UITableView instance. Apple's official documentation for UITableViewDiffableDataSource contains a strict warning: "Do not change the dataSource on the table view after you configure it with a diffable data source. If the table view needs a new data source after you configure it initially, create and configure a new table view and diffable data source." I’m seeking clarification on: Internal State: What specific UIKit caching or internal state is corrupted if we nil out the diffable source and re-assign a classic one? Background Processes: Does the background diffing engine pose a risk (race conditions/crashes) if the source is swapped while a diff is calculating? The "Safe" Reset: If swapping is truly necessary, is there a verified cleanup sequence (e.g., clearing snapshots first) that avoids the need to recreate the UITableView entirely?

When tapping the currently selected time in a TimePicker (wheel style) component to invoke the inline numeric pad popover, the popover renders incorrectly on iPadOS 26.4.1 — it appears as a very narrow single-line/bar rather than the full numeric keypad layout. Steps to Reproduce: Run Reminder, create a new reminder and add a custom time Tap the currently selected time value to trigger the numeric pad popover Observe the popover layout Expected Result: A properly sized popover appears containing a full numeric keypad, allowing direct numeric input of the time value — consistent with behavior on iPadOS 18.x Actual Result: The popover appears as an extremely narrow horizontal bar (single line height), making the numeric pad unusable Regression: Works correctly on iPadOS 18.x through iPadOS 26.3. Broken on iPadOS 26.4.1 (Xcode 26.x simulator and/or physical device). https://www.youtube.com/shorts/bd3pYA3B-iI https://www.youtube.com/shorts/wSHzepHBwEY Feedback: FB22517457

Hello, I am encountering a UI layout issue on iOS 26 where UITabBar items become squashed or overlapping during device rotation (from Portrait to Landscape). This glitch occurs specifically when a custom UITabBarAppearance is applied. 1. "Liquid Glass" and UITabBar Customization According to TN3106, Apple states: "Starting in iOS 26, reduce your use of custom backgrounds in navigation elements and controls. While the techniques in this document remain valid for iOS 18 and earlier, prefer to remove custom effects and let the system determine the navigation bar background appearance. Any custom backgrounds and appearances you use in the navigation bar might overlay or interfere with Liquid Glass or other effects that the system provides, such as the scroll edge effect." Does this guidance also apply to UITabBar? Specifically, could setting a custom background color via UITabBarAppearance interfere with internal layout constraints required for the Liquid Glass effect to adapt correctly during orientation changes? It appears that the internal UIStackView may fail to recalculate width in time when these system effects are active. 2. Validation of the Layout Workaround To maintain our app's visual identity while resolving this squashing issue, I implemented the following fix within the transition coordinator of my UITabBarController: Code Implementation (Objective-C) [coordinator animateAlongsideTransition:^(id<UIViewControllerTransitionCoordinatorContext> _Nonnull context) { // Forcing a layout refresh to synchronize with the rotation animation [weakSelf.tabBar invalidateIntrinsicContentSize]; [weakSelf.tabBar setNeedsLayout]; [weakSelf.tabBar layoutIfNeeded]; } completion:nil]; Is manually invalidating the intrinsic content size an acceptable practice for iOS 26? Or is there a more "system-native" approach to ensure UITabBar layout remains stable and compatible with Liquid Glass, especially when custom appearances are necessary?

We're experiencing an EXC_BAD_ACCESS (SIGSEGV) crash in UIView.drawHierarchy(in:afterScreenUpdates: false) that occurs only on iOS 26.3.1 and later. It does not reproduce on iOS 26.3.0 or earlier. Crash Stack Thread 0 (Main Thread) — EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0 libvDSP.dylib vConvert_XRGB2101010ToARGB8888_vec 1 ImageIO IIOIOSurfaceWrapper_CIF10::CopyImageBlockSetWithOptions 2 ImageIO IIOImageProviderInfo::CopyImageBlockSetWithOptions 3 ImageIO CGImageReadGetBytesAtOffset 4 CoreGraphics CGAccessSessionGetBytes 5 CoreGraphics img_data_lock 6 CoreGraphics CGSImageDataLock 7 CoreGraphics ripc_AcquireImage 8 CoreGraphics ripc_DrawImage 9 CoreGraphics CGContextDrawImage 10 UIKitCore -[UIView(Rendering) drawHierarchy:afterScreenUpdates:] The crash occurs during 10-bit CIF10 → 8-bit ARGB8888 pixel conversion when the IOSurface backing a UIImageView in the view hierarchy is deallocated mid-render. How to Reproduce Display a scrollable list with multiple UIImageViews loaded via an async image library Call drawHierarchy(in: bounds, afterScreenUpdates: false) on visible cells periodically Scroll to trigger image recycling Crash occurs sporadically — more likely under memory pressure or rapid image recycling What We've Tried Both UIKit off-screen rendering approaches crash on iOS 26.3.1: Approach Result drawHierarchy(afterScreenUpdates: false) EXC_BAD_ACCESS in CIF10 IOSurface decompression view.layer.render(in:) EXC_BAD_ACCESS in Metal (agxaAssertBufferIsValid) iOS Version Correlation iOS 26.3.0 and earlier: No crash iOS 26.3.1 (23D8133)+: Crash occurs (~5 events per 7 days) We suspect the ImageIO security patches in iOS 26.3 (CVE-2026-20675, CVE-2026-20634) may have changed IOSurface lifecycle timing, exposing a race condition between drawHierarchy's composited buffer read and asynchronous IOSurface reclamation by the OS. Crash Data We sampled 3 crash events: Event 1 (iOS 26.3.1): 71 MB free memory — memory pressure Event 2 (iOS 26.3.1): 88 MB free memory — memory pressure Event 3 (iOS 26.3.2): 768 MB free memory — NOT memory pressure Event 3 shows this isn't purely a low-memory issue. The IOSurface can be reclaimed even with ample free memory, likely due to async image recycling. Question Is this a known regression in iOS 26.3.1? Is there a safe way to snapshot a view hierarchy containing IOSurface-backed images without risking EXC_BAD_ACCESS? Should drawHierarchy gracefully handle the case where an IOSurface backing store is reclaimed during the render? Any guidance or workarounds would be appreciated. We've also filed this as Feedback (will update with FB number after submission).

I am facing weird keyboard issue when building the app with Xcode 26 recently. Actual behaviour I need is: But one below is the issue as the keyboard keys are greyed out: Please tell how to resolve this issue

Environment: Xcode Version: Xcode 26.3 Affected iOS Versions: iOS 26.1 and later Working iOS Versions: iOS 26.0 and earlier Tested Devices: iPhone 15 Pro (iOS 26.2) - ❌ Bug presents iPhone 17 (iOS 26.1) - ❌ Bug presents iPhone Air (iOS 26.0) - ✅ Works as expected iPhone 16 Pro Max (iOS 18.0) - ✅ Works as expected Description: We have identified a severe localization regression regarding the setAlternateIconName(_:completionHandler:) API starting from iOS 26.1. Our application is strictly restricted to support only Traditional Chinese (zh-TW / zh-Hant). We have correctly configured CFBundleLocalizations, CFBundleDevelopmentRegion, and explicitly set CFBundleAllowMixedLocalizations to YES in our Info.plist. In iOS 26.0 and earlier, when changing the app icon, the system alert correctly displays in Traditional Chinese. However, in iOS 26.1 and later, the alert unexpectedly falls back to English, completely ignoring the app's localization constraints and the user's preferred device language. Crucial Observation: We noticed a significant behavioral change: in iOS 26.1+, invoking setAlternateIconName forces the app to enter the sceneWillResignActive state before the alert appears. This behavior did not exist prior to iOS 26.1. This strongly suggests that the alert has been moved to an out-of-process overlay managed by SpringBoard. It appears that the system cache is failing to properly resolve the app's CFBundleLocalizations during this out-of-process presentation. Steps to Reproduce: Create an iOS application restricted to Traditional Chinese (zh-TW). Set CFBundleDevelopmentRegion to zh-Hant in Info.plist. Set the CFBundleLocalizations array to contain only zh-TW (or zh-Hant). Set CFBundleAllowMixedLocalizations to YES. Implement setAlternateIconName to trigger the app icon change. Run the app on a device running iOS 26.1 or later (ensure the device's system language is set to Traditional Chinese). Trigger the icon change action. Expected Result: The app should NOT trigger sceneWillResignActive (maintaining iOS 26.0 behavior); OR the out-of-process system alert must correctly read the Info.plist and display the prompt in Traditional Chinese. Actual Result: The app immediately triggers sceneWillResignActive and loses focus. The system overlay alert appears but ignores all Traditional Chinese settings, displaying an English interface instead. Any insights or workarounds from the engineering team would be highly appreciated. We'd like to know if this is a known SpringBoard rendering issue in iOS 26.1+. Thank you!

in iOS26.4, after installing the app for the first time, opening the app and clicking on the UITextField input box will trigger the system to pop up the network permission application interface. This issue did not exist before iOS 26.3, only in iOS 26.4. This is a fatal bug where the network permission request box should not pop up when the developer has not called the network related API.

I have built my custom keyboard, is there a way to customize the bottom most layer of keyboard where only globe and system mic icons are visible . Iike I want to put my app name between globe and mic icon. Also I know that by setting hasDictationKey = true, we can remove showing the system mic icon from keyboard , but can I add any text or icon to that area of keyboard.