Summary: Starting from iPadOS 26.4, the maximum memory available to a single app has been reduced from approximately 6GB to 3GB on an 8GB iPad. This change persists in iPadOS 26.5 and has not been addressed. This breaks core functionality of memory-intensive applications such as 3D scanning apps that require large amounts of RAM to process models. Device: iPad with 8GB RAM Affected versions: iPadOS 26.4, iPadOS 26.5 Working version: iPadOS 26.0 / 26.1 / 26.2 / 26.3 Measured Data: iPadOS 26.0–26.3: App available memory ≈ 6GB (75% of total RAM) iPadOS 26.4–26.5: App available memory ≈ 3GB (37.5% of total RAM) Measurement method: Apple system API Impact: This is a regression, not expected behavior. The available memory per app has been cut by 50% without any official documentation or release notes mentioning this change. As a result, our 3D scanning application crashes immediately when attempting to process 3D models on iPadOS 26.4 and later. The app requires substantial RAM to load and process 3D model data. With only 3GB available, memory allocation fails during model processing, causing the app to crash (EXC_RESOURCE / OOM kill). This core functionality was working correctly on iPadOS 26.3 and earlier with the same device and same app binary. This regression makes our app's primary feature completely unusable for all users on iPadOS 26.4+. Steps to Reproduce: On an 8GB iPad, install iPadOS 26.0 Measure available app memory using Apple system API Upgrade to iPadOS 26.4 or 26.5 Measure available app memory again Observe: available memory drops from ~6GB to ~3GB Expected Result: Available memory per app should remain consistent across minor OS updates, or any changes should be documented. Actual Result: Available memory per app dropped by 50% starting in iPadOS 26.4, with no documentation of this change. Additional Notes: Disabling Apple Intelligence does not resolve the issue This issue was not fixed in iPadOS 26.5 Other developers have reported increased crash rates starting in iPadOS 26.4 (Apple Developer Forums)

Since iPadOS 26.1 I notice a new annoying bug when changing the dark mode option of the system. The appearance of the UI changes, but no longer for view controllers which are presented as Popover. For these view controllers the method "traitCollectionDidChange()" is still called (though sometimes with a very large delay), but checking the traitCollection property of the view controller in there does no longer return the correct appearance (which is probably why the visual appearance of the popover doesn't change anymore). So if the dark mode was just switched on, traitCollectionDidChange() is called, but the "traitCollection.userInterfaceStyle" property still tells me that the system is in normal mode. More concrete, traitCollection.userInterfaceStyle seems to be set correctly only(!) when opening the popover, and while the popover is open, it is never updated anymore when the dark mode changes. This is also visible in the standard Apps of the iPad, like the Apple Maps App: just tap on the "map" icon at the top right to open the "Map mode" view. While the view is open, change the dark mode. All of the Maps App will change its appearance, with the exception of this "Map mode" view. Does anyone know an easy workaround? Or do I really need to manually change the colors for all popup view controllers whenever the dark mode changes? Using dynamic UIColors won't help, because these rely on the "userInterfaceStyle" property, and this is no longer correct. Bugreport: FB20928471

I have encountered the following issue on iPadOS. Has anyone experienced this issue or reported it before? Steps to Reproduce Enable Windowed Apps mode in Settings. Launch the Settings app and another app (App X), and display both in windowed mode. Use the Settings app to completely cover App X (App X becomes inactive at this point). From the Settings app, enable Full Screen Apps mode. Bring App X to the foreground. Expected Result App X becomes active when brought to the foreground. Actual Result Even after bringing App X to the foreground, it immediately becomes inactive. The issue persists even if App X is restarted. To resolve the issue, it is necessary to either restart the iPad or switch back to Windowed Apps mode. Verified OS Versions iPadOS 26.5: Reproducible iPadOS 26.4.2: Reproducible iPadOS 26.2: Not reproducible iPadOS 26.0.1: Not reproducible Additional Information According to the console logs, App X appears to remain inactive because the deactivation reason "sceneOverlap" persists.

I'm trying to get the count of how many windows an iPadOS app has 'open' (open from the user's perspective in the app switcher). This is for the sake of determining whether I should show or hide a button that takes action on every window (if there is only 1 window, the button will be hidden). According to the documentation the proper API for this is this property on UIApplication: // All of the representations that currently have connected UIScene instances or had their sessions persisted by the system (ex: visible in iOS' switcher) @property(nonatomic, readonly) NSSet<UISceneSession *> *openSessions So I print the count (only sessions with role UIWindowSceneSessionRoleApplication) when scenes are added/removed etc via appropriate lifecycle notifications like -sceneDidDisconnect: -sceneDidBecomeActive: and so forth. What I noticed is when I add a new window scene, the count increases by one so cool, that works. But when I kill a window in the App switcher the count does not decrease. I can end up in a situation where the app has only 1 window in the app switcher but the count prints 8, so this is wrong. So am I using the wrong API? How can I just get scene count in the app switcher? The documentation makes it seem like using 'connectedScenes' for this would be wrong because that property is not supposed to include 'archived' scenes in the app switcher (or is it?)? I do know I can't take action on an archived scene 'yet' but I would still show the button because whether or not the scene is archived in the app switcher is a fact that remains hidden from the user. My code will take care of that later after state restoration. Is iPadOS 26 potentially keeping scene sessions open for too long? Is there a good way to reliably detect how many scenes I have in the app switcher? Is a scene session explicitly killed by the user supposed to remain the .openSessions set? I am testing on the Simulator FWIW. iPad 26.5.

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?

