There’s a Bug in File Sharing Between Windows and iOS 10.3 – Here’s a Workaround

2 minute read
| Deep Dive

When iOS 10.3 was released, the iPhone and iPad began using a new file system, Apple File System (APFS). The transition seemed to go just fine, without any widespread panic or problems. However, complaints are starting to trickle in from Windows users that file sharing is occasionally broken between their computers and their iOS 10.3 iPhone or iPad. There is a workaround—read on for more.

File Sharing between Windows and iOS 10.3 is borked

Computer and iPhone code is tricky, so it’s not surprising that there’s a bug in file sharing between Windows and iOS 10.3 (Image Credit: Markus Spiske)

The Problem With File Sharing Between Windows and iOS 10.3, in a Nutshell

The problem with file sharing is occurring when certain Unicode characters are used in the file name. On the Apple Developer Forums, a thread from early April relates to a problem with Korean or Japanese file names. The files appear to transfer without any problems, but do not actually appear on the iOS device.

Developers for iMazing found more non-English characters which trigger the APFS bug in file sharing between Windows and iOS 10.3. Some, but not all, of these characters include:

  • The Spanish ñ (U+241)
  • Many Korean Hangul characters such as (U+54620)
  • Accented Russian Cyrillic characters, Ѝ or Ё for example (U+1037 and U+1025)
  • Accented French characters like é or à (U+233 and U+224)
  • The Scandinavian Å (U+197)

APFS Isn’t Normalizing the File Names

Computer software uses Unicode, a standard that associates numerical values to characters. This is especially important for characters outside the English alphabet. For example, Unicode expresses the Latin character A with U+41, and its lower case variant a with U+61. Characters like the Spanish ñ are composite, or precomposed, characters. Unicode represents that one, in particular, with an n (U+110) and ~ (U+771).

On the other hand, the single Unicode value U+241, a decomposed character, will display also display the ñ.

Both macOS and versions of iOS prior to 10.3 use the HFS+ file system. HFS+ normalizes file names – it converts all characters in a file name to their decomposed Unicode variant, if one exists. That way, you don’t end up with two identical-looking file names in the same folder.

Windows’ file system, NTFS, actually favors precomposed variants and doesn’t normalize file names. APFS doesn’t normalize the file names, either. So what ends up happening is that when a Windows user transfers a file containing one of the offending precomposed characters to their iPhone through iTunes, nothing ever normalizes that character to its decomposed variant.

That Would Be Fine, but …

APFS can recognize both decomposed and precomposed characters just fine. The problem lies within the developer Application Program Interfaces (APIs) used to interact with the file system. Apple built those APIs with macOS in mind, and the code normalizes file names. That seems to result in buggy behavior when trying to list non-normalized APFS files or access their attributes.

Okay, So What Do I Do?

Apple has acknowledged the bug, and will eventually fix it. In the meantime, Windows users who need to transfer files to their iOS devices from a PC actually do have an option that works. The developers at iMazing have updated the app so that it normalizes file names before transferring those files to the iPhone or iPad. Essentially, iMazing reproduces how macOS handles the file names. Until Apple comes out with its own fix, Windows users can make use of iMazing for their file transfer needs.

Note that DigiDNA does charge for iMazing, but you can download a limited free trial. However, transferring files between the computer and the iOS device is a feature that has always been unlimited in the iMazing trial, so you don’t need to buy a license to take advantage of it. You can download iMazing for Windows directly from DigiDNA’s website for the app. The developers say they will revert to non-normalized file names once Apple has fixed the issue on their end.

Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

1 Comment
Oldest Most Voted
Inline Feedbacks
View all comments
John Kheit

Dude, you are the man. I love your deep dives. Thanks for the heads up. I’ve just come up on this on Synology. If you move things to their encrypted file system, you can only have like 140 characters instead of 255. Of course, you have to fix this by hand. And find any weird characters by hand. Why the operating system in both cases doesn’t give you an option to rename things to comply with the target file system on the fly is beyond me… Like medieval times.