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

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

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

  • アプリ – Swift, Objective-C, C++, C, ほか
  • フレームワーク – アプリに同じ
  • スタティックライブラリー – Objective-C, C++, C, ほか

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

  • Objective-Cと比較して、ピュアなSwiftの方が動作速度は速い1
  • Swiftからは直接C++のコードはアクセスできない2 。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を中心にいろいろな情報や意見などを提供しています。ご用の方はコメントかコンタクトフォームにて。
  1. ただし、Objective-CはC言語も混在しているため、トータルで考えると一概にはいえない []
  2. 場合によってはCも同様 []
スポンサーリンク

フォローする