SimpleBoxes | 汎用コードを複数の iOS アプリケーション開発で共有利用する手法

汎用コードを複数の iOS アプリケーション開発で共有利用する手法

いくつかの iOS アプリケーションを開発していると、自然と共有できるコードが増えてきます。

そうした共有可能な汎用コードを複数のアプリケーションのプロジェクトで利用する方法はいくつか考えられます。

別リポジトリで管理している汎用コードを svn externals や git submodule などを使ってリンクして、それをそのままアプリケーションのプロジェクトに組み込みます。

svn や git などバージョン管理ソフトウェアの機能だけを利用しているので、仕組み自体はとてもシンプルになります。

構成はシンプルになりますが、その分運用でカバーしなくてはいけない点があります。

汎用コード部分のビルドがアプリケーションのプロジェクトに依存するので、汎用コード部分の独立性を保つのに注意が必要。
汎用コード部分でファイルの追加・削除があった場合、それを参照している全てのアプリケーションプロジェクトを逐次変更しなくてはならない。
汎用コードを利用する新規アプリケーションプロジェクトを作成して、リンクしたリポジトリを取り込む際、ターゲットに含めるファイルとそうでないファイルの切り分けが必要。

総じて独立性が乏しい分、手順が増える傾向があります。

汎用コード部分を静的ライブラリとして作成して、アプリケーションのプロジェクトにライブラリとして登録します。

静的ライブラリを作成するプロジェクトファイルがアプリケーションのプロジェクトとは独立した形で作成されるので、アプリケーションのプロジェクトに依存することなく、ビルド・ユニットテストを行うことができます。

Xcode は外部プロジェクトもプロジェクトに組み込めるので、アプリケーションをビルドする際に都度静的ライブラリを生成するような形で運用することも可能です。

Xcode の基本機能だけで完結しますし、手順もそれほど難しくはないのですが、イメージや xib などのバイナリリソースが静的ライブラリには、そのまま組み込めないという制約があります。

イメージなどのバイナリリソースは静的ライブラリとは別にアプリケーションのプロジェクトに組み込む必要があります。

その場合、汎用コード部分で利用されるリソースファイルの追加・削除の手間は前述の組み込み型と同等になります。

静的ライブラリではリソースは組み込めないのですが、フレームワークという仕組みを利用するとリソースも込みでライブラリを生成することができます。

UIKit などはフレームワークの形で配布されて、ほぼ全てのネイティブ iOS アプリケーションで利用されています。

汎用コード・リソースの共有化という点では最適な方法なのですが、Xcode の標準な方法ではサポートされないという欠点があります。

Mac OS X 向けアプリケーションに対してはフレームワーク生成がサポートされていますが、iOS プラットフォームではサポートされていません。

iOS ユニバーサルフレームワークなどを利用すると iOS プラットフォーム向けフレームワークを作成することができます。

github での説明を見ても分かる通り、現状ではややハック的な運用にならざる得ないようです。Fake Framework という仕組みではバンドルを利用していたりするみたい。

拙作 SBPullToRefreshHeaderView のようにリソース込みな汎用コードがある場合、リソースがあるのでやはりフレームワークを使う方法になると思います。

ハック的な運用を避けて、Xcode 標準な機能だけでなんとかならないか、と探していたところ、Compiling Image Resources into a Static Library という記事を見つけました。

静的ライブラリにはバイナリリソースは組み込ませんが、バイナリを C コードの形でダンプしてコンパイルしてしまえば、データとして組み込むことが可能になります。

Compiling Image Resources into a Static Library では、イメージだけ処理していますが、同様に nib ファイルも処理できます。具体的な手順については後日改めて。