Hi everyon. I‘d like to ask If there’s a way of including info.plist into swift playground on the iPad. I’m currently developing a daw on the iPad, I can see and use Apple’s auv3 plugins but can’t see third party apps like fab filter etc installed on the iPad. I think it’s needs inter app or auv3 entitlement. Is there a work around? I have attached my code for auv3 section. if anyone is interested , here is a video of my progress so far https://youtu.be/_2-L3oowfd0?si=cbr_9vYc3DOXV3R1 AUV3Diagnostic.swift

Markup Tool: Support for persistent tool presets (color, stroke, fill settings) I use Markup heavily for work — up to 20 images per day, always with the same settings: red arrow or rectangle, no fill, specific stroke width. The problem has two parts: Part 1 – Markup resets everything: Every time Markup is opened, all settings reset: tool, color, fill, stroke width. This means 3–4 manual steps per image, adding up to 80 unnecessary interactions per day. Part 2 – The default red is unusable: The red in Apple’s color palette is muted and too pale for clear, high-contrast annotations. I have to open the color wheel every single time to manually select a proper, vivid red. The copy/duplicate workaround only helps within one image — as soon as a new photo or screenshot is opened, everything starts over from scratch. Markup has no memory between different images. Switching to a third-party annotation app is not a solution — the entire advantage of Markup is its native integration directly within the Photos app, without switching apps. And Markup cannot be configured in depth through Shortcuts either — color, fill, and stroke width are not controllable there. The attached images: Image 1 shows the entry point in the Photos app. Image 2 shows Markup open with the current color palette. The blue-outlined fields do not indicate colors to be replaced — they mark the position where personally configured tool presets should appear: not individual colors, but fully pre-configured tools with color, stroke width, and fill setting already saved, ready to use with a single tap. My suggestion: Tool presets — configure once, saved permanently, available directly in the Markup toolbar. No need to re-configure color, fill, or stroke width for every new image. iOS already remembers last-used settings in many areas: camera mode, emojis, colors in Notes, Pages, and Keynote. Markup behaves as if it’s being opened for the first time, every time. This inconsistency costs me measurable time every single day.

Howdy! I'm in the R&amp;D phase of this project and I need help. I can't find any sources that verify what I want to do is even possible. I need to connect an iPhone or iPad using a USB cord to an external device which will transfer files to the iPhone or iPad. I have an app already made which can organize the files and whatever else I need to do (app is from a similar project). I'll refer to this device as Alfred (for poops and giggles) The plan (if possible) is for Alfred to recognize my app and use its documents folder as the destination of the transfer. The iDevice doesn't have to communicate with Alfred, but that would be a bonus. I don't want Alfred to run on an SOC. My goal is to have it be as simple as possible. No OS, just firmware. If the only way to interact with Apple Devices is Bluetooth or Wifi than so be it. If Matter or Thread could be utilized I wouldn't be apposed. Any help with this project would be greatly appreciated. Thanks in advance.

Our Flutter app has been rejected by App Review 4 times with this description: "Login screen cleared the email and password fields when we attempted to enter the demo account details, preventing us from logging in." Review environment: Device: iPad Air 11-inch (M3) OS: iPadOS 26.4.2 Flutter version: 3.41.4 State management: GetX We cannot reproduce this on: Real iPhone (iOS 18.x) — works fine iPad simulator (iPadOS 26.3.1) — works fine Our TextEditingControllers are created inside a GetX controller, not inside build(), so they survive widget rebuilds. Questions: Has anyone seen text fields clearing or not retaining input specifically on iPad with iPadOS 26? Are there any known Flutter issues with text input on iPadOS 26 that could cause this? Is there anything different about how iPad handles text input vs iPhone that we should be aware of? Any help appreciated — this is blocking our App Store approval.

