iOS開発 vs. Android開発

Cameron Henneke氏は、GQueuesの設立者兼開発者である。GQueuesは、オンラインタスク管理ツールの一種で、いくつかのGoogleのサービスと統合されている。HTML5モバイル版のアプリケーションは、iOSとAndroidに移植されているが、両方のプラットフォームを巻き込んだ開発の苦労や、その結果を比較した記録がブログ記事の形で残っている。以下の記事は、InfoQが実施したインタビューによるもので、Henneke氏がこの開発を通じて発見し経験したことについてのダイジェストとなっている。

事前の経験

Henneke氏は１２年以上にわたってソフトウェア開発の経験を積んできているが、彼の視点からはどちらのプラットフォームも対等な立場と位置づけており、iOS と Android について、それ以前は殆んどあるいは全く経験がなかった、と私達に話した。

私は、このアプリの開発をスタートした時には Androidについて全くの初心者でした―このプロジェクトを始めるまで、自分のコンピュータにSDKをインストールしたことさえなかったのです。私は、iOSに関しても同様に初級者でした。2010年には２つの基本的な iPhoneゲームを作成しましたが、GQueuesアプリほどの複雑さからはほど遠いもので、全く異なるAPI群を使っていました。それ以来、今年の３月にGQueuesプロジェクトを開始するまで、私は iOS 開発には触れてきませんでした。

開発工程

Android

• 参考書を読み込み、チュートリアルを眺め、そしてテストアプリケーションを作成するのに1週間
• 最初の設計フェーズに1週間
• 実際のコーディングを始めるまでに870時間

iOS

• Core Data APIに習熟し、 PersistentStoreCoordinators と ManagedObjectContexts を使い、『FetchedResultsControllersのためのスケーラブルなアーキテクチャ』を開発するのに、2週間の学習期間
• 『安心してiOS向けのコーディングができる』までに、さらに2週間

全体として、Henneke氏は Androidに比べて iOSでの学習曲線には２倍の時間を使ったと述べた。

教材について、Henneke氏は AndoroidドキュメントはiOSに比べて「より高い」品質であることに気づいた。Androidがオープンソースであることも助けとなり、彼はサンプルコードを見つけて学ぶことができた。iOSのドキュメントについては、彼は以下のように述べている。

iOSドキュメントは増殖していますが、その多くは iOS 5 および 6 での自動参照カウンティング（ARC)を含む大きな変更によって内容が古くなっています。それゆえ、多くのコードサンプル（Apple社の公式サンプルを含む）や、問題への対処方法は、新しいやり方（=ARC）を選択するなら、事実上無視しなければなりません。全てを新しい内容に書き替えるには、まだもうしばらく時間がかかるでしょう。

Android版の開発は、「HTML5版のモバイルWebアプリでいままで用いていたバックエンドのサーバーと同期コード」の完全な書き直しを含んでいるが、Henneke氏は、iOSに比べてAndroidではおよそ１０％少ない時間で済ませることができた。開発の全体を集計したものは、以下の表のようになった。

	Android	iOS
開始日	2012/09/21	2013/03/02
βテストの準備完了	2012/12/22	2013/06/10
アプリ公開	2013/01/31	2013/07/18
プロジェクト総時間	4.25 ヶ月	4.5 ヶ月
準備期間	1 週間	2 週間
開発期間	870 時間(概算)	960 時間(概算)
ベータテストおよび修正	34 日	38 日
ベータテスタの数	92 人	48 人
コードの行数	26,981 行	23,872 行
アプリのダウンロードサイズ	1.1 MB	3.5 MB

ツール

個人的には Vim を好むようだが、Henneke 氏がこのプロジェクトで使用したツールについて以下のように述べてくれた。

• 「Eclipse内で検索するのは、びっくりするほど遅く煩わしいものです。」
• 「Xcodeのオーガナイザでドキュメントを検索するのは、腹立たしいほど遅いです。」彼は後に検索を速くする方法を発見した。
• 「Eclipse（および Androidプラグインの logcat 統合機能）のタグによるログの絞り込みはとても役に立ちます。」
• 「双方のIDEとも、コード補完機能は、本当に素晴らしいものです。」
• 「Xcodeのインターフェイス・ビルダは使い物になりません」
• 「Xcodeのインスツルメント機能は、プロファイリング、計測、デバッグに極めて有効です。」
• 「Androidエミュレータは完全なる時間の無駄です。その遅さときたら、ほとんど冗談のような代物です。私の開発サイクルでは、テストのため、常に実際のAndroidデバイスにデプロイしました―そのほうがずっと早いからです。」
• iOSシミュレータは「とても高速であり、開発サイクルをより効果的なものとしてくれました。新しいコードを追加するたびに、私はシミュレータでテストを開始し、実機に切り替えるのは一度きりで、それもずっと形式的なテストだけでした。」
• 「Androidでは、このアプリがサポート対象とする全てのバージョンのテスト用 Android デバイスを用意していました（ただしGingerbreadは除きます）、それから、デバイスのカバー率を十分なものにするため、後にはベータテスターの皆さんに大いに助けられました。」
• iOSでは彼はテスト用に、「サポート対象の最も古いデバイスと最も新しいデバイスを用いました」

