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

If you use UISceneDelegate's scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) to handle deep links (such as tapping a widget) you might run into an issue where this callback is called twice in the majority of cases. If you push a view controller in response to this, you might end up with two pushed view controllers, if you do not mitigate this. This is exclusively an issue in iOS 26.0 and works as expected on iOS 18. func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) { /// Add any widget to the home screen that uses the widgetURL modifier and tap them. Most of the time, openURLContexts() will get called twice. /// If you run this project on iOS 18, it's *always* called once as expected. print("openURLContexts \(URLContexts)") } Filed as FB20301454

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

Hello, I'm experiencing a navigation bar positioning issue with my UIKit iPad app on iPadOS 26 (23A340) using Xcode 26 (17A321). The navigation bar positions under the status bar initially, and after orientation changes to landscape, it positions incorrectly below its expected location. This occurs on both real device (iPad mini A17 Pro) and simulator. My app uses UIKit + Storyboard with a Root Navigation Controller. A stack overflow post has reproduce the bug event if it's not in the same configuration: https://stackoverflow.com/questions/79752945/xcode-26-beta-6-ipados-26-statusbar-overlaps-with-navigationbar-after-presen I have checked all safe areas and tried changing some constraints, but nothing works. Have you encountered this bug before, or do you need additional information to investigate this issue?

Since the beta releases of iPadOS 26 we have been having some crashes about Invalid parameter not satisfying: parentEnvironment != nil We got to contact a couple of users and we found out that the crash appears when entering a screen in a UINavigationController with the iPad device connected to a Magic Keyboard. If the device is not connected to the keyboard then nothing happens and everything works ok. From our end we haven't managed to reproduce the crash so I am pasting part of the stacktrace if it can be of any help. 3 UIKitCore 0x19dfd2e14 -[_UIFocusContainerGuideFallbackItemsContainer initWithParentEnvironment:childItems:] + 224 (_UIFocusContainerGuideFallbackItemsContainer.m:23) 4 UIKitCore 0x19dae3108 -[_UIFocusContainerGuideImpl _searchForFocusRegionsInContext:] + 368 (_UIFocusGuideImpl.m:246) 5 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 6 UIKitCore 0x19db28900 -[_UIFocusMapSnapshot addRegionsInContainers:] + 160 (_UIFocusMapSnapshot.m:545) 7 UIKitCore 0x19d1313dc _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 632 (_UIFocusRegion.m:143) 8 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 9 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 10 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 11 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 12 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 13 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 14 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 15 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 16 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 17 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 18 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 19 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 20 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 21 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 22 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 23 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 24 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 25 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 26 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 27 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 28 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 29 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 30 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 31 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 32 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 33 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 34 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 35 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 36 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 37 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 38 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 39 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 40 UIKitCore 0x19d132e08 -[_UIFocusMapSnapshot _capture] + 424 (_UIFocusMapSnapshot.m:403) 41 UIKitCore 0x19db2675c -[_UIFocusMapSnapshot _initWithSnapshotter:mapArea:searchArea:] + 476 (_UIFocusMapSnapshot.m:171) 42 UIKitCore 0x19d130dcc -[_UIFocusMapSnapshotter captureSnapshot] + 192 (_UIFocusMapSnapshotter.m:137) 43 UIKitCore 0x19db2045c -[_UIFocusMap _inferredDefaultFocusItemInEnvironment:] + 136 (_UIFocusMap.m:168) 44 UIKitCore 0x19daffd2c -[_UIFocusEnvironmentPreferenceEnumerationContext _inferPreferencesForEnvironment:] + 140 (_UIFocusEnvironmentPreferenceEnumerator.m:313) 45 UIKitCore 0x19d127ab4 -[_UIFocusEnvironmentPreferenceEnumerationContext _resolvePreferredFocusEnvironments] + 104 (_UIFocusEnvironmentPreferenceEnumerator.m:250) 46 UIKitCore 0x19d127394 -[_UIFocusEnvironmentPreferenceEnumerationContext preferredEnvironments] + 36 (_UIFocusEnvironmentPreferenceEnumerator.m:184) 47 UIKitCore 0x19d126e94 _enumeratePreferredFocusEnvironments + 400 (_UIFocusEnvironmentPreferenceEnumerator.m:503)

