3 ms·

This isn't talking about computers. It's talking about a tablet that already suffers from intentionally crippled capabilities. Apple has always prevented devel

This isn't talking about computers. It's talking about a tablet that already suffers from intentionally crippled capabilities. Apple has always prevented developers from accessing the I/O ports on iOS devices, and I don't expect that to end with the switch to USB. Apple even cripples the Bluetooth functionality on said devices. And then of course there's the removal of the headphone/microphone jack. That's what this jab means: Apple has deliberately hobbled its mobile devices from connecting to the world around them.

lloeki 3y ago
> This isn't talking about computers. It's talking about a tablet that already suffers from intentionally crippled capabilities. You're missing the point: how can one blame Apple for a missing feature that is nonexistent OOTB on any other non-Apple hardware out there? By using that specific feature as a metric of crippledness, all computing hardware - including, but not limited to, direct iPad competitors -, Apple or not, is crippled. Now, by itself it doesn't dismiss the argument that Apple cripples connectivity, only that not having that feature you suggested built in implies Apple specifically is crippling connectivity is a non-sequitur. That said, I would argue that the following does invalidate the argument: > and I don't expect that to end with the switch to USB† Looks to me that you can develop quite arbitrary things since iPadOS 16: https://developer.apple.com/documentation/driverkit/creating_drivers_for_ipados https://developer.apple.com/documentation/driverkit/creating... https://developer.apple.com/documentation/driverkit https://developer.apple.com/documentation/driverkit > Use the USBDriverKit framework to develop drivers for custom or non-class-compliant USB devices There's even PCIe in there (presumably thanks to Thunderbolt support?). Crazy thought: theoretically one could develop a driver for eGPU? > Use the PCIDriverKit framework to develop drivers that manage custom features on your Peripheral Component Interconnect (PCI) and PCI-Express hardware These software+hardware things don't develop themselves overnight, and I would consider the following to be a very reasonable deliberate reason for "hobbling" up til now: > The drivers you build with DriverKit run in user space, rather than as kernel extensions, which improves system stability and security. I would presume that DriverKit is how communication with the Orion capture card is developed - and that's assuming iPadOS does not support video capture class devices by itself. I think it does, at least to an extend, because this is a thing: https://www.macstories.net/stories/i-used-a-game-boy-camera-for-facetime-video-calls-in-ipados-17-and-it-was-glorious/ https://www.macstories.net/stories/i-used-a-game-boy-camera-... > The way UVC capture works on iPad Pro is simple: if a compatible camera is connected to the iPad, apps like FaceTime (and iPadOS 17 ones that have added support for the new API) will switch to it as the default video source > During my tests with UVC devices, I noticed that, just like the FaceTime app can pick up the Studio Display’s webcam when the iPad Pro is connected to it, so it can use other UVC devices’ input as its video source. To prove my point, I plugged a Steam Deck into the capture card, connected it to the iPad Pro, opened FaceTime, and there it was: Elden Ring on FaceTime. For DriverKit there is this notable caveat (emphasis mine): > The base DriverKit framework is available in macOS for Apple silicon and Intel-based Mac computers, and in iPadOS for devices with an M1 processor. The availability of family frameworks like USBDriverKit and AudioDriverKit varies by platform. Although I'm half-expecting that over time Mx SoCs with eventually trickle down the iPad tiers, ultimately dropping Ax, and providing iPadOS a single consistent hardware target. I would also venture that the iOS/iPadOS split had Mx for iPad as a big driver. † To be pedantic, it's a switch to USB-C (the plug), not USB (the protocol), which has always been there ever since Lightning. It's the SoC that matters here, not the plug.
- ShadowBanThis01 3y ago
  The DriverKit info is encouraging, certainly. I haven't explored it yet. But I can blame Apple independently for anything. Who cares what anyone else does? It may be an edge case, but not a non-sequitur for Apple's connectivity fears. Nobody should get a free pass for sucking only as much as anyone else. WTF kind of excuse is that?

lloeki 3y ago

> This isn't talking about computers. It's talking about a tablet that already suffers from intentionally crippled capabilities. You're missing the point: how can one blame Apple for a missing feature that is nonexistent OOTB on any other non-Apple hardware out there? By using that specific feature as a metric of crippledness, all computing hardware - including, but not limited to, direct iPad competitors -, Apple or not, is crippled. Now, by itself it doesn't dismiss the argument that Apple cripples connectivity, only that not having that feature you suggested built in implies Apple specifically is crippling connectivity is a non-sequitur. That said, I would argue that the following does invalidate the argument: > and I don't expect that to end with the switch to USB† Looks to me that you can develop quite arbitrary things since iPadOS 16: https://developer.apple.com/documentation/driverkit/creating_drivers_for_ipados https://developer.apple.com/documentation/driverkit/creating... https://developer.apple.com/documentation/driverkit https://developer.apple.com/documentation/driverkit > Use the USBDriverKit framework to develop drivers for custom or non-class-compliant USB devices There's even PCIe in there (presumably thanks to Thunderbolt support?). Crazy thought: theoretically one could develop a driver for eGPU? > Use the PCIDriverKit framework to develop drivers that manage custom features on your Peripheral Component Interconnect (PCI) and PCI-Express hardware These software+hardware things don't develop themselves overnight, and I would consider the following to be a very reasonable deliberate reason for "hobbling" up til now: > The drivers you build with DriverKit run in user space, rather than as kernel extensions, which improves system stability and security. I would presume that DriverKit is how communication with the Orion capture card is developed - and that's assuming iPadOS does not support video capture class devices by itself. I think it does, at least to an extend, because this is a thing: https://www.macstories.net/stories/i-used-a-game-boy-camera-for-facetime-video-calls-in-ipados-17-and-it-was-glorious/ https://www.macstories.net/stories/i-used-a-game-boy-camera-... > The way UVC capture works on iPad Pro is simple: if a compatible camera is connected to the iPad, apps like FaceTime (and iPadOS 17 ones that have added support for the new API) will switch to it as the default video source > During my tests with UVC devices, I noticed that, just like the FaceTime app can pick up the Studio Display’s webcam when the iPad Pro is connected to it, so it can use other UVC devices’ input as its video source. To prove my point, I plugged a Steam Deck into the capture card, connected it to the iPad Pro, opened FaceTime, and there it was: Elden Ring on FaceTime. For DriverKit there is this notable caveat (emphasis mine): > The base DriverKit framework is available in macOS for Apple silicon and Intel-based Mac computers, and in iPadOS for devices with an M1 processor. The availability of family frameworks like USBDriverKit and AudioDriverKit varies by platform. Although I'm half-expecting that over time Mx SoCs with eventually trickle down the iPad tiers, ultimately dropping Ax, and providing iPadOS a single consistent hardware target. I would also venture that the iOS/iPadOS split had Mx for iPad as a big driver. † To be pedantic, it's a switch to USB-C (the plug), not USB (the protocol), which has always been there ever since Lightning. It's the SoC that matters here, not the plug.

ShadowBanThis01 3y ago
The DriverKit info is encouraging, certainly. I haven't explored it yet. But I can blame Apple independently for anything. Who cares what anyone else does? It may be an edge case, but not a non-sequitur for Apple's connectivity fears. Nobody should get a free pass for sucking only as much as anyone else. WTF kind of excuse is that?