iPadOS 17.7.7

I'm developing a DriverKit USB driver for iPadOS. So, my first and strongest recommendation is that you shift your development environment from iPadOS to macOS, even if you never intend to ship on macOS. I have a more extended post on this here, but the basic summary is that, in my experience, the higher friction, lower visibility, and lack of critical investigator tools [1] on iPadOS mean that you'll end up wasting far more time trying to figure out “what’s happening on iPadOS than you saved by not getting a minimal macOS implementation working. [1] In particular, I consider IORegistryExplorer to be an absolutely critical tool for driver developers. See this forum post for download instructions and general guidance on using it. That leads to here: Does iPadOS allow third-party DriverKit extensions to access vendor-class (0xFF) USB devices? That is, in iPadOS, is there a way for a third-party DriverKit extension to access IOUSBHostInterface objects for ven

[quote='873863022, DTS Engineer, /thread/813853?answerId=873863022#873863022'] may I ask you to file a bug with that project? [/quote] Before you do that, I’d like to clarify what you mean by this: [quote='813853021, OC_s, /thread/813853, /profile/OC_s'] How do I determine the real values? [/quote] What specific information are you looking for here? And what do you plan to do with that information? This matters because Mac Catalyst is returning values that make sense in the iOS-ish environment that’s expected by such apps. It is possible to get ‘real’ values, but the best way to do that depends on your specific setup. For example, the systemName property is uninteresting in a Mac Catalyst app because the real system name is macOS. So you can do this [1]: let systemName: String #if targetEnvironment(macCatalyst) systemName = macOS #else systemName = device.systemName #endif However, that’s just one of these properties. The best path for the other properties varies based your the specific property and your ulti

Thanks again :) Test please at your leisure at your side this project: https://ocs.cz/CD/catalyst_test.zip Note: my application is intended primarily for macOS, should be able to run also with lower priority, essentially as a side-effect, on iPadOS. Thus I believe “Catalyst” to be a much better destination than “Designed for iPad”, or am I wrong here?

SwiftUI.TextEditor doesn't currently provide a way to scroll to a certain position within its content. To do so, consider using UITextView + UIViewRepresentative or NSTextView + NSViewRepresentative, which provide the scrollRangeToVisible(_:) method here and here. SwiftUI.TextEditor should automatically scroll to make the cursor visible (or avoid the keyboard on iOS / iPadOS) though. If you don't see that happening, I'd be interested in taking a closer look. Best, —— Ziqiao Chen  Worldwide Developer Relations.

When changing Bluetooth settings from the system Settings app without using multitasking, the app does not terminate but instead logs the user out. However, when changing Bluetooth settings while using multitasking, the app terminates completely. I'm not sure what you're actually referring to here. What do you mean by while using multitasking? Are you talking about iPadOS's multitasking interface? Or something else entirely? In terms of the question here: Whether there is any system behavior that causes the app to refresh or restart when Bluetooth settings are changed No, the system doesn't do anything special/unusual with this setting. Generally speaking I wouldn't expect toggling the bluetooth state to have any effect on apps, however, that actual behavior would depend on the details of the apps involved (particularly memory use). __ Kevin Elliott DTS Engineer, CoreOS/Hardware

If this behavior is still observed in the latest iOS or iPadOS version 26.2 please file a bug report about this. Bug Reporting: How and Why? has tips on creating a successful bug report.