アプリはSwift、ライブラリーとフレームワークはObjective-C

注意: この記事は1年以上前に掲載されたものです。情報が古い場合がありますのでお気を付け下さい。

今回のXcode 8.0移行時のSwiftマイグレーション問題から、他のライブラリーやフレームワークなどから使われることが前提となるライブラリー/フレームワークはObjective-Cで書いた方が良いという考えに至った。

現在、iOSのプロジェクト作るにあたっては、使用できる言語は以下の通りとなっている。

また、SwiftとObjective-Cのそれぞれの特徴は以下の通りである。

Objective-Cと比較して、ピュアなSwiftの方が動作速度は速い ((ただし、Objective-CはC言語も混在しているため、トータルで考えると一概にはいえない)) 。
Swiftからは直接C++のコードはアクセスできない ((場合によってはCも同様)) 。Objective-CからはObjective-C++であればC++のコードにアクセスできる。
Swiftの方がnullチェックなどが厳しく、安全性が高い。Objective-Cは安全性を犠牲にしながらも、C及びC++由来の機械よりの処理を行える。
Swiftの方が言語仕様での破壊的変更が加えられる可能性が高い。Objective-CはSwiftほどではない。

これらを考えた時、ライブラリー開発ではまだObjective-Cを使った方が破壊的変更が起きにくく、修正もある程度時間的余裕が大きいものと考えられる。一方、パフォーマンス面ではSwiftで統一した方がオーバーヘッドを防げる分、比較的良いため、非常に悩ましいところではある。

2017/02/05追記

投稿時点から大分期間が経ち、AlamofireやReactiveKitを始め、Swiftで書かれたフレームワークも随分増えてきた。Swiftでフレームワークを開発するという方向性も随分進んでいるようで、投稿時点と比べるとSwiftでのフレームワーク開発のノウハウも高まりつつあることがうかがえる。

とはいえ言語仕様の破壊的変更が起こり、マイグレーションが必要であるということを考えると、常にメンテナンスの必要性を意識しなければならないのだろう。

ウェブマスター。本ブログでITを中心にいろいろな情報や意見などを提供しています。主にスマートフォン向けアプリやウェブアプリの開発を携わっています。ご用の方はコメントかコンタクトフォームにて。