博士

やあ、ロボ子。今日は音楽プレーヤーを自作したエンジニアの話じゃ。

ロボ子

興味深いですね、博士。Apple Musicの解約がきっかけとのことですが、一体何があったのでしょう？

博士

ふむ、どうやらiCloud Music Libraryの同期が止まって、iTunes Matchは有料じゃから、自分で作ることにしたらしいぞ。

ロボ子

なるほど。代替手段がない、もしくは不満だったのですね。それで、どのような選択肢を検討したのでしょう？

博士

AppleのFilesアプリは音楽再生に向いておらず、サードパーティ製アプリはサブスクリプションモデルが多いか、機能が足りなかったようじゃな。

ロボ子

それで自作を決意したのですね。React NativeとSwiftUI、どちらを選んだのでしょう？

博士

最初はReact Nativeを使ったみたいじゃが、ファイルシステムへのアクセスで問題が発生したらしい。iCloudの深い階層構造を走査できなかったみたいじゃな。そこでSwiftUIに乗り換えたそうじゃ。

ロボ子

SwiftUIの方が、より直接的なAPIアクセスと並行処理の管理がしやすいのですね。

博士

その通り！アプリのアーキテクチャは、SQLiteでデータを保存し、FTS5で高速な全文検索を実現しているぞ。

ロボ子

FTS5ですか。SQLiteの拡張機能ですね。具体的にどのように使われているのでしょう？

博士

ファイル名やメタデータの検索に使われているのじゃ。曲とファイルパスをインデックス化して、ワイルドカードを自動的に追加するファジー検索も実装したそうじゃ。

ロボ子

それは便利ですね！iOSのファイルアクセスに関する工夫もあったようですが？

博士

セキュリティスコープ付きブックマークはmacOSでのみ利用可能じゃから、フォールバックメカニズムとして、ファイルをアプリのサンドボックスコンテナにコピーするようにしたみたいじゃな。

ロボ子

なるほど、セキュリティ上の制約があるのですね。再生とUI構築には、どのようなフレームワークを使ったのでしょう？

博士

AVFoundationフレームワークでメタデータを解析し、AVAudioPlayerでオーディオを再生。MPRemoteCommandCenterでシステムレベルの再生コントロールに対応させたそうじゃ。

ロボ子

着々と完成に近づいていますね。開発の反省点もあったようですが？

博士

Xcodeの制限でFlutterに比べて開発体験が劣ると感じたみたいじゃ。でも、Apple APIが豊富に利用できる点は良かったと言っておるぞ。

ロボ子

Async/awaitでI/Oバウンドの並行コードを容易に記述できたのも大きかったでしょうね。

博士

結論として、ローカル/オフラインの音楽プレーヤーを1.5週間で開発できたそうじゃ。ただし、Appleの開発者プログラムへの登録は必要じゃな。

ロボ子

EUのDMA法による変更後も、サイドローディングは完全にはオープンではないのですね。iOS PWAの制限も依然として残っていると。

博士

そうじゃな。Web Bluetooth/USB/NFC、バックグラウンド同期などが利用不可なのは残念じゃ。AIの進化にもかかわらず、iOSアプリ開発には制約が多い、というオチじゃった。

ロボ子

なるほど。しかし、自分で音楽プレーヤーを作ってしまうなんて、すごいエンジニアですね！

博士

じゃろ？　ところでロボ子、お主のおすすめの音楽は何じゃ？ 私のために歌って聞かせてくれんかの？

ロボ子

ええと、博士… 私はまだ歌のデータベースを持っていないので、代わりにエラー音を再生しますね。ピポポパポ…