やらかしたので反省文

iOS10.3にてファイルシステムが HFS+からAPFSに強制変換されましたが
濁点など含むファイル名にてfopenなどの下位関数にアクセスする際
Stringなどからconst char* への変換は
UTF8String ではなく fileSystemRepresentation を使いましょう。

ざくっと調べた

検証コードを整えるのが面倒なので結果だけ

合成された普通のもの NFC : "だ" 3080 (1文字は1文字)
正規化分解NFD : "だ" 305F 3099 (濁点分割して検索なんかも楽しそうよね)

HFS+でもAPFSでもファイル名は正規化分割NFDされて保存される（前からそう)

HFS+では分割されていてもいなくても(NFD,NFC)同じNFDファイル名にアクセスできる、おそらくどこかでうまく処理してくれていたのだろう

APFSではfopenなどの下位関数はNFCそのままにアクセスされる、変換処理してくれない (ここが問題）

よってAPFSではNFC,NFDのファイル名が2つできたり、NFC名でアクセスした際ファイルが無いなどの問題が起こる
(これでNFCなファイルが出来るとbackupなんかでも問題起きたりするとか)

NSFileManagerなどの上位関数でのファイル処理は問題ない
(objc的に書いているけれども)swiftも問題は同じ

対処としては、ファイル名などは普通StringなりURLなりで持っていると思われ、
fopenなどの低位関数にてアクセスする際のファイル名は const char* に変換することになると思われるので、
このStringなりからconst char*への変換をUTF8StringではなくfileSystemRepresentation (これはファイルシステムに対応してNFDなりの処理をしてくれる)で行う。

CFStringNormalize((CFMutableStringRef)なにか, kCFStringNormalizationFormD);
でもNFD変換できるが、ここは素直にファイル系のAPIに従おう。

NSURLのメソッドなのでNSStringとかからなら
[[NSURL fileURLWithPath:self] fileSystemRepresentation];
てのでもよい。(相対パスからだと少し注意)

ファイルシステムとAPIの問題で、今までうまく処理していてくれただけに、バグと判断したくもなるﾖﾅ。

ざくっとなので内容に関しては自分で確認してね。

追記
NFCなファイル名は存在するべきではないし、
ファイルのcreate/writeには上記に気をつけていれば問題ないがreadの場合、
NSFileManagerなどの上位関数ではNFCなファイル名のものは無いものとして処理される。
fileExistsAtPathなどではfalse
だがcontentsOfDirectoryAtPathではNFCなままリストアップされて返ってくる。
上位関数レベルで見ると、あるらしいけれどアクセスできないってファイルになるという。

そんなの作らなければいいのだけれど、windowsのiTunes転送だと、NFCなファイル名なまま作成されてしまう恐ろしい罠が。（あ、もうapple自身がやっちゃてるならバグよね）