“AndroidとiOS、どっちを先にやるか?”という、スタートアップにとって永遠の問いは、ますます難問になってきた。Androidのマーケットシェアが80%を超えた、というニュースがあったからだ。でも、経営者や非技術系のファウンダはさておき、かんじんのデベロッパ! デベロッパ!は、この対立をどう考えているのか？ どちらが、デベロッパの人生にとって有利か？
実はぼくも、デベロッパの一人だ。本誌の記事（や小説）を書いていないときは、ぼくはHappyFunCorpのソフトウェアエンジニアだ。世界でもっとも良い名前のコンサルタント企業であり、Webサイトだ（クリックしてみて）。最近は管理職的な仕事が多くなっているが、プログラミングを忘れたくないので、ちょっとした個人的なプロジェクトをAndroid用とiOS用両方を作って、それをオープンソースにした。以下はそのときの経験に基づく、両プラットホームの比較論だ。
ぼく自身の経歴としては、これまで数多くのAndroidアプリとiOSアプリを作ってきた。仕事と、個人的なプロジェクトの両方だ。たとえば、ぼくの好きなニュースアグリゲータScanvine用に作ったネイティブクライアントは、ソーシャルメディア上で異様に広く共有されている記事を見つける。そのソースコードはGithubにあり: (Android | iOS) 、アプリ本体もダウンロードできる: (Google Play | App Store)。
比較論を始める前に、Xamarinのクロスプラットホームな開発ツールに言及しておくべきだろう。ぼく自身も、もしも自分がC#プログラマで、JavaやObjective-Cを知らない人間だったら、モバイルアプリの開発のためには、これを選んでいたと思う。
それにまた、今回のプロジェクトは、商用製品ではなくて、個人的に楽しむためのプログラミングだ。だから、テスト用のコードがない。だからiOSのハイゼンバグは、今でも手作業で調べている。サードパーティのライブラリも、gitのサブモジュールにせずに、ファイルをコピペしている。今は直したけど、Androidのビルドでレイアウトファイルにバグがあって、タブレットがクラッシュしたこともある。
では、前置きはこれぐらいにして、二頭の馬たちのゲートを開こう。さあ、走れ！
環境
コードをテキストファイルに書いて、コマンドラインでビルドすることは、今でも可能だがしかし統合開発環境(integrated development environment, IDE)を使った方が生産性は高い。
AppleはXcodeだ。使っていて楽しいし、すっきりしてるし（ごたごたの逆）、速いし、強力だし、出しゃばらないヘルプが良い。AppleはiOSのアプリやデバイスを厳しく管理するために、奇妙で独特なコンパイラと、被害妄想的な証明/プロファイリングの仕組みを持っているが、それらはXcodeの快適な外見の下に隠されている。デバッガはシームレスだし、シミュレータは速くて応答性が良い。
Androidは、ほぼ標準のIDEがEclipse ＋ Androidプラグインだが、こいつが厄介者だ。遅い、ぎくしゃくしている、分かりにくい、そしてときにはまったく不可解。レイアウトが悪い、不必要に複雑、そして混乱。デバッガーがドジなので、ぼくはログファイルを見ながらデバッグをしている。Xcodeのデバッガは、まさに、頼りになるデバッガだ。Androidのエミュレータもひどくて、立ち上げに数分かかるし、Android Debug Bridgeに接続できないことが、とても多い。
ツイート訳: [Androidの仮想デバイスを使って開発している人なんかいるの？ なんで、立ち上げに10分もかかるんだよ？]
そこでGoogleは、独自のIDE Android Studioを提供するつもりでいるが、しかし:
Android Studioは現在、初期的なプレビューバージョン(early access preview)です。まだ不完全な機能や未実装の機能があり、バグもあります。未完成の製品を使いたくない方は、代わりにADT Bundle(Eclipse ＋ ADTプラグイン)をお使いください。
GoogleがAndroid Studioを鋭意開発中なのはよろしいが、ぼくが最初のAndroid携帯を買ってからほぼ5年になるのに、まともな開発環境がまだないとは、どーゆーこっちゃ？
勝者: 大差でiOS。
構成
上で述べたように、Xcodeの外見はすっきりシームレスだが、その下にはObjective-Cという、70年代のプログラミングの恐怖を彷彿とさせる怪獣が眠っている。おおげさかもしれないが、そう言いたくなる。マクロ、ヘッダファイル、プロジェクト、ターゲット、スキーム、そしてビルドのコンフィギュレーション（構成）。ビルドの設定だけでも、うんざりしてくる。不可解なリンカエラーが出ると、絶望あるのみ。そして、こんな発見: “あら、きみのサードパーティコードはARCをサポートしていないの？ じゃあフラグ-fno-objc-arcを加えるんだよ。簡単だろ？”。
Androidではマニフェストファイルが一つあるだけで、アプリのビルドはEclipse が完全にやってくれる（正常時は）。ファイルを保存したらビルドは自動的に行われる。パーミッションの構成ミスでアプリが動かないときに出るエラーメッセージは、もっと分かりやすくしてほしいが、それはそんなに重大な問題ではない。とにかく、ビルドのための構成はAndroidの方が概してシンプル、そしてエレガントだ。
勝者: Android。
UXデザイン
勝者は当然Apple、とみなさんお思いだろう。Interface Builderを使うと、きれいなユーザインタフェイスを簡単に手早く指定できる。でもぼく的には、Interface Builderを使えば使うほど、嫌いになった。ここでもまた、構成が面倒なのだ。最初は単純で楽ちんでも、その後のアプリの進化とともに、世界はぐちゃぐちゃになっていく。とくに、Appleが1年前に加えた、マルチスクリーンのStoryboardsは、すごーく、好きくないね。
Androidのビジュアルツールもまあまあだが、それについて、あまり言うべきことはない。なにしろAndroidは製品の種類が多様で画面サイズもまちまちだから、UIをそのすべてに正しく対応させるために、レイアウトの指定をXMLファイルで書く（AppleのAuto Layoutも、今後のiOS製品の画面の多様さに対応するための仕掛けだろう）。なお、Androidではアイコンパックが提供されているが、iOSではIcons8のようなサードパーティ製品を使うか、または自作する。
意外にも‘Apple圧勝’とはいかなかった。ちょっと奇妙な結果ではある。しかし、iOSは幸運にも製品種類がとても少ないから、デベロッパの苦労も少ない。それにiOSのデフォルトのUI部品は、デザインがおおむね美しい。この二点で、iOSが有利だ。
勝者: iOS。
言語
AndroidのアプリはJavaで書く。iOSのアプリはObjective-Cで書く。その例外は、Xamarin（前述）を使うとき。ただしツールによってはマイナーな例外があるし、PhoneGapのようなネイティブ/Webのハイブリッドもある。しかし一般的には、AndroidはJava、iOSはObjective-Cでネイティブアプリを書く。
ぼくがプログラミングをやり始めたときの言語がJavaだったから、最初はObjective-Cに馴染めなかった。とくに、書く量が多すぎる、と思った。
Javaなら:
String s2 = s1.replace(“abc”,”xyz”);
Objective-Cでは:
NSString *s2 = [s1 stringByReplacingOccurrencesOfString:@"abc" withString:@"xyz"];
でも、その後だんだんとObjective-Cが大好きになった。Javaよりもクリーンな、良い言語だ。Objective-Cにはブロック〔ブロック構文〕があり、Javaにはない。Objective-Cにはカテゴリー〔カテゴリ〕があり、Javaにはない。Javaでは大量の例外処理（try/catch節）を義務的に書かなければならないが、Objective-Cにはそれがない。
Javaにも、良い点はある。たとえばスタックトレースが良くできているので、散発的な（起きたり起きなかったりする）バグの原因を見つけやすい。2年前までは、ガーベッジコレクションではAndroidが断然優位だった。今ではiOSにautomatic reference counting（ARC（前述））があるので、Javaの優位は薄れた（ただし古いサードパーティのツールはARCをサポートしていないのでXCodeの構成で苦労しないといけない）。この点でJavaの優位はなくなったので、勝者はObjective-Cで決まりだ。
勝者: iOS.
API
AndroidもiOSもライブラリの規模は大きく、その内容は互いに似ている。電話機能、ネットワークアクセス、多様なViewオブジェクト…その中にはブラウザそのものとも言える強力なWebViewがある。実際の仕事は、コントローラの中で行う…iOSではViewController、AndroidではActivity。
iOSにあってAndroidにないものは、一連の機能集、フレームワークだ。たとえばiOSの強力なCore Dataフレームワークに相当するものは、Androidにない。またiOSのAPIの方がよりクリーンでありシステムとしての設計も良い。ぼくのアプリでは、iOSの場合、これとこれ、二つのかなりシンプルなクラスが仕事の大半を行うが、Androidではこれとこれとこれ、計三つのクラスが同じことをする。そしてこれらは、10個近い内部クラスや無名クラスを使用している。結局のところ、iOSのCollectionViewControllerの方がAndroidのListAdapterよりも使いやすい。
あまり客観性はないが、ぼくのこのアプリの自作コードはiOS版が1596行、Android版が2109行だ（Java ＋ XML）。32%もの差がある。
勝者: iOS.
インターネット
今ではほとんどのアプリが、スタンドアロンのプログラムではなく、多かれ少なかれインターネットに依存している。だからここでは、それほどまでに重要なインターネット機能を比較しよう。インターネットに関して、ツールやAPIは両プラットホームとも、たいへん多い。どちらも、互いによく似たWebViewsがあるので、どのアプリにも完全なブラウザウィンドウを置くことができる。
ネットワークへの接続は基本的にバックグラウンドで動く処理であり、アプリの本流の邪魔をしない。しかし、このようなマルチスレディング(multithreading, 処理の多重化並列化)は難しい。Androidが提供しているAsyncTaskクラスは、大きいが良い仕事をする。今オンラインかどうかをとても容易に判定できるための、便利な方法もある。iOSにも同様の機能はあるが、どれもかなり低レベルで、不満足なものだ。
しかしながら、オープンソースのライブラリがたくさんあるから、それらを使えば苦労はない。ぼくはAFNetworkingを使ったが、作者が言ってるとおりの、良質なフレームワークだ。Webのリクエストが完了したら動かしてほしいコードのブロックを、渡すだけだ。ブロック構文（前述）のないJavaでは、それはできない。
勝者: ネイティブではAndroid、サードパーティのライブラリも含めるとiOS。
共有
アプリから容易にFacebookやTwitterやEvernoteなどで共有できるか？ AndroidにはIntentという強力なアプリ間コミュニケーションシステムが前からあるから、第一ラウンドでAndroidのノックアウト勝ちだ、とぼくは思った。一般的に言っても、複数のアプリ間のデータ共有機能は、Androidの方が優れている。
でも、きわめてふつうの共有機能では、Appleもかなり追いついている。というか、これは読者ご自身が判断していただきたい。ぼくのアプリScanvineの、Androidの共有コードはこれ、iOSのコードはこれだ。iOSのコードがやや長いのは、Google Analyticsでちょっと余計なことをしているためだ。こいつは、直したい。
勝者: 引き分け。
分裂
こいつは、簡単。Androidはこう。iOSはこう。証明終。Googleがおもしろい統一策を実装中だから、この話題は再訪の価値があるかもしれない。
勝者: iOS.
発表
Androidアプリは、世の中に発表することが、うそみたいにやさしい。Eclipseには便利なアプリ登録ウィザードがある。どのデバイスでも動くAPKファイルを、あなたは作った（はず）。それを、メールしてもよい、Webサイトに載せてもよい、Google Playにアップロードしたらたちまち、全世界があなたの市場になる。最高にシンプルだ。インストール時のログデータとクラッシュ報告を見る。スタックトレースを見れば、問題のコードがどこか分かる。すぐにバグフィクスして再びアップロードすればよい。
Appleのアプリは、発表が悪夢だ。頭の良いぼくの友人は、iOSアプリを開発するときは通常のスケジュールに最低でも1日足せ、とアドバイスする。証明とか配布プロファイルと苦戦するための時間だ。何度やっても、それにXCodeの最新バージョンがどんなにそのための努力をしていても、それはつねに、でっかい苦労だ。TestFlightがあるから、ややましだが、アプリのテストも厳しい。そしてAppleの”iTunes Connect”WebサイトとGoogle PlayのDeveloper Console（デベロッパコンソール）は、Ford Pinto vs. Teslaだ。クラッシュレポートがもらえたら、ついてる方。だいたい、ろくな情報は得られない。彼らの、デベロッパに対する恣意的な態度は、こうなったら楽しむしかない。そしてAppleのUXのひどさに、感嘆するのだ。
勝者: 大差でAndroid。
そして優勝は…
僅差でiOSだ。Androidにも良い点はあるが、良いiOSアプリを書くことと、良いAndroidアプリを書くことを比べると、前者の方が相当にやさしい。今でも。それにAndroidユーザはお金持ちで周囲への影響力もあるから、大ウケをねらうスタートアップは、最初にiOS、Androidは後で、で行くのが理にかなっている。Android Studio IDEは、差をやや縮めるかもしれないが、まだ横並びにはならないだろう。
（なお、ぼくの日常のメインの携帯はNexus 4だ。しかも、すごく満足している。）
画像クレジット: Jennifer Stolzer, DeviantArt。
〔訳注: この記事はコメントが166もあり（日本時間11月19日18時現在）、参考になるコメントも多いので、この記事をより相対的に読むためにはコメントも読むことをおすすめします（Twitter上の関連ツイートは961件あります）。以下に、今はEclipseじゃなくてIntellij、という正論を書いていると思われるコメントを一つだけ訳出（抄訳）しておきます（GoogleのAndroid StudioはIntellij（の無料版）がベースです）。〕
＜コメント訳開始＞
ちょいと、こいつは露骨に偏った記事だよ。詳しく書いてる時間がないから、Eclipseが標準IDE説を、ここでは取り上げよう。前からJavaをやってる人なら、Intellijを知ってるだろう（Android Studioはまだバグが多くてだめだけど）。GoogleがEclipseを見捨てたのも、当然だ。Androidデベロッパも、だいぶ前から、すでにIntellijを使ってる人が多い。また、エミュレータはとっくに誰も使っていない。あまりにも、ひどいから。今はほとんどの人が、デバイスそのもの、またはx86エミュレータ、またはGenymotionなどを使っている。今更一体誰がSamsung Realityなんか検討するの？
【後略】— from kpgalligan
＜コメント訳終了＞
[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）
