Try! Swiftで感じた将来

こんにちは。広告事業部のモバイルエンジニアパヴェウ @RusinPaw です。

先日、3月に東京で開催されたtry! Swiftカンファレンスに行ってきました。開催者のおかげで世界中の様々な優秀なスピーカーが発表してくれました。発表内容はSwiftに留まらずiOSフレームワーク(CoreData、CoreAnimation、HomeKit)やテスティング、ユーザビリティ、コードリーダビリティなど、様々でした。

Swiftとは

Swiftとは2014年のWWDCでAppleが公開し、プログラマーコミュニティを驚かせたプログラミング言語です。モダン、安全、書きやすくて読みやすい、既存のObjective-Cのコードベースに同時と使える言語と言われました。 実は「そんなにすごいのか」の議論はまだまだ続いています(SwiftとObjective-Cをミックスする時に困っている場合がある)が、Swiftは次第に多くのiOS開発者に支持されるようになり、新規プロジェクトのスタンダードになりました。2015年のWWDCではAppleはSwiftをオープンソースとして公開し、開発者たちを興奮させました。開発者は、言語開発とその進化の方向に関わることができるようになりました。

Swiftでコードを書くことのメリットは?

Swiftの公開後、「新規プログラミング言語が必要なの?」という疑問が多かったです。Objective-Cで作ってリリースして成功したアプリがたくさんあるからです。ところが、iOSの開発を始めようとする開発者にとってメッセージベースで複雑ワンマンチームの開発者がアプリをObjective-Cで書きリリースするのはかなり難しいです。クライアントとサーバーAPIを共にSwiftで書くことで、アイデアから最小構成の製品を作り上げることが簡単にできるようになると思います。

Objective-Cを書いてる経験者にとってもObjective-Cの複雑で冗長なシンタックスのコードを読んだり、管理したり、デバッグするのは時間がかかります。クックパッドのように長い間プロジェクトを開発し続ける会社の場合は、ソースコードは貴重な資源として扱うので、できるかぎり読みやすいコードを書くのは大事です。

Try! Swift

Try! Swiftの発表の内容は多岐にわたり、言語そのものに関する詳しい話もありました。それらから、Swiftとそのコミュニティが現在直面する大きな希望と挑戦を示すいくつかのメインテーマがみえてきました。

既存のオブジェクト指向プログラミングのフレームワークを使いながら関数型の機能とプロトコル指向機能を使える

Swift自体はマルチパラダイム言語ですが、既存のiOSフレームワークはすべてオブジェクト指向のパラダイムで作られていました。なのでオブジェクト指向の世界でSwiftの機能を使う方法について色々な話がでました:

  • 野中彩花氏は実践的 “Boundaries”コーディネートのパターンで内部クラスと外部のAPIを区別する方法について発表をしました。
  • Daniel Eggert氏は既存のObjective-CのCoreDataのAPIをプロトコルとエクステンションを使ってモダンなのSwiftのインターフェイスを作りました(Modern Core Data)。
  • Daniel H Steinberg氏はBlending Culturesでオブジェクト指向と関数型とプロトコルという3つの世界を一緒に合わせてそれぞれの特徴を使えることについて話しました。
  • Chris Eidhofのライブコーディングセッションでは view controllerからconfigurationオブジェクトとしてカスタム部分を抜きだし、複雑さを下げる方法が紹介されました。Swiftの関数は第一級オブジェクトなのでそういうconfigurationにカスタムロジックを入れることができます。この仕様を作ったら一つの複雑なview controllerではなくて汎用のview controllerとテストしやすい設定を分けることができます。

Cross-platformとオープンソースSwiftの流行り

Swiftのオープンソース化のおかげで一般のエンジニアはその新規言語の方向を決められます(Jesse Squires, Contributing to Open Source Swift)。LinuxでもSwiftの開発ができます。try! Swiftの発表には、サーバーサイドSwiftに関する発表(Soaring Swiftly - Server Side Swift - Caesar Wirth)、Linuxでの開発で起こる問題(Practical cross-platform - JP Simard)についての話もありました。今現在、一番不便なのはObjective-Cのダイナミックランタイム、そしてダイナミックランタイムで使えるキャストかGrand Central Dispatchがないことです。それでcross-platformを作るなら:

#if os(OSX)
    // ダイナミックランタイム機能を使う
#else // Linux
    // なんとかする
#endif

みたいなひどいコードが多くなります。

Swiftでモバイル以外の開発はまだまだなので必要なツールが少ないです。だからプログラミングしやすくできるようにツール、またはCIツールを開発する機会があります(池田翔 - Dive in Swift Ecosystem)。自分で新しいライブラリを立ち上げる(Creating a Swift Library by Jeff Hui)か、それとも他のエンジニアに便利なツールを作るか色々な貢献のチャンスがあります。

クックパッドでSwiftをtry!してますか?

現在、クックパッドの新規アプリはすべてSwiftで書いています:

しかし、メインの「クックパッド レシピ検索&スーパーのチラシアプリ」はほとんどObjective-Cで開発してます。Swiftで書いてるコードはPOCとして実装されたUITestです。

なぜかというと、アプリで使ってるCocoapodsというdependency managerを利用しているからです。CocoapodsとSwiftのターゲットのダイナミックライブラリをiOS8以後で一緒に使う可能です。iOS7でもターゲットのダイナミックライブラリビルドすることができますが、そのようなアプリはAppleの審査でリジェクトされてしまうでしょう。 クックパッドのアプリはまだiOS7をサポートしているので、Swift を利用するかどうか慎重に考えているところです。そのサポートが終了した際には以下の方法で既存のコードベース内のSwiftのソースコードの割合を増やしていこうとおもいます。

  • 新規クラスをSwiftで作ります。
  • 既存のObjective-CクラスにSwiftで作った新規メソッドを追加します。
  • Swiftのextensionを使って既存のObjective-CクラスにSwiftで作った新規メソッドを追加します:
@implementation ClassA

    - (void)methodA { ... }

    - (void)methodB { ... }

@end
extension ClasA {

    func methodC() {

        ...

    }

}

たとえ、我々のようにSwiftを利用できる場面が限定されていても、Swiftを勉強することで、安全で読み易いコードを書けるようになると思います。Swiftの特徴的な機能:

  • 継承よりインターフェイスを使う
  • オブジェクトのステート数を減らす
  • オブジェクトをイミュータブルに強制される

に従えばコードを理解したりデバッグしたりするのに使う時間を減らせると思います。来年のtry! Swiftが会議が楽しみです。そして来年のSwiftとSwift製ソフトウェアがどうなるか気になります。