SwiftとiOSの変化を意識したアプリ開発

今回は、いつもと趣向を変えて、違う話題を取り上げてみます。SwiftやiOS APIの将来について、開発ツール選びや開発方針との関連も含めて、ちょっと考えてみたいと思います。

　

開発ツールやAPIを選ぶことは、開発者にとって大事な選択です。とくに大きなソフトを作る場合、開発ツールやAPIの将来性を適切に見極めないと、時間をかけて開発したものが無駄になったりします。同様に、小さなソフトでも数が増えると、大きなソフトを作ったと同じ状況に陥ります。

見極めが大事だと書きましたが、開発ツール全体の傾向としては、少しずつ不安定な方向に変化していると感じています。昔のように、１つの言語をマスターすれば、安心して長い間使えるという時代ではなくなっていると感じます。上手に対応するためには、複数の言語やAPIを使えなければならない時代なのでしょう。見極めと同時に、どれか１つだけに固執しないのも、これからの時代は大事なのかもしれません。

　

で、肝心のSwiftとiOS APIの話です。これらも将来の変化を意識する必要があるでしょう。まずはSwiftから。

今のところSwiftは、アップルの開発ツールとして大きな地位を築きつつあります。築きつつというより、固めつつあると表現したほうが適切かもしれません。その流れを作っているのは、当然ながらアップルの方針です。

おそらくアップルは、開発用のプログラミング言語を、Objective-CからSwiftに移行したいのでしょう。現状では、Objective-Cを完全に無くすことはできませんから、段階的に移行する過程だと思います。今後の大きな流れとしては、Swiftの仕様を少しずつ拡張しながら成長させて、Objective-Cから完全に置き換える方向に向かっているのでしょう。

　

続いて、iOSのAPIです。現状のAPIは、OSXのAPIをできるだけ流用しつつ、座標などを少し変えて手直ししたものです。細かなクラスなどは、iOSとOSXで共通のものが多くあります。それは当然の選択で、あえて同じに作ることで、ソースコードを流用しやすくしています。

では、今後も今のAPIを使い続けるのでしょうか。有名な噂サイトに登場した噂話によると、どうやら新しいAPIを作っているようなのです。おそらくは、iOSとOSXで完全に共通のAPIとして作っているでしょう。iOSとOSXは、UIも少しずつ近づけていますから、これも当然の流れだと思います。

　

その新しい共通APIは、どのような形になるのでしょうか。当然の流れとして考えられるのは、Swiftとの親和性を強めることです。

現状のSwiftでは、iOS APIとの親和性が十分ではありません。たとえば、Dictionaryなら、NSObject以下のクラスを自由に扱えるのはNSDictionaryであって、SwiftのDictionaryではありません。同様にAnyも、NSObject以下のクラスとの親和性がAnyObject(中身はObjective-Cのid)に劣ります。

これらの欠点を解消し、SwiftのDictionaryやAnyとの親和性の高いAPIになるはずです。それ以外の面も含めて、Swiftとの親和性を第一に考えて設計されたAPIとなるでしょう。

その新しい共通APIは、Objective-Cからも使えるでしょうか。そのときになってみないと分かりませんが、アップルのことですから、使えなくすることも十分に考えられます。Swiftへの移行を強く進めるために。

　

おそらくは、APIの共通化だけが目的ではないでしょう。もっと現代的な設計に作り変えているのではないかと、予想します。

私だけの印象かもしれませんが、NSObjectをトップに持つ一連のクラスは、昔ながらのオブジェクト指向を強く意識した形で作られているように見えます。デリゲートなどの作り方に癖があるというか、全体的に美しくありません。また、使いやすくないことも大きな欠点だと思います。

アップルがどのような形に改良するかは不明ですが、おそらくは癖をあまり出さないで、ソースコードが書きやすい形でまとめ上げると予想してます。

　

つまり全体の流れとしては、プログラミング言語はObjective-CからSwiftに、APIはiOS/OSXの２つのAPIから共通モダンAPIに、という形になると予想します。当分の間は、それぞれの古いもの(Objective-Cと、iOS/OSXの２つのAPI)もサポートされるでしょうが、iOSやOSXのバージョンがどんどん上がるうちに、サポートしなくなる可能性が高いでしょう。

