Swift PackageでGeoCoreJPを共有する — ローカルパッケージのマルチアプリ構成

GeoConverterPro と GeoPrism JP は、見た目も機能もまったく違うアプリですが、座標変換・補正の中身は同じエンジンを使っています。高精度を支えるGeoCoreJPの設計思想や座標変換エンジン『GeoCoreJP』技術解説では中身の設計思想を書きましたが、今回は「2つの独立したアプリに、どうやって1つのエンジンを配線しているか」という、Xcodeプロジェクトの構成そのものを解説します。

1つのworkspaceに複数アプリとエンジンを同居させる

GeoConverterPro と GeoPrism JP は、GeoApps.xcworkspace という1つのXcode workspaceの中で管理しています。workspace配下には、次の3つが並んでいます。

GeoCore/ — 座標変換・補正エンジン本体（Swift Package）
GeoConverterPro/ — 座標変換専用アプリ
GeoPrism/（コードフォルダ名は当時の名残でこのまま） — 測地系可視化・学習アプリ

それぞれ独立したXcodeプロジェクトでありながら、1つのworkspaceにまとめておくことで、エンジン側を修正した瞬間にどちらのアプリからも変更が見える状態を保っています。複数アプリを別々のworkspaceで開いていたら、「片方のプロジェクトだけ最新のGeoCoreJPを見ている」というズレが起きかねません。

ローカルSwift Packageという選択

GeoCoreJPはGitHub上の別リポジトリとして公開しているパッケージではなく、同じリポジトリ内にある相対パス参照のローカルSwift Packageです。各アプリのプロジェクト設定では、依存関係として ../GeoCore を指定しているだけで、リモートのgit URLやバージョンタグは一切登場しません。

この構成には、実務上いくつかの利点があります。

バージョンのズレが起きない。 リモートパッケージだと「アプリAはv1.2を見ているが、アプリBはv1.3のまま」という状態が起こり得ますが、ローカル参照なら常に同じコミット時点のGeoCoreJPをすべてのアプリが参照します。
変更の反映が速い。 GeoCoreJP側のコードを直したら、依存しているアプリをビルドし直すだけで反映されます。パッケージを公開してバージョンを上げて依存側を更新して……という手順が不要です。
1つのPull Requestでエンジンとアプリを同時に変更できる。 座標変換ロジックの修正とアプリ側の呼び出し変更が、常にセットでレビュー・コミットできます。

デメリットも当然あります。GeoCoreJPを他のプロジェクト（例えば社外に公開するOSSなど）から使いたい場合、この構成のままでは切り出せません。今のところGeoCoreJPは自社アプリ群専用のエンジンという位置づけなので、公開パッケージ化のコストより、密結合のメリットの方が上回っている、という判断です。

命名の内と外 — コードはGeoCore、対外表記はGeoCoreJP

もう一点、地味だが重要な運用ルールがあります。Swift Package自体のフォルダ名・モジュール名は歴史的経緯で GeoCore のままですが、ブログや固定ページなど対外的に発信する文章では「GeoCoreJP」という名称に統一しています。「GeoCore」だと世界中の座標変換全般を扱うエンジンに見えてしまい、実際には日本の測地系（JGD2024・セミダイナミック補正・地震補正など）に特化したエンジンであることが伝わりにくいためです。

コード上の識別子を変更すると影響範囲が大きく壊れやすい一方、対外表記だけを変えるのはブログ記事の文言を直すだけで済みます。「コードの実体は変えず、外向きの言葉だけ変える」という割り切りは、個人開発でリファクタリングコストを抑えながらブランディングを整える現実的なやり方だと感じています。

まとめ

GeoConverterPro と GeoPrism JP は、GeoApps.xcworkspace という1つのworkspaceでGeoCoreJPというSwift Packageを共有している
依存はリモートgitではなく相対パス参照のローカルパッケージで、バージョンズレなく常に同じエンジンをすべてのアプリが参照する
コード上のパッケージ名は GeoCore のままだが、対外的な発信では「GeoCoreJP」に統一し、日本特化エンジンであることを明示している