After updating to Xcode 26 my XCUITests are now failing as during execution exceptions are being raised and caught by my catch all breakpoint These exceptions are only raised during testing, and seem to be referencing some private internal property. It happens when trying to tap a button based off an accessibilityIdentifier e.g. accessibilityIdentifier = "tertiary-button" ... ... app.buttons["tertiary-button"].tap() The full error is: Thread 1: "[<UIKit.ButtonBarButtonVisualProvider 0x600003b4aa00> valueForUndefinedKey:]: this class is not key value coding-compliant for the key _titleButton." Anyone found any workarounds or solutions? I need to get my tests running on the liquid glass UI

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

On iPad OS 26, the custom keyboard works correctly with a full keyboard, but with a floating keyboard, there is only one line and the console displays a constraint error. Unable to simultaneously satisfy constraints. Probably at least one of the constraints in the following list is one you don't want. Try this: (1) look at each constraint and try to figure out which you don't expect; (2) find the code that added the unwanted constraint or constraints and fix it. ( "<NSLayoutConstraint:0x600002172c10 V:|-(10)-[TUIKeyboardContentView:0x1039c5410] (active, names: '|':TUIKeyplaneView:0x1039c3e20 )>", "<NSLayoutConstraint:0x600002172c60 V:[TUIKeyboardContentView:0x1039c5410]-(-11)-| (active, names: '|':TUIKeyplaneView:0x1039c3e20 )>", "<NSLayoutConstraint:0x6000021721c0 V:|-(0)-[TUIKeyplaneView:0x1039c3e20] (active, names: UIKeyboardLayoutStar Prev...:0x105160e00, '|':UIKeyboardLayoutStar Prev...:0x105160e00 )>", "<NSLayoutConstraint:0x600002172210 V:[TUIKeyplaneView:0x1039c3e20]-(0)-| (active, names: UIKeyboardLayoutStar Prev...:0x105160e00, '|':UIKeyboardLayoutStar Prev...:0x105160e00 )>", "<NSLayoutConstraint:0x6000021728a0 V:|-(0)-[UIKeyboardLayoutStar Prev...] (active, names: UIKeyboardLayoutStar Prev...:0x105160e00, '|':UIKeyboardImpl:0x109905fa0 )>", "<NSLayoutConstraint:0x6000021728f0 V:[UIKeyboardLayoutStar Prev...]-(0)-| (active, names: UIKeyboardLayoutStar Prev...:0x105160e00, '|':UIKeyboardImpl:0x109905fa0 )>", "<NSLayoutConstraint:0x600002177980 '_UITemporaryLayoutHeight' UIKeyboardImpl:0x109905fa0.height == 0 (active)>", "<NSLayoutConstraint:0x600002172df0 'TUIKeyplane.height' TUIKeyboardContentView:0x1039c5410.height == 217 (active)>" ) Will attempt to recover by breaking constraint <NSLayoutConstraint:0x600002172df0 'TUIKeyplane.height' TUIKeyboardContentView:0x1039c5410.height == 217 (active)> Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger. The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKitCore/UIView.h> may also be helpful. iPad OS 26 custom keyboard, full keyboard mode is working normally.

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

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?

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?

Fatal Exception: NSInternalInconsistencyException Cannot remove an observer <WKWebView 0x135137800> for the key path "configuration.enforcesChildRestrictions" from <STScreenTimeConfigurationObserver 0x13c6d7460>, most likely because the value for the key "configuration" has changed without an appropriate KVO notification being sent. Check the KVO-compliance of the STScreenTimeConfigurationObserver [class.] I noticed that on iOS 26, WKWebView registers STScreenTimeConfigurationObserver, Is this an iOS 26 system issue? What should I do?

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.

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!

I’m developing an iOS app that integrates with CallKit. Starting from iOS 26, I’ve noticed that the system automatically presents a top banner / toast-style UI when a CallKit call becomes active (see attached screenshot). This UI appears to be fully managed by the system. On iOS versions prior to iOS 26, this UI did not appear under the same CallKit configuration. What I’ve observed The banner is displayed automatically by the system It appears at the top of the screen, similar to a toast or call status banner It is not a view created by my app I could not find any public API or CallKit configuration related to dismissing or controlling it My questions： Is this top banner an intended system behavior change in newer iOS versions? Is there any public API to dismiss, hide, or customize this UI? If not, is this UI considered non-dismissible by design? Any clarification on the expected behavior or recommended approach would be greatly appreciated.

