私がここ2週間ほどごりごりと作っていたiPhone用ねとらじプレーヤーLadio Tail for iPhone 1.0が昨日App Storeで公開された。
Macをメイン環境に据えてから数年たつものの、Objective-C・XCodeには触ったこともなかった私がApp Storeにアプリを公開するまでの課程をざっと記す。
なお、本ソフトはMIT Licenseのオープンソースとしてgithubに公開しています。
アプリケーションなのでフォークして改善したり、参考にしたりはしにくいとは思いますが一応。
前提・目的
- C言語やC++、Javaなどいくつかの言語についてはそこそこ扱える
- Androidアプリは作ったことあり。これもねとらじ関係のアプリですが、Google Playストアで公開しています。
- Macでの開発経験はなくObjective-Cを使って何かを作ったことはない
- Objective-Cのような動的型のオブジェクト指向でメッセージパッシングにより動作するような言語をがっつり扱ったことはない
- もっぱらクライアントサイドのソフトウェア開発ばかりやっていた。サーバサイドプログラミングについては詳しくは無い。
なので、XCodeとObjective-Cをクリアすれば「ねとらじプレーヤーくらいなら何とでもなるんでね？」という算段だった。
iOSプログラミングの習得自体が目的なので、他プラットフォームで作ったことのあった「ねとらじプレーヤー」をとりあえず作ってみることとした。
なぜねとらじプレーヤーなのか
過去にもWindows Mobile向け（W-ZERO3なんか向け）にPocketLadioとPocketLadio::Deux、Android用にLadio Tail for Androidを作っているくらい、おまえはいっつも「ねとらじプレーヤー」ばっかり作ってんなといわれそうなんですけれども。
ねとらじプレーヤーを作ることにしたのは、
- ねとらじがモバイル向けプレーヤーアプリを作っていないこと
- ねとらじがプレーヤーアプリ開発者のために配信中の番組情報をテキスト形式で公開していること。プレーヤーのための開発情報も公開し、サードパーティーにプレーヤーアプリの作成を推奨している。
- かつ、その番組表がHTTPでアクセスするだけで簡単に取得できること
- Twitterなどもアプリ開発者向けにタイムラインを公開しているけれど、アプリ作成するためにTwitterに申請が必要だったり、アプリ側に認証の仕組みを組み込まなければならないので面倒
- 最近ではそういう認証周りのオープンなライブラリがあるけれど、作っている上で意外と引っかかったりするので
- 認証がないサービスでもタイムラインの情報が公開されていない場合があり、その際はウェブサイトからHTMLを取得し解析したりしたりなんてこともするのだけれど、サイトのデザイン変更に追従しなければならないため面倒
- そしてそういうサービスに限って、後になってサイトのHTMLを解析すんなとか言い出すんだよ
- プレーヤー側で必要なのは、HTTPへのアクセス、簡単なテキストの解析（正規表現を用いた）、取得した情報のUIへの展開、オーディオのストリーム再生程度と、技術的にさして難しくないこと
と、新しいプラットフォームの開発作法を覚えるのを目的にするには適当な粒度だから。サーバもサービスも用意しなくていいし。
なので、C#やらAndroidなんかでも一通りの開発作法を覚えるのに適当なので、いっつも「ねとらじプレーヤー」作っているんですけれども。
iPhone用の「ねとらじプレーヤー」としては、かわうそさんのらじおぱ（85円）、 @jp_chips_potate さんのnrPlayer（無料）に続く後発だが気にしない！ 機能的にもこれらより優れているところがないけれど気にしない！
らじおぱにもnrPlayerにも不満あったりしたわけでもないのですけれども。
なぜObjective-Cでのネイティブ開発なのか
Ladio Tail for iPhoneは、Objective-Cによるフルスクラッチから開発を始めている。
ねとらじプレーヤーなら、iOS/Androidのクロスプラットフォーム開発環境であるTitanium MobileやPhoneGap、または純粋にHTML5だけでも十分に開発が可能だ。
極端な速度が求められるアプリでもなし、わざわざiPhone向けにObjective-Cでネイティブに作るまでもなく、これらプラットフォームでも充分すぎるプレーヤーが開発可能だろう。
そういう意味ではXCodeとObjective-Cを覚えるよりも、HTML5とJavaScriptを覚える方がいいともいえるのだが、iOSではどのようなアプリを作るべきなのか、iOSでどのようなUIが良いとされるのか、AppleはiOSの上で何を考えているのかということを垣間見てみるにはやはり純正の開発環境を触ってみるしかないというのが、今回Objective-Cでのネイティブ開発に至った理由である。
それぞれの開発環境にはそれぞれの思想がある。
iOSアプリを作るならApple純正の開発環境をまず触ってみるのが適当ではないかと個人的には思う。
サードパーティーの開発環境なんぞその後でも充分だ。（純正の開発環境がファッキンな場合は除く）
あと個人的にHTMLはあまり好きじゃないのよね。JavaScriptはそうでもないのだけれど。
開発のために用意したもの
- Mac。手持ちのMac Proを使用した。
- 必須ではないが、iPhoneなりのiOSが動く実機。手持ちのiPhone 4Sを使用した。
- 必須ではないが、iOS Developer Program加入料（年額8,400円）
iOSアプリの開発にはどうしてもMacが必要。
Androidアプリの開発環境はWindows・Mac OSX・Linuxに対応しており、かつ無料なので、いわゆるパソコンがあれば充分なのに比べ（Androidアプリの開発環境は重いので大きめのメモリが必要なのだけれど）、Macを用意しなければならないというハードルがある。
Titanium MobileやPhoneGapでもiOSアプリを作ろうとしたら、多分Macはいるんじゃないかな。
iOSアプリの開発環境であるXCodeはMac App Storeから無料でダウンロードできる。
XCodeにはiPhone Simulatorが付属するので、カメラやGPSや加速度センサを使う場合を除いてiOSのアプリ開発iPhoneは必須ではない。
iPhone/iPad/iPod touchで動かしたい場合には、実機に加え、iOS Developer Programに登録する必要があるのでさらに年額8,400円が必要。
個人だと、アプリがマネタイズ可能でない場合には微妙に心理的なハードルがある金額だ（と思う）。
まぁでもシミュレータで動くもの作ったら、実機でも動かしたくなる衝動にはなかなかあらがえないと思う。
開発の前に参考にした資料
恥ずかしながら、iOSやCocoa、Objectve-Cに関する手持ちの書籍を数えてみたら古いものも含め15冊もあったんですけれど、ぶっちゃけそれだけ今までiOSアプリ開発に挫折してきたわけで。
挫折というか15冊のうち半分くらいには過去に目を通しているのに、どうも手を動かす気になれなかったというか。
荻原本についてはiPhoneが世の中に出る前に、興味からObjective-C Mac OS Xプログラミングを読みObjective-Cのおもしろさに触れて以来（この頃、日本語で書かれたObjective-Cの書籍は荻原本しかなかったように思う。今はいろいろあるけれど。）、詳解 Objective-C 2.0、詳解 Objective-C 2.0 改訂版、詳解 Objective-C 2.0 第3版と、新版が出るたびに買っていた。
大学の先生が書いた言語解説の本が個人的に好きというのもあるのだけれど、表層的な説明だけに終始せずに内容も踏み込んでおり、iOSアプリの開発においては鉄板。
私がLadio Tail for iPhoneを開発し始めるにあたって、どれだけその内容を覚えていたかというと微妙なところだし、未だに本書の中で読んでいない部分も多いのだけれど。
他にGUIまわりと処理の連携部分の作り方を学ぶにあたって何らかの書籍が必要になってくるかなとも思ったが、XCodeのバージョンが上がるたびにiOSアプリのGUIの作り方がころころ変わるらしく（特にXCode 4.2を境に大きく変わっているようだ）、書籍の情報がどうも古そうだということがわかり、結局アップルの初めてのiOSアプリケーションだけで済ませてしまった。
このドキュメントはあくまでGUIとコードの連携部分の雰囲気をつかめるという程度の内容だが、他のプラットフォームで何らかのアプリを開発したことがあれば一読し手を動かしておけばておけばあとは実践で覚えていけると思う。
コーディング中に参考にした資料
Foundationフレームワーク（文字列とかリストとか連想配列とかのクラス）の基礎的な内容については荻原本の9章にあるので当初はそれを参照した。
もちろんAppleのリファレンスを参照する必要も出てくるのだけれど、これ英語だし、最初くらい日本語で読みたいよね。
コーディング指針については荻原本の巻末と、Google Objective-Cスタイルガイドの日本語訳を参照。
ブログなどウェブ上のサンプルコードではインスタンス変数名やメソッド名の先頭がアンダーバーのものが結構あるが、荻原本によると接頭語がアンダーバーのクラス名なりはAppleが予約しているようなので、接頭語がアンダーバーを用いるのはどうもいけないことらしい。注意されたし。
Googleのスタイルガイドの日本語訳は、ざっと読めるわりに実用的なのでおすすめ。
コーディング指針については、AppleのCoding Guidelines for Cocoa: Introduction to Coding Guidelines for Cocoaを読めって話もあるが、上記2つで必要分はカバーしてそうだったので目も通してません。すいません。
インスタンス変数の変数名やsynthesizeにアンダーバーをつけるべきかどうかについては、上記では特に言及がなかった（と思う）し、単純なインスタンス変数名（tableViewとかね）だとdelegateの引数なんかと結構ぶつかるので、正直どうしたものかという思いがあったのだが、Naming Conventions for Instance Variables and Properties « Dave Meehanを参考にしつつ、接尾語にアンダーバーをつけることにした。
この記事では接頭語にアンダーバーをつけているが、荻原本によるとそれはマズそうだったので。
iPhone Simulatorについて
当初は実機を用いずiPhone Simulator上のみで開発。
ねとらじプレーヤー程度ならiPhone Simulator上の機能だけで間に合うし、SDKの基本的な部分しか使っていたいため、iPhone Simulator上で動作したコードを実機向けにコンパイルしなおしても非互換は起こらないだろうというもくろみもあったので。
（後になって実機で動作させてみたところ特に問題なく動いている。）
iPhone Simulator向けにコンパイルすると、どうもx86バイナリがはき出され、iPhone Simulator上でそのままネイティブに動作しているようだ。
AndroidエミュレータではQEMUを用いARM環境をエミュレーションし、その上でさらにDalvik仮想マシンを通してでアプリを動作させているので、それと比べだいぶ速い。
（Androidエミュレータは、ARMエミュレーションとその上でDalvik仮想マシンが動いているという、アプリから見て2重のレイヤーがあるわりには相当早いと思うけれど。）
Androidエミュレータも最近速くなったのだけれど、ネイティブ動作するiPhone Simulatorとアプリには及ばない。
iOSアプリの開発をやってみるまではAndroidエミュレータでも充分じゃないかと思っていたけれど、やはりアプリを試しに実行してみる環境の速度が速いと心が軽い。Androidエミュレータもいらいらするほど遅いわけじゃないんだけれどね。
うちの環境でiPhone Simulatorを動かした範囲ではiPhone 4S実機よりも動作が機敏だったりするので、実機で試したときにはぽこぽこ出てたバグもiPhone Simulator上では遭遇しなかったなんてこともあったくらい。
加えてiPhone Simulatorではマウスによる操作のため、実機ほど機敏な操作ができず、連打タップなんかが原因で発生するバグにもiPhone Simulator上で開発していたときには気づけなかったということがあった。
大丈夫だろと思いロック処理していなかった（最悪だ！）私が悪いんですけれどもね。
Objective-Cは特殊な言語か？
iOSアプリやOSXアプリを開発する上でObjective-Cは避けて通れないが、基本的な部分でC言語の流れを汲んでいるとはいえ、クラス周りの記述がSmalltalkの影響を受けていることもあって、おもむきも見た目もC++やJavaなんかとはだいぶ異なる。
メソッドの実行も実行時に解決していたり、メソッドが実装されているかを返す構文があったり、既存のクラスのメソッドを書き換えたりメソッドを追加したりできたりなど、こんな柔らかい言語で整合性のちゃんとしたもの作れるのかなという心配は当初少なからずあった。
が、実際やってみると意外とできるもので、むしろJavaに比べてがっつりやらなくていいだけ手数が減っているように思う。
Objective-Cの構文も慣れるまではキツいかなと思っていたが、実際やってみるとすぐに慣れ違和感を感じなくなった。
未だに[]の数があっているかどうかはそこそこ気を遣うが、数や位置を間違ってもコンパイルが通らないだけで、間違った位置に[]をつけることで意図しない動作をするわけでもないので、コーディング中にそこまで神経質になることもない。
Objective-Cを扱う上でFoundationフレームワークの感覚になじむかどうかが言語上のいちばんの心配だったのだが、意外にも感覚的にJavaのライブラリに近く（あくまで感覚的にだが）、Objective-Cのサンプルコードを見て何がやりたいのかを理解するのにあまり苦労しなかった。
名前空間とインナークラスがないことが不満といえば不満だが、多分すぐこんなもんだと思える。
正直なところObjective-Cの導入がiOSアプリ開発の最大のハードルになるかなと考えていたが、実際のところたいしたこと無かった。
Objective-Cだからという理由でiOSアプリ開発に食指の伸びない開発者とかいそうだけれど（私がそうだった）、全然イケるよ！
Objective-Cのメモリ管理について
Ladio Tail for iPhoneの開発では、Mac OSX Lion/iOS 5から導入されたARCに完全に依存した。
ARCならば循環参照に気をつけておけばいいくらい（と理解している）で、メモリの解放処理を明示的に書く必要がない。
retainとreleaseを自分で書けといわれていたら挫折していたと思う。
ARCの概要については、ARCでめちゃモテiOSプログラマーを参考のこと。
XCodeについて
XCodeはバージョンごとにいろいろ変わっていたりするせいもあって、ウェブ上の情報が以前のバージョンを元に書かれているので使えないということが多々あった。
特にXCode 4.2から導入されたStoryBoardについて解説しているところが少なく、GUIまわりはウェブを検索してなんとか動作するところまでこぎ着けた感はどうしても強い。
また、最新版であるXCode 4.3の書籍がないのもちょっと痛い。
そういうところがクリアできてくれば、XCode自体はとてもよくできている開発環境だ。
開発環境特有のワケのわからなさは適度に隠蔽されているし、XCodeという開発環境にもAppleのデザインがいい意味で生きていると思う。
Androidの開発環境がクソだといわれても私はあまりピンと来ていなかったのだが、XCodeを触ったあとだとそういいたくなる気持ちも分からないではない。
また、メソッドごとの処理時間をやメモリの使用量やリークを計測したりするプロファイラがとても使いやすかった。
この手の計測環境は別途購入が必要だったり、使い始めるまでのハードルが異様に高かったりするのが定石なのだが、前提知識なしに使えてしまったことには本当にびっくりした。UIもGarage Bandライクだしね。
Ladio Tail for iPhone程度の規模ならばこの手の計測ツールは必要無いと思っていたのだけれど、手軽に使えるとなると使ってしまうし、実際にいくつかのボトルネックを発見して性能改善もできた。
私のように実行性能に興味の薄いタイプだと、全体を通してみると気づかずに遅い処理や無駄な処理をしてしまっているということが多々あると思うのだが、どこが悪かったかを数値で示されるとさすがに改善しようと反省するし。
XCodeを扱う上で参考にしたのが、キーボードで完結！ハイスピード Xcodeコーディング。まだ全然覚えられていないが。
XCodeの代替環境であるAppCodeも若干触ったが、割引期間を逃してしまったので結局購入せずじまいになってしまった。
clangとlldbがデフォルト採用されていた
XCode 4.3からはコンパイラにはclangが、デバッガにはlldbがデフォルトになっていた。
どちらもアップルが強く推進するオープンソースのプロジェクトであるが、gcc/gdbではなくclang/lldbをデフォルト採用したのにはびっくり。
clangは2010年にセルフホスティングに達し、現在までにFreeBSDのコンパイル・Boostのコンパイル・Linuxカーネルのコンパイルができるくらいには開発が進んでいるのだけれど、これだけ影響のあるプロダクトへの採用は初めてではないだろうか。
個人的には好きですけどねclang。
ハードルが高かったiOS Developer Program登録と実機での動作、App Storeへの登録
上記のように開発自体については当初想像していたよりもすんなりと進んだのだが、アプリ公開まででいちばん引っかかったのがiOS Developer Program登録と実機での動作、App Storeへの登録、iAdネットワークの有効化のあたり。
この辺は皆さんやはり引っかかるようで、ググれば関連情報がいっぱい出てくる。
メモが残っている限りだが、私が参照したのは下記のサイト。
開発で困ったら
とりあえずググれ。アプリ作り始めた程度のレベルなら結構解決する。
Stack Overflowにはずいぶんお世話になった。
iOS絡みに困ったときに探してるといつもここにたどり着く。Androidでも困ったらここに辿り着くんだけれど。
英語サイトだがたいていの回答にはサンプルコードも付いているし、内容も開発関係のことに終始するので分からないということもそんなにないはず。
ググった感じウェブ上にあるAndroidの開発ノウハウ情報よりもiOSのそれの方が多いように感じる。あくまで体感的にだけれど。
iOSはアプリ開発のみに限定されるのに対し、Androidはアプリ開発以外にもこれから家電やらキオスク端末的な何かやらに普及が見込まれており、市場もそっちに動いていることもあって、少なくとも国内ではAndroid開発者の方がずっと多いように個人的には推測しているのだが。
App Storeに申請してから
Ladio Tail for iPhoneをApp Storeに申請したのが4月18日の午前1時（日本時間）、申請が通ったのが24日の午前11時なので、申請から公開になるまで6日かかっている。
聞いた話によると、この日数は以前よりも伸びているらしい。
公開まで1週間ほど見ておく必要がありそうだ。
アプリのデザインについて
最後にアプリのデザインについて。
ねとらじから放送中の番組を取得し、その情報を画面上に表示して、選択された放送を再生するだけならば1日あればできる。
Objective-C/XCodeに触ったことなかった私でも1日でこれらはできていたのだが、そこからはほとんどを細かいUIの調整に費やしてしまった。
iPhone上で見ているとUIの細かいところが気になってくるので、フォントを1ポイント大きくしてみたりだの画像を1ピクセルうえにもっていってみたりだのしていた。
そういう作業は好きではないのだが、iPhoneの上で見ながら作り込んで行っていると不思議と苦ではない。
その辺もiPhoneの魅力がなせることなのだろう。
最後に
昨日、Ladio Tail for iPhone 1.1（次バージョン）を申請に出しました。
レビューが通れば1週間後くらいに公開されると思います。
荻原 剛志
ソフトバンククリエイティブ
売り上げランキング: 6407
