How iOS 10.3 broke iTunes File Sharing on Windows
With iOS 10.3, Apple started to roll out it's new file system, APFS. The delicate transition was largely successful, with very few bugs and no widespread systematic issues reported.
But lately, we've been receiving more and more complaints from Windows users that some files wouldn't transfer anymore from their computer to their iOS 10.3 iPhone or iPad: iTunes or iMazing seemed to copy the file just fine, but it would never appear in the app it was transferred to...
After some testing, we determined that only file names containing specific non-english characters were affected. Korean characters are especially often source of issues, but so are the Spanish ñ and many Scandinavian, French and Russian accented characters.
Who's affected?
Windows users who transfer files which contain specific non-english characters to their iOS 10.3 devices.
Here's a non exhaustive list of characters which will trigger the bug:
- 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)
Once again, this list isn't exhaustive. But it does give a rough idea of how widespread the issue is.
What to do if you're affected?
The issue will eventually get fixed by Apple, but for now, iMazing is as far as we know the only iOS file transfer tool to work around the bug. File transfer is 100% free in iMazing 2.2, so if you're experiencing the issue with iTunes, simply use iMazing instead - no registration required, 100% free file transfers to file sharing apps.
Download iMazing here: iMazing Download Page
Going further: why is this happening?
At the root of the problem lies handling of Unicode. Unicode is the standard used in computing to associate a numerical value to a specific character. The latin character A for instance is associated with U+41, and a with U+61.
Many languages feature composite characters. Let's go back to the Spanish ñ: it is composed of 2 characters, n and ̃ (Unicode U+110 and U+771). But it can also be written with a single Unicode value, U+241, which displays just the same character, ñ. When a character has 2 such Unicode representations, the composite one is referred to as decomposed and the other as precomposed.
Both macOS and iOS (before 10.3) use the HFS+ file system, which normalizes file names so that all characters are converted to their decomposed Unicode variant, if one exists. This prevents two identical looking file names from coexisting in the same folder.
In iOS 10.3, APFS does not normalize file names. And that's the heart of the issue: Windows doesn't normalize either, but actually favors precomposed variants, so that when a Windows user's ñ containing file name is transferred to an iOS 10.3 iPhone, the precomposed representation of the character is not normalized to its decomposed version. iOS 10.3's APFS handles that perfectly fine, but many Apple APIs which app developers leverage to interact with the file system were built with macOS in mind and do normalize file names, resulting in buggy behavior when listing non-normalized APFS files or accessing their attributes.
What's next?
Apple will fix this sooner or later. The issue is not trivial at all, as file name normalization is integrated in quite a few high level macOS and iOS file system APIs.
As the following Apple forums thread attests, Apple is aware of the issue and has acknowledged the bug: https://forums.developer.apple.com/thread/75428
In the meantime, we've updated iMazing so that file names are normalized before the files are transferred to iPhone or iPad, essentially reproducing macOS's handling of file names on Windows. We'll revert to non-normalized file names once the issue has been definitely fixed iOS side.