Since iOS26, I've been running into an issue with using a NavigationStack with .searchSuggestions, and using searchable with placement: .navigationBarDrawer(displayMode: .always) With this, the search is activated and search suggestions list is displayed, but tapping on the search suggestions dismisses the whole search control without doing selecting the search suggestion item. This doesn't happen on iPhone, and doesn't happen on iPadOS 18.5 or below. And removing the 'placement' argument also fixes the issue. NavigationStack { List { /// ... } .searchable( text: $searchText, tokens: $searchTokens, isPresented: $isSearchPresented, placement: .navigationBarDrawer(displayMode: .always), prompt: "Search timestamps" ) { token in Label(token.title, systemImage: token.systemImage) } .searchSuggestions { ForEach(suggestedTokens) { token in Label(token.title, systemImage: token.systemImage) .searchCompletion(token) } } .toolbar { ToolbarItem { Button(action: addItem) { Label("Add Item", systemImage: "plus") } } } } I have a test sample app with this, and created FB22639453 The same problem happens in UIKit as well, when using UISearchController with UINavigationItems' searchController.

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)

Attempts to create Swift Playgrounds from the built-in templates fail. Clicking the “Get” button on these templates appears to download something, but it changes back into a “Get” button afterwards without creating a playground. Furthermore, the Swift versions of the templates seem to be behind; it shows Swift 5.8 and Swift 5.9 editions whereas it should be Swift 6.x Steps to Reproduce Start the Swift Playground app (the standalone app, not the Xcode one, on macOS or iPadOS). Select “Learn to Code” Choose the “Get Started With Code” template (or any other template will do). Click the Get button. Wait until the Get button becomes a circular progress indicator. Expected Results A new Swift Playground should be created from the selected template. Actual Results The Get button changes into a circular progress indicator and then changes back. No Playground gets created. Versions Swift Playground 4.7 (2088) macOS 26.4.1 (25E253) iPadOS 26.4.2

What I am trying to do I am building a browser-based exam proctoring platform that runs in Safari and Chrome on iPad. I need to detect when a candidate opens another app or browser tab in Slide Over (the floating panel) while the exam is running in the background. This is a pure web app - no native wrapper, no MDM. What I've already tried I tried listening to window blur and focus events neither fires when Slide Over is triggered on Chrome. I tried document.visibilitychange - same result, it never fires during Slide Over. I tried the resize event but it is completely inconsistent on iPadOS Chrome. For Split View I am computing the ratio of window.innerWidth to window.screen.width and flagging below 0.80 as a likely split. That works. But Slide Over doesn't change the viewport at all - the exam tab stays full width in the background. So my ratio check is completely blind to it. My question Is there any JavaScript API, browser event, visualViewport property, or any other web-accessible signal that fires or changes when iPadOS enters Slide Over mode — specifically from a page running inside Safari or Chrome (WKWebView)? Even an indirect signal would help. If there's truly no way to detect this from a web page today, is there a recommended pattern or workaround that others have used? I've seen the interaction heartbeat approach (flagging when no pointerdown arrives for N seconds) but that's too noisy for an exam context where a candidate may be reading a long question.

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?

We are seeing an issue after updating iPads to iPadOS 26.4 where cellular service is lost until network settings are reset. Environment: Devices managed via Apple Business Manager and Microsoft Intune Carrier: Verizon Confirmed affected devices: iPad (9th generation) eSIM Behavior: After update, device shows no cellular service No prompt to re-activate or re-add the cellular plan The plan appears to still be present on the device Workaround observed: Resetting Network Settings restores service Notes: This does not appear to be a provisioning issue (no need to re-add eSIM) Behavior suggests the cellular/eSIM state may not be initializing correctly after update Toggling Cellular or Airplane mode has not yet been tested for service restoration. We have not yet confirmed whether devices using a physical SIM are affected Still gathering data on scope across additional iPad models Additional observation: We have not observed this behavior on iPhones (e.g., iPhone 16 on iOS 26.4 with LTE remains unaffected) Has anyone else observed similar behavior on iPadOS 26.4, particularly on managed devices or eSIM configurations?