There appears to be a serious issue in iOS 26.4 regarding text alignment. All text strings are rendered right-aligned instead of left-aligned, even when explicitly setting the paragraph style to NSTextAlignmentLeft. This behavior is unexpected and seems to indicate a regression in text rendering. Could you please confirm whether this is a known issue in iOS 26.4? I am using the following code in a central function that has been working reliably for years across all my apps. Best regards, Rolf Code: NSMutableParagraphStyle* paragraphLeft = [[NSMutableParagraphStyle alloc] init]; if (paragraphLeft != nil) { paragraphLeft.alignment = NSTextAlignmentLeft; NSDictionary *settings = @{ NSFontAttributeName : font, NSForegroundColorAttributeName : fontclr, NSParagraphStyleAttributeName : paragraphLeft }; [theString drawAtPoint:CGPointMake(x, y - font.ascender) withAttributes:settings]; [paragraphLeft release]; }

Hello, I’ve noticed an issue with custom keyboard extensions in iOS 26 that seems specific to native apps. When a custom keyboard is opened in apps like Messages, Notes, or Safari, there’s an extra strip of native grey space around the left, right, and top edges of the keyboard. This extra margin cannot be rendered over by the keyboard’s own views. Interestingly, this behaviour does not occur in third-party apps like Instagram. It also wasn’t present in earlier iOS versions. The result is that keyboards with custom or non-grey backgrounds look visually inconsistent (they appear framed by unwanted grey). Has anyone else run into this? Is this a known change in iOS 26, or could it be a bug? Any guidance or official clarification would be appreciated. Thanks!

Hi Team I’m facing an issue with UISwitch inside a UITableViewCell on iOS 26. When the switch is toggled, I update my data and call tableView.reloadData(). Since both the switch animation and table view reload happen at the same time, the UISwitch does not show its glass effect properly (it looks flat/missing during the animation). If I delay the reload, the switch renders correctly. Is this a known issue? Is there a recommended way to handle this without affecting the switch’s visual appearance?

We're experiencing a severe main thread hang (29 seconds) in our CarPlay audio app when calling [CPListItem setImage:] on iOS 26.4. This issue affects 81% of our reported hang cases, and is concentrated on iOS 26.4. Environment iOS 26.4 CarPlay Audio app Images are downloaded via SDWebImage, resized to appropriate scale, then set via [CPListItem setImage:] on the main thread Problem When multiple list item images finish downloading around the same time, each setImage: call triggers expensive synchronous CoreUI operations on the main thread. The total accumulated time causes a 29-second freeze. The entire hang occurs inside Apple frameworks — no app code is on the hot path after calling setImage:. Call Stack (simplified) [CPListItem setImage:] └─ [CPImageSet initWithImage:treatmentBlock:] (57% + 21% + 18% = 96%) └─ [UIImageAsset imageWithTraitCollection:] └─ [UIImageAsset _withLock_imageWithConfiguration:] └─ [UIImageAsset _performLookUpRegisteredObjectForTraitCollection:] └─ [UITraitCollection _enumerateThemeAppearanceNamesForLookup:] └─ [CUICatalog _imageWithName:scaleFactor:deviceIdiom:...] └─ [CUIMutableStructuredThemeStore canGetRenditionWithKey:] └─ [CUIMutableStructuredThemeStore renditionWithKey:] └─ copyKeySignatureForKey / NSDictionaryM objectForKey: / CFStringCreateImmutableFunnel3 Code // Image download completion callback (dispatched to main queue by SDWebImage) if (finished && image) { UIImage *carPlayScaleImage = [UIImage imageWithCGImage:image.CGImage scale:[self getCarPlayDisplayScale] orientation:UIImageOrientationUp]; [item setImage:carPlayScaleImage]; // <-- hang here } Analysis Inside setImage:, the CarPlay framework creates a CPImageSet, which calls [UIImageAsset imageWithTraitCollection:] three times (at offsets +540, +344, +300 in CPImageSet initWithImage:treatmentBlock:). Each call performs a full CoreUI rendition key lookup via CUIMutableStructuredThemeStore, involving key signature computation, dictionary lookups, and string allocation. On iOS 26.4, these CoreUI operations appear significantly slower than previous iOS versions. When a CarPlay list loads ~20 items and images complete downloading in a short window, the serial execution of these setImage: calls on the main queue accumulates to a multi-second hang. Questions 1. Is this a known CoreUI performance regression in iOS 26.4? 2. Is there a recommended way to set images on CPListItem that avoids the heavy CPImageSet / UIImageAsset trait collection resolution path? 3. Are there any planned fixes for the CoreUI rendition lookup performance in upcoming iOS 26.x releases? Any guidance would be appreciated. We have also filed a Feedback report.