アプリ設計

Henneke 氏は、Androidプラットフォームが「開発者が様々な寸法尺度をサポートするのを助けてくれる安定したコンポーネント」を有していることに気づいて、色々なスクリーンサイズ上で容易にUIをレイアウトできるようにアプリケーションを設計する計画を立てた。彼は RelativeLayoutを使ったが、「全てのレイアウトはXMLで指定されていて、実際にスクリーンを設計するのに非常にクリーンでシンプルかつ効果的な方法です ―　iOSのスクリーンレイアウトを作成した後に振り返ってみると、それは唯一文句なしに称賛できる Android の特徴でした。」と述べている。

この件に関して、我々は Henneke 氏に Androidのフラグメント化問題についてはどう考えるか尋ねてみた。

私はAndroidのフラグメント化は、騒がれすぎだと思います。それは存在するのでしょうか？ たしかに、それは事実でしょうが、それは必ずしも Android 開発の悪い側面なのでしょうか？ それは真実ではないと思います。 GoogleやAndroidコミュニテイは、この課題に対する様々なアプローチを行っており、それは役に立っています。 公式なサポートライブラリは十分に包括的ですし、つねに成長しています。また、ActionBarSherlock のような強力なサードパティのライブラリを使えば、古いデバイスにも新しい機能を与えることができます。 加えて、Google が最近導入した Google Play サービスによって、各キャリアは、フラグメント化問題から解放されます。ユーザは最新機能を使うために最新版のAndroid の入手をキャリアに頼る必要はもはやありません。これはAndroidのユーザや開発者にとって大きな前進です。

非常に興味深いことに、iOSでのレイアウト作成についてのHenneke氏の経験は、それほど良いものではなかったようだ。

Auto Layoutは、Apple版 の Relativelayout であり、最新版の機能（iOS 6から導入）ですが、Interface Builder(IB)との統合機能は恐ろしいほど無茶苦茶です。私は、iOS 6 の開発者の皆さんと同じように、何日も IB上でAutoLayoutと格闘しました、IBだけを使ってビューの正確な位置決めをしようとしましたが、IBの「スマート」システムが不明確なレイアウト規約を常に守ろうとして動作するため、私が指定した値を完全に変更してしまうのです。私は、IBのこの弱点を扱うための tips や トリック を全て学びましたが無駄でした。私は、最終的には全てのレイアウトをIBで扱うのをやめることでこの苦痛を終わりにし、何ページにもわたる定型的なコードを単純に手書きすることにしました。もし読者がIBやApple のゴリゴリの ASCIIアート風のレイアウトコーディングを避けるなら、Auto Layout の実装は、実は非常に強力で素直に使えるものになります。おそらく、Apple はこの点を iOS 7で大幅に改良するでしょうが、今のところ私はそれを試してはいません。

Auto Layout を使うということは、彼が以下で話しているように、古いバージョンには対応せず iOS6(iPhone4 と 5)だけに開発が限定されるということである。

GQueues アプリは実際、古い iOS デバイスにはインストールすることも動かすこともできません。私がそうしたデバイスでテストしなかった理由です。読者がモバイルアプリを開発するとき、最初のステップはどのバージョンのOSをサポートすることにするか決めることです。iOS 6 は、古いレイアウト技法よりも大きく改良された Auto Layout と呼ばれる新しい機能を導入しましたが、もちろんそれは、最新版のOSが稼働するデバイス上でのみ使えるものです。私は、古くて廃止予定の手法と Auto Layout を併用してレイアウトを作成する代わりに、 Auto Layoutだけを使うことを決断しました。これによって開発時間が劇的に短縮できるからです。このことはもちろん、GQueus アプリが iOS6デバイス上でしか動かないことを意味しますが、実際には過去２年間に購入された iOS デバイス全てがそこに含まれるのです。私は、２年以上前に iOS デバイスを入手した人は、とにかくすぐにOSをアップグレードするだろうと予想しました。実際、私の商売はこの件の影響を大して受けませんでした。

その他の設計に関する結論は次の通り：

