Objective-Cの紆余曲折から急激に進化 “モダンで安全な言語”になった「Swift」
Swiftは、WWDC 2014の基調講演において突如彗星のごとく発表されたAppleの新言語だ。それまで使っていたObjective-Cに比べ、“モダンで安全な言語”になったと言われている。言語仕様／開発環境共に急速な進化を続け、すぐ翌2015年には2.0が登場。年末にはオープンソース化され、コンパイラやコアフレームワークも公開。Linuxもサポートされた。Appleだけでなく、外部の多彩なデベロッパーを巻き込みながら、Swift 3.0 に向けて進化を続けているといったところだろう。
もともとiOSなどで使われていたObjective-Cは、1983年に開発され、ジョブズとともに紆余曲折を経て2001年のMac OS XのCocoaフレームワークのコア言語として採用されたという歴史を持つ。佐野氏は「C言語をオブジェクト指向化したものだが、オブジェクトはただの構造体へのポインタであり、メソッドコールもCの関数呼び出しに変換される。つまり、C言語を“ラッピング”したようなもの」と解説する。
そのため、古い言語として非効率で難解、ランタイム時処理においてはオーバーヘッド、さらに柔軟性が保たれる分、コンパイル時の最適化ができないことや、型付けが弱くて実行した際にエラーが落ちるなど、様々な弱点が指摘されていた。それが2007年に2.0でプロパティ等が加わり、2012年の段階にModern Objective-Cとなった際に、Appleが独自に開発したコンパイラ「LLVMシステム」が加わったことで急速に進化し、Swiftの誕生へとつながった。
佐野氏は言語としてのSwiftを、モダンで読みやすい言語仕様、型安全であり、関数型でプロトコル仕様、Objective-Cとの互換性などと説明。Swiftに対応するメリットとして、Objective-Cよりも安全なコードを効率的に書くことができること、コンパイル時最適化でパフォーマンスの改善が期待できること、そして、iOSアプリ開発においてはSwiftが標準となることは明らかであり、3rdパーティ製ライブラリも徐々にObjective-Cサポートを切るであろうことをあげた。
「Yahoo!ショッピング」などヤフー製アプリの約30％がSwift対応
それでは、ヤフーのSwift対応はどこまで進んでいるのか。佐野氏によると、ヤフー製の59アプリのうち20アプリ、3分の1が導入済みだという（2016年2月18日時点）。現在、会社をあげての推進活動により、主力アプリは2016年度中には導入される予定だ。
既にSwiftに対応した事例として、まず「Yahoo!ショッピング」iOSアプリが紹介された。2010年に開発を開始し、2011年にver1.0.0がリリースされたが、機能追加やビジネス案件の対応により徐々にコード量が増加し、さらに古いコードが多く、ビューとロジックが分離されていないなどから、新機能追加が高コストになっていた。
そこで、昨年の6月よりSwift導入対応プロジェクトを開始した。しかし、通常の開発を止め、フルスクラッチで作り直すことはビジネス判断でNGとされ、少数の推進メンバーが中心となって、画面／機能単位で段階的に対応を行っていった。なお、その際にはSwift対応によるメンテナンス性向上とともに、iPad対応も併せて進めた。
ホーム、商品検索、商品詳細と、通信やユーティリティ部分の共通ライブラリに分けて、引き出し可能な部分や頻繁に手が入る部分から対応を進めていった。その詳細については「Yahoo! JAPAN Tech Blog」にて掲載しているという。
この対応によって、クラッシュ率がほぼ半分に大幅に低下し、実装コストも大きく削減できた。さらに、同時に進めたiPadアプリが想像以上にヒットすることになった。問題もないわけではなかったが、たとえばSwiftに慣れるまで一時的に開発速度が落ちたことは、長い目で見ればプラスであり、新言語の学習コストは自分たちで自主的に勉強会を開催してカバーしたという。ただ、Objective-Cよりビルドに時間がかかったこと、頻繁なSwift自体の仕様変更でその度に対応が必要だったことなどが、苦労点としてあげられた。
Swift対応のカギとなるMVVMアーキテクチャのメリット
続いて「ヤフオク!」iOSアプリの事例が紹介された。こちらも2010年にver1.0.0がリリースされてから、長年に渡って多くの開発者の手にかかり、新旧のコードが入り混じって肥大化していた。簡単な機能追加でも影響範囲が分かりづらく、かなりコストがかかっていたという。
そこで昨年末よりSwift対応プロジェクトが始動した。こちらも開発を止めずにアプリを根本的に再設計するために、少数の推進メンバーが先行して導入をはかった。特にコンポーネント間の依存関係を断ち切るため、MVCからRxSwiftによるMVVMアーキテクチャへと変更したという（RxSwift：リアクティブプログラミングを行うためのライブラリ「ReactiveX」のSwift実装）。
「二者の違いは、ViewControllerからViewを管理するViewModelを分離したこと。MVVMでは、お互いの依存関係をつくらないために、メソッド単位で結合するのではなく、自分が責任を持っている範囲の変更をするだけで、必要な人が必要に応じて受け取り、半自動的に切り替わるというような作りになっている」（佐野氏）
MVVMアーキテクチャのメリットとしては、コンポーネントが疎結合になり、安全性や再利用性が高まること、コンポーネント間の連携の仕方が規定されており、不用意に肥大化することが避けられること、そしてコードの書き方が統一されるため、メンバーの能力差による品質のバラツキが抑えられることなどがある。
一方、外部フレームワークの採用のリスクとしては、提唱するアーキテクチャを理解しなければならないこと、進化するフレームワークに適応していく必要があるなどがある。最もリスクとして大きいのは、外部フレームワークへの依存性が強すぎると、それが廃れたときに抜け出せなくなる危険があるということだ。佐野氏はかつてのThree20ではしごを外された例を紹介し、「それなりの覚悟と未来のビジョンがないと、いざ状況が変わった時に困ってしまう。なので、手離しでは推奨しないが、それでもMVVMアーキテクチャを活用する価値はある」と語った。
現状では画面単位での再設計を進めており、本格的な開発が始まれば、外部のエンジニアも参加することから、事前に設計のガイドラインやコーディング規約等も用意しつつあるという。そして、5〜6月にはフルリニューアルを完了させる予定だ。
なお、3つめの事例も紹介されたが、Swiftに自動変換するソフトウェアを自分たちでつくり、ほぼ100％置き換えられているが、設計の部分をObjective-Cのまま引き継いだため、早くも肥大化・複雑化が進んでいるという。早々のMVVMアーキテクチャの導入を検討しているそうだ。
こうした事例を振り返り、佐野氏の気づきとして「ゼロからSwiftアプリを作るのは楽しい。しかし、既存アプリをSwift対応するのは実に大変。特に多くのユーザを抱えて稼働しているアプリの場合は、不利益を出さずに移行できるよう計画が肝心だ。経営層にアピールするには、ユニバーサル化や設計の見直しなどと併せてSwift導入をすると説得しやすい」と語った。
