
filesystem-synchronizedなxcodeprojでアプリ雛形を量産する
Swift PackageでGeoCoreJPを共有するでは、複数アプリが1つのエンジンを共有する仕組みを書きました。今回はその一歩手前、新しいアプリの雛形(Xcodeプロジェクト)そのものをどう素早く用意するかという話です。Xcode 16で導入された「filesystem-synchronized」形式のおかげで、この作業がかなり軽くなりました。
旧形式の苦痛 — pbxprojへのファイル列挙
Xcodeプロジェクトは長らく、project.pbxproj という1つの巨大な設定ファイルに、プロジェクトに含まれる全ファイルのパスとグループ構造を1件ずつ記録する形式でした。この方式には、個人開発でも次のような不便がありました。
- フォルダにファイルを追加しても、Xcode上で明示的に「ターゲットに追加」しないとビルドに含まれない
- 複数の作業(自分の手作業とAIコーディングツールによる編集など)が同時にファイルを増やすと、
pbxprojの該当行が衝突し、コンフリクト解消が面倒 - ファイルシステム上のフォルダ構造と、Xcode上のグループ表示が一致するとは限らず、見た目と実体がズレていくことがある
新しいアプリを1つ作るたびに、このpbxprojをゼロから正しく組み立てる必要があり、地味に時間がかかる作業でした。
filesystem-synchronizedとは何か
Xcode 16以降で使える「filesystem-synchronized group」は、指定したフォルダの中身をXcodeが自動的にプロジェクト構造として認識してくれる仕組みです。フォルダにファイルを置けば、それだけでターゲットに含まれます。逆にファイルを消せば、プロジェクトからも消えます。
- フォルダ構造=プロジェクト構造。 Finder上のフォルダ階層がそのままXcodeのグループ階層になる
- 「ターゲットに追加」の手作業が不要。 ファイルを置くだけでビルド対象になる
pbxprojの差分が小さくなる。 ファイル列挙がなくなるぶん、設定ファイルの変更行数が減り、差分が読みやすい
この特性が、複数アプリの雛形を短期間で用意する作業と非常に相性が良いことに気づきました。
雛形の中身と複製の手順
新規アプリの土台として用意しているテンプレートは、次の3点だけを持つ最小構成です。
- MainView — アプリ名・キャッチコピー・GeoCoreJP連携の簡単な表示だけを持つエントリ画面
- GeoCoreJPへのローカルパッケージ参照 — 各プロジェクトから相対パス(
../GeoCore)で座標変換エンジンを参照 - Bundle ID・表示名の命名規約 —
jp.y4u.<アプリ名>形式のBundle IDと、6文字統一の表示名
新しいアプリを起こすときは、このテンプレートフォルダをコピーし、Bundle IDと表示名だけを書き換えて GeoApps.xcworkspace に追加します。filesystem-synchronized形式のおかげで、フォルダをコピーした時点でほぼプロジェクトとして成立しており、ファイルを1つずつターゲットへ登録する作業が発生しません。将来展開する予定のアプリ群についても、この雛形を複製する形で土台だけは先に用意してあります。
AIコーディングツールとの相性
filesystem-synchronized形式のもう一つの利点は、AIエージェントによるコード編集との相性です。ファイルシステム上の構造がそのままプロジェクト構造なので、AIツールが「このフォルダにファイルを追加すればビルドに含まれる」という前提で安心してファイルを作れます。旧形式のように「ファイルは置いたがpbxprojへの登録を忘れている」という、見た目には気づきにくい不整合が起きにくくなりました。
一方でデメリットもあります。フォルダ内のすべてが自動的に対象になるため、テンプレート的な資材(ドキュメントや作業メモなど)を同じフォルダに置いてしまうと、意図せずビルド対象に混入することがあります。テンプレートを複製する運用では、フォルダの中身を「本当にビルドに必要なファイルだけ」に保つ規律がこれまで以上に重要になります。
まとめ
- Xcode 16のfilesystem-synchronized形式は、フォルダ構造をそのままプロジェクト構造として扱ってくれる
- 「ターゲットに追加」の手作業が不要になり、
pbxprojの差分も小さくなる - MainView+GeoCoreJPローカルパッケージ参照+Bundle ID命名規約という最小構成のテンプレートを複製することで、新規アプリの雛形を素早く用意できる
- フォルダ内の全ファイルが自動的にビルド対象になる特性上、テンプレートフォルダの中身を必要最小限に保つ規律が必要
関連記事
- Swift PackageでGeoCoreJPを共有する — ローカルパッケージのマルチアプリ構成(GeoConverterPro)
- 高精度を支えるGeoCoreJPの設計思想(GeoConverterPro)
- なぜNET MAUIで測量アプリを作るのか(GeoDiveExa)
- 「同じような記事は書かない」をAIに守らせる — 重複チェックを執筆前工程に組み込む運用(GeoPrism JP)
開発者より: アプリ・Kindle本・オープンソースの一覧は GitHub: amru195704 にまとめています。
お願い
本記事の情報は参考目的で掲載しており、正確性・完全性を保証するものではありません。誤記・不正確な情報がございましたら、コメント欄よりご指摘いただければ、確認のうえ修正いたします。
アプリを入手(App Store):GeoConverterPro(座標変換) | GeoPrism JP(測地系の可視化・学習)
コメントを残す