もう１つ、iOSとOSXという２つのOSの存在も、今とは違ってくるでしょう。おそらく、これも共通になり、１つのOSに統合されるはずです。UIが少しずつ近づいているわけですから、共通化も少しずつ容易になっていきます。もちろん現実は逆で、共通化する目的のためにUIを近づけているのでしょう。

アップル独自のチップであるAシリーズも、世代が進むごとに処理能力が向上しています。あと数世代も進めば、現状のパソコン用CPUと同等か、それ以上の処理能力を得られるでしょう。そうなったときが、共通OSへの移行に適した時期ではないでしょうか。

共通OSになったとき、iPhone、iPad、Macというハードウェアの区別に、あまり意味はありません。iPhoneの画面の大きな機種に、Xcode後継ツールをインストールして、無線キーボードと組み合わせながら、iPhone上でアプリ開発も十分に可能でしょう。実際に使うかどうかは別として。

　

以上のような流れですが、大きくは外れないと思います。大事なのは、プログラミング言語はObjective-CからSwiftに、APIはiOS/OSXの２つのAPIから共通モダンAPIに、という流れです。

いろいろな開発者がいますから「流れなんて考えず、また作り直せばいいよ」と思う人もいるでしょう。でも、作り直すのは大変です。誰にも頼めないユーザーもいるでしょう。作り直しだと余計に手間や費用がかかり、そこまでの費用を出せないユーザーもいるでしょう。どう考えても、できる限り最小限の手間で、使い続けられることが一番良いのです。

将来の手間を最小限にするためには、現時点でどんな選択をすれば良いのでしょうか。Xcodeを使ったiPadアプリ開発に限って考えると、次のような点が大事だと思います。

まずは、プログラミング言語の選択です。可能な限りSwiftで書くことは必須です。もしObjective-Cしか作れない機能があったとしても、全体をObjective-Cで作るのはお勧めできません。作れない部分だけ切り分けてObjective-Cで書き、残りの部分をSwiftで書くのがベストです。

APIに関しては、新しい共通APIが登場していませんから、現状のAPIを使うしかありません。でも、将来への対処方法が、まったく無いわけではありません。どのアプリでも共通で使う機能は、できるだけライブラリとして作り、すべてのアプリで共通して使えるように作っておきます。将来、新しいAPIが登場したとき、個々のライブラリを新APIで作り直して、入れ替えることを可能にしておきます。

共通ライブラリを使ったアプリに仕上げることで、入れ替え用の互換ライブラリを１つ作るだけで、どのアプリにもそのまま利用できます。ライブラリとして作るわけですから、テストも試験専用アプリで徹底的に行えます。アプリ側の細かくテストする必要はありません。徹底的にバグを消してから、アプリ側を入れ替える手順が可能です。

いくつものライブラリとして作っているので、１つずつ順番に新APIで作り直すことができます。それぞれのライブラリは関連する機能が集まっているので、新APIの仕様を調べるのも効率的でしょう。同様に、細かなテストも作りやすいはずです。

ライブラリ化の大きなメリットは、ライブラリ化してないアプリを新APIに移行する作用を想像すると、よく分かります。ライブラリ化してないのですから、すべてのソースコードが、それぞれのアプリで異なります。新APIに書き換えるときは、アプリごとに細かく見ながらソースコードを書き直していきます。テストも個々のアプリごとに、別々に行う必要があり、非常に大変な手間となるでしょう。

当然ですが、共通ライブラリ化の一番のメリットは、将来への備えではありません。共通化することで、新しいアプリを作るときの手間を大きく減らせることが、最大のメリットです。さらには、ライブラリにバグが見つかったとき、バグを修正すれば、すべてのアプリで入れ替えが容易です。アプリごとに個別に直す必要はありません。こうしたメリットに加えて、将来への備えにもなるのですから、やはり非常に大きなメリットと言えるでしょう。

　

長くなりましたが、ここまでの話をまとめると次のようになります。

現状のiPadアプリ開発で重視したい点
・できるだけSwiftで作る（Objective-Cでなければ作れない箇所は、その部分だけObjective-Cで作る）
・どのアプリでも共通に使う機能は、関連する機能を集めてライブラリ化して、取り替え可能に作る

以上は、あくまで私個人の考察結果です。信じるのも自由、一部だけ信じるのも自由、まったく信じないのも自由です。どちらにしても、将来起こる変化を少しは気にして、アプリ開発の方法を考えてみてはいかがでしょう。