My iPadOS app can open .xml files. In my XMLApp.swift, I hooked up a: var body: some Scene { WindowGroup(id: "main") { .commands CommandGroup(replacing: .newItem) { ... Button(.openDot) { openXMLFile() } ... Next, I entered a new UTImportedTypeDeclarations / UTExportedTypeDeclarations in Project Settings -> Target -> Info -> Document Types, Exported Type Identifiers, Imported Type Identifiers, for the XML file-type: ... <key>UTImportedTypeDeclarations</key> <array> <dict> <key>UTTypeConformsTo</key> <array> <string>public.data</string> <string>public.xml</string> <string>public.content</string> </array> ... As soon as I do that, Xcode creates an additional Open... menu entry all the way at the bottom of the File menu. I cannot get rid of this additional menu entry. Its state is disabled (grayed out). I have my own Open (per the code above), which also responds to ⌘ - O. My menu entry works fine, as long as I disable the same keyboard shortcut so they don't collide. The extra Open entry is also displayed on the matching iPadOS simulator. From the same codebase, the Open is not displayed on the Mac (targeting macOS, not Catalyst). On macOS, only my Open is in the File menu, as expected. Why is there a duplicate Open menu entry and how do I get rid of it?

Hi everyone, I’m troubleshooting a WiFi issue affecting some iPads on a WPA2-PSK network with captive portal. Problem: The iPad shows “incorrect password” when connecting to the SSID. The password is correct (validated with multiple devices). Other devices connect normally. After entering the password, the captive portal should appear, but it never does. What we see on the network side (Cisco WLC): Client associates successfully. RADIUS authentication is successful. Failure occurs during the 4-way handshake: Received EAPOL-key M2 with invalid MIC This causes deauthentication, which the iPad reports as “incorrect password”. From the iPad sysdiagnose (Entity_Join file): Entity_2026-04-15_10_23_39.529_Join Entity_2026-04-15_10_23_39.529_Join.csv Questions: Does anyone know how to interpret: reason status subReason values in Entity_Join logs? Specifically: What does reason = -3925 mean? What does reason = 1 mean? What does subreason = 524288 mean? Any insight into these codes or similar experiences would be really helpful. Thanks!

[Submitted as FB22200608] With Increase Contrast turned on, the selected row highlight in a List behaves inconsistently between light and dark appearance on iPad. In light appearance the blue selection highlight correctly becomes darker, but in dark appearance it becomes lighter instead. The text contrast ratio drops from about 3:1 to about 1.5:1, well below accessibility guidelines. This reproduces both in the simulator and on a physical device. The sample uses a standard SwiftUI List inside NavigationSplitView with built-in selection styling. No custom colors or styling are applied. REPRO STEPS Create a new Multiplatform project. Replace ContentView with code below. Build and run on iPad. Select an item in the list. Turn on Dark appearance (Cmd-Shift-A in Simulator). Turn on Increase Contrast (Cmd-Control-Shift-A in Simulator). Observe the selected row highlight. ACTUAL In light appearance, the blue selection highlight becomes darker when Increase Contrast is on, improving contrast as expected. In dark appearance, the blue selection highlight becomes lighter when Increase Contrast is on, reducing contrast between the selection background and the white text. EXPECTED Increase Contrast should consistently increase contrast. In dark appearance, the selection highlight should become darker—or otherwise increase contrast with the foreground text—not lighter. SAMPLE CODE struct ContentView: View { @State private var selection: String? var body: some View { NavigationSplitView { Text("Sidebar") } content: { List(selection: $selection) { Text("Item One") .tag("One") Text("Item Two") .tag("Two") } } detail: { if let selection { Text(selection) } else { Text("Select an item") } } } } SCREEN RECORDING CONTACTS The Contacts app behaves correctly. When Increase Contrast is turned on, the selection blue becomes darker, improving contrast. PASSWORDS The Passwords app, however, exhibits the issue. With Increase Contrast turned on, the selection blue becomes lighter instead of darker, reducing contrast.

Note On a Mac with Xcode installed, or on an iPad with Swift Playgrounds, you can open this chapter as a playground. Playgrounds allow you to edit the code listings and see the results immediately. (Note in page 3) (I would like to open the chapter or book: Swift Programming Language in Swift Playground on iPad) https://books.apple.com/ve/book/the-swift-programming-language-swift-5-7-beta/id1002622538?l=en-GB Best regards

After updating my Xcode to the latest, I am unable to download an installed app container from the Xcode Devices screen. This currently works with older versions of Xcode with the same app on the same iPad. This worked with older versions of Xcode on the same MacBook as well (including the Xcode 26 beta before updating to the official release yesterday) The specified file could not be transferred. Domain: com.apple.dt.CoreDeviceError Code: 7000 User Info: { DVTErrorCreationDateKey = "2025-09-18 20:31:01 +0000"; NSURL = "file:///Users/thomsk2/Desktop/com.test.polarisdev%202025-09-18%2015:30.53.744.xcappdata/AppData/Library/Caches/"; } The specified file could not be transferred. Domain: com.apple.dt.CoreDeviceError Code: 7000 User Info: { NSURL = "file:///Users/thomsk2/Desktop/com.test.polarisdev%202025-09-18%2015:30.53.744.xcappdata/AppData/Library/Caches/"; } Failed to perform I/O operations. Domain: com.apple.dt.remoteservices.error Code: 11001 Failure Reason: Cannot open destination file /Users/thomsk2/Desktop/com.test.polarisdev 2025-09-18 15:30.53.744.xcappdata/AppData/Library/Caches/com.apple.dyld/standaloneapp.ios.dyld4: Permission denied System Information macOS Version 15.6.1 (Build 24G90) Xcode 26.0 (24228) (Build 17A324) Timestamp: 2025-09-18T15:31:01-05:00