iPhone to USB C transfer Speed?

The vast majority of USB-C to USB-C cables (including the ones shipped with Apple devices) are rated for USB2.0 data speeds. Anything with higher speeds are specialty items. I don't think I have a USB-C 3.1 (or 3.2) cable. I do have a USB-C to USB micro-B drive cable, and that's 3.0 speeds (5 Gbit/sec). I also have a USB-C to HDMI cable, and that has to be at least 5 Mbit/sec in order to drive high-def video.
Yeah, it goes beyond that even since a USB-C connector does not tell you if the port is a DFP, UFP, or DRD or if the devices support DisplayPort Alt Mode.
 
My iPhone is usb c. Both the usb port and the phone seem capable of 5Gbps when the right cable is used.

I bought an Anker powerline II and after a try it worked. I think the image capture sw has limitations creating a list with 68k entries of data. It seems like almost a bug spreadsheet with thumbnails in one section. But doesn’t seem to use the ram it needs for all of it.

But the fast data cable seems to help too.

I wonder if iOS/macOS has an indexing service like Windows. A USB drive loaded with a lot of small files like pictures or documents will have very similar issue like you're describing and it seems like the limitation of the processing power available to the index service.
 
I wonder if iOS/macOS has an indexing service like Windows. A USB drive loaded with a lot of small files like pictures or documents will have very similar issue like you're describing and it seems like the limitation of the processing power available to the index service.
Thing is, this is a capture program that I think anticipates new or changing files. Even if the index was stored in the phone (I think it is, as the photo app on the phone has great searchability), it’s not natively transferred back and forth to the image capture sw. That sw is there to pull photos from a range of sources, files, scanners, cameras, etc.
 
I wonder if iOS/macOS has an indexing service like Windows. A USB drive loaded with a lot of small files like pictures or documents will have very similar issue like you're describing and it seems like the limitation of the processing power available to the index service.

Both do, called Spotlight, and it powers a lot of functions.

It will try to index every volume, unless the volume is blacklisted, with a marker sort of like robots.txt. If you've ever come across a flash drive that a Mac OS user has mounted on their system, then see some oddly named files or folders, including one named ".Spotlight-V100" when mounted on Windows, that's where it originates from.

However, I don't think that's the issue here.

The Mac doesn't treat iOS devices like mountable volumes, or a mass storage device like a Windows machine does. The file system is hidden, and only specific apps like Image Capture, or iTunes, will interact with the device, not the Finder GUI/file manager.

Image Capture is one of those native OS bundled utility apps that performs some handy basic functions, like Notepad or Paint does on Windows. Functional, but basic. Once written, they rarely see any further development, or enhancements, other than rudimentary compatibility checks on newer versions of the OS.

The IC app serves not only to provide an interface to extract media from devices, but also as a front end for image scanners.

I rarely task it with extracting more than 100 or so images at once, from my phone with fewer than 6000 images stored, and it's still not a performant program.

I don't think it's reading from the volume index database, but is trying to build a temporary cache each time it reads a device, and is choking on the high number of files in the OP's phone.

A quick check of the copyright shows that it dates from 2000, when OS X first shipped, so the bones of the app were written at a time when iOS devices didn't exist, and the app's function was to pull low res images from digital cameras with relatively small storage capacities, not the gigabytes worth of data on a modern smart phone.

It probably hasn't been updated to handle such amounts of data, and under most use cases, probably doesn't have to. A lot of Mac users have probably never even launched the app, and rely on other methods, like the Photos app, to manage their pictures. It's not a work flow a common user will utilize.

That's why I suggested an alternative, like iMazing, if the preferred method is to do a hard wired transfer.
 
Both do, called Spotlight, and it powers a lot of functions.

It will try to index every volume, unless the volume is blacklisted, with a marker sort of like robots.txt. If you've ever come across a flash drive that a Mac OS user has mounted on their system, then see some oddly named files or folders, including one named ".Spotlight-V100" when mounted on Windows, that's where it originates from.

However, I don't think that's the issue here.

The Mac doesn't treat iOS devices like mountable volumes, or a mass storage device like a Windows machine does. The file system is hidden, and only specific apps like Image Capture, or iTunes, will interact with the device, not the Finder GUI/file manager.

Image Capture is one of those native OS bundled utility apps that performs some handy basic functions, like Notepad or Paint does on Windows. Functional, but basic. Once written, they rarely see any further development, or enhancements, other than rudimentary compatibility checks on newer versions of the OS.

The IC app serves not only to provide an interface to extract media from devices, but also as a front end for image scanners.

I rarely task it with extracting more than 100 or so images at once, from my phone with fewer than 6000 images stored, and it's still not a performant program.

I don't think it's reading from the volume index database, but is trying to build a temporary cache each time it reads a device, and is choking on the high number of files in the OP's phone.

A quick check of the copyright shows that it dates from 2000, when OS X first shipped, so the bones of the app were written at a time when iOS devices didn't exist, and the app's function was to pull low res images from digital cameras with relatively small storage capacities, not the gigabytes worth of data on a modern smart phone.

It probably hasn't been updated to handle such amounts of data, and under most use cases, probably doesn't have to. A lot of Mac users have probably never even launched the app, and rely on other methods, like the Photos app, to manage their pictures. It's not a work flow a common user will utilize.

That's why I suggested an alternative, like iMazing, if the preferred method is to do a hard wired transfer.

It's kind of difficult to use, but I've been able to access an iPhone's photos directly with a Chromebook or Windows machine. There are some settings that need to be made for that.

Finder has the ability to do drag and drop for video files that go the the TV app as "home videos". There's also a way to specify photos on the host Mac to sync and load on the iPhone/iPad. It's kind of clunky though.

I save my photos by dragging them using Image Capture. The only issue I've had is that sometimes HEIC isn't recognized by some websites or services and I need to convert to JPEG.
 
Back
Top