• 「Androidでローテーションに対応するには、非常多くの作業が必要ですが、そのソースには多くのバグが存在しています。」
• 「Androidでは、デバイスをローテションしようとすれば、ローテーション完了時に、原則として全てのビューの階層を破棄して、それらを一つ一つ再構築しなければなりません。そのため、GQueues アプリをローテーション対応とするために、全ての状態情報がいつでも正しく保存され、かつ再開時にそれが再現されるように保証することが必要になりました。」
• 「（ローテーション対応で） iOSで はほんの少しの努力しか必要ありません。残りの作業はプラットフォームがやってくれるので」
• 「iOSでは、ローテーションに関するほとんど全ての事をプラットフォームが管理してくれます。」
• Android も iOSも、Flow レイアウトを模擬するためにはコードの追加が必要です。

ベータテストと配信（リリース）に関して、Henneke氏は以下のように述べている。

• 「オンボードのAndroidテスタ達は、自分たちのデバイスにダウンロードできるAPKへのリンクを容易に公開することができました。」
• 「Google は、デベロッパコンソールおよびステージング機能でアプリのα版やβ版をサポートすることにより、実際のユーザがアプリをテストするのをさらに容易にしました。」
• 「iOSのβテストは、TestFlightサービス―これはずいぶんと作業を簡単にしてくれます―を使用したにもかかわらず、かなり大変でした。Apple の『コントロール（＝開発者支配）』に対する飽くなき欲求を満たすため、テストに使う各デバイスのUDIDを、β版アプリに署名する際に使う証明書に加えておかなければなりません。そのため、βテスタを追加する必要が生じるたびに、それが一人であれ集団であれ、アプリの新しいビルドを作成しなおして配布しなければなりませんでした。それに加えて、Appleはテストデバイスの登録を毎年１００台までに制限しているので、私は注意深くテスタを配置しなければなりませんでした。このことが原因で、Androidのテスタ数にくらべてiOSでは半分しかテスタを使えませんでした。」
• 「Google Play上に GQueues アプリを投稿するのは、本当に楽しかったです。私は、そうしようと決めたらすぐにアプリを配信可能にできました。ボタンをクリックして３０分以内にアプリは全世界のGoogle Play 上に公開され、利用者は自分のデバイスにそれをインストールしつつありました。」
• 「Apple の App Store への登録は、iOS 開発者のほとんどのみなさんが同じことを言うと思いますが、がっかりするような体験でした。数ヶ月にわたる激しく、緻密なコーディング作業のあとに、私は自分の制作物をAppleに送し、レビューアがアプリを見るのに２分ほどを費やし、そしてほとんど儀礼的な最初のリジェクトを返すまでに７日間待つように強制さました。それから私は、一日かけて要求された修正を実施し、再度アプリを提出しましたが、最終的に審査を通過するのにさらに８日間待つことになったのです。」

Henneke 氏は、双方のプラットフォームでのデータストレージの使用と管理、検索、正規表現、ページング、音声入力、共有とウィジェットについて一連のノートを作成しており、それらは彼のブログ記事となっている。

結論として、Henneke氏は、それぞれのプラットフォームは「本当に強みがあって熟成された領域と、間違いなく何らかの改良が必要な別の側面」を持っており、どちらかが他方よりもより良いものだとは見なしていない。

iOSとAndroidにおいて、どの特徴に注目したいと思うか、我々は、再度Henneke氏に尋ねた。

iOSでは、私は、SIRIあるいは会話認識のAPIについて注目したいと思います。Androidでは、Google Nowとのより深い統合が今後本当に「クールな」ものになるでしょう。

最後に我々は、なぜ最初の段階でHTML5からネィテイブアプリに切り替えたのかを Henneke 氏に尋ねた。彼の経験では、HTML5はまだ早かったとのこと。

私は、以前はHTML5の公式な支持者だったので、ネィテイブアプリを作るという戦略の急激な変更について説明したブログ記事を書きました。簡単にいえば、HTML5はネィティブアプリに匹敵するような機能やスピードをいまだに提供できていません。加えて、良い悪いは別として、人々はマーケットプレースからアプリをダウンロードすることを好みます。GQueuesの利用者はネィティブアプリを必要としていたので、私はその要求を満たすことを目指したのです。

この記事は、AndroidとiOS双方に向けたアプリケーション開発についての、たった一人の個人の経験を反映したものにすぎず、各々のプラットフォームでの開発についての最終結論―特にどちらが良いのか悪いのかについて―を導きだすために一般化することはできない。とはいえ、Henneke氏の見解の多くは価値があり、２つのもっとも人気のあるプラットフォームでのモバイル開発にともなう喜びと悲しみを表現している。