iPadOS 17.7.7

The adaptable gray colors are only supported on iOS, iPadOS, visionOS and Mac Catalyst. If you'd like us to consider adding the API functionality to tvOS, please file an enhancement request using Feedback Assistant. Once you file the request, please post the FB number here. If you're not familiar with how to file enhancement requests, take a look at Bug Reporting: How and Why?

Update: While the issue remains highly reproducible on simulator, it turns out that on physical iPadOS 26 devices, an external keyboard needs to be connected. On my physical iPad, I was unable to reproduce the issue until I connected my Mac's Magic Keyboard to the iPad (Magic Keyboard model A1644). From there it has the same strange behavior being observed on simulator. Based on our app's user reports, issue is reproducible with other keyboards as well such as the smart keyboards. My guess as to why it is highly reproducible on an iPadOS 26 simulator is that from the simulator's perspective, the Mac keyboard is an external keyboard. I think it would still be helpful to get an update on this as it is not uncommon to have a wireless or external keyboard for iPad, and this is resulting in a bad experience.

I just had a chance to test this under iPadOS 26.1 beta 2. Great news - if the primaryBackgroundStyle property of the split view is set to .none then we get back the old style tile layout and none of the content of the other columns appear behind the primary column. Thank you. If the primaryBackgroundStyle is set to .sidebar, the primary column is inset a bit as it has been since iPadOS 26.0 (and that's fine for a sidebar). But there is still some unwanted extension of content from the other columns behind the primary column. It's not nearly as bad as iPadOS 26.0. Running the app I used for the screenshot in the first post of this thread now results in just the background color of the selected row appearing on the far left. The section headers do not extend to the far left any more. Here's how it looks now with primaryBackgroundStyle = .none with iPadOS 26.1 beta 2: Here's how it looks now with primaryBackgroundStyle = .sidebar with iPadOS 26.1 beta 2 (note the row

FYI - none of these issues have been resolved as of iOS/iPadOS 26.1 beta 2. Dear Apple, please fix all of these scope button issues. They are impacting my app. If you do not intend to fix these then you should mark the APIs as deprecated and suggest an alternate solution.

I duped this one as well (FB20547079 for iPadOS 26, FB20376452 for macCatalyst 26.1, and FB20376479 for iOS 26.1). The problem still exists in beta 2.

When we tried using this feature, we were not able to get it to work on iOS 26. We stumbled upon this ticket (https://developer.apple.com/forums/thread/797538?answerId=854825022#854825022) in the Apple Developer forum, in which possibly an Apple engineer claims it is supported ONLY for iPadOS 26. That engineer would be me, and yes, what I said there is correct. Background GPU access is currently only available on iPads. 96% of the users are on iPhone (compared to iPad), and if we refer to the official documentation above, it claims that this feature should work on iOS 26. What the documentation says is that the APIs themselves are available on iOS and iPadOS and that background GPU access is not available on all devices, both of which are true. This both simplifies the implementation on both platforms and allows for future API evolution without requiring major API revision. This is the same basic pattern most of our APIs use when functionality is only available on some hardware. __ Kevin Ell

It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits. we do not wish to create a driver visible by the entire system. Well, that certainly simplifies things. For example, it makes an EA-based solution feasible (although the EA-based solution still requires MFi hardware). Are there any APIs that give an application access to a raw USB interface … in userspace? Not on iOS. On macOS you can do this using the I/O Kit API [1]. And on iPadOS you can achieve similar functionality using DriverKit. But iOS has neither of those options. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] You can also do it using the KPI, but that just complicates things unnecessarily.

You don’t have a lot of options in this space. [quote='802640021, nam-common, /thread/802640, /profile/nam-common'] we have been informed DriverKit is only available on iPadOS, not iOS. [/quote] That’s correct. [quote='802640021, nam-common, /thread/802640, /profile/nam-common'] First being IOkit [/quote] macOS is the only platform that supports I/O Kit drivers [1]. [quote='802640021, nam-common, /thread/802640, /profile/nam-common'] the second being External Accessory Session (EASession). [/quote] There are two problems here: External Accessory framework can only talk to accessories that are built under the aegis of the MFi programme. If you have an existing accessory that wasn’t built that way, you can’t talk to it with EA. External Accessory framework allows apps to talk to hardware. It doesn’t let you publish a network driver that’s visible to the rest of the system. I think your best option here is to work with your chip vendor to update their firmware to work with iOS’s built-in USB Ethernet dr

Although the code may not be using the best or latest practices, that is not the main concern. It seems that most methods that modify the layout of the tableView, either directly or indirectly, results in the strange auto scrolling behavior. Or maybe the issue is triggered when the tableView does not fill the entire view. The mechanics of the bug are not fully known. The conditions behind this do not seem to make sense. navigationControllerWithVC.navigationBar.isTranslucent = false for example, may not be using best practices, but why does that cause the table to start auto scrolling when being reloaded? The same can be asked for the safeArea top anchor scenario in the original code. Disregarding all of the navigation bar stuff, consider another case where we may want to present a label or some other content above the tableView. If the setupTableView() function is replaced with the code below, this will also trigger the auto scrolling issue: func setupTableViewWithLabelAbove() { tableView.delegate = self tabl