Qiita を見る人は仕事だけでなく個人でアプリを作ったりしている人も多いと思いますが
リリースまでの細々したところってあまりノウハウが公開されてないような気がします。

最近勉強も兼ねて iPhone アプリを作ってみたのでその際にやったことをざっとまとめてみました。

概要

サーバに貯めこんであるデータを json 形式で取得してアプリ上に表示する。アプリとしてログイン機能を持っているものを開発する。

サーバサイド - 開発

今回は Rails の勉強も兼ねていたので BaaS は使いませんでした。

Rails

サーバAPIの設計

Rails を APIサーバとして使うのは少しおおげさかもしれませんが、将来的に Web 版も作ることも検討して Rails にします。ですが、Controller で json を返すようにすると、実装が複雑になる気がしたので（html(Web) と json(アプリ) で必要になるデータが変わることがありそうですし）、サーバAPI は Rails の Controller から分離することにしました。

サーバ API の実装に grape という gem を使用しました。参考にしたページはこちら。

gem の使用検討

基本的に有名なもの＆開発が活発なものを選ぶのがいいようです。そのあたりの情報は The Ruby Toolbox で見れます。下記のリンクは Rails の認証に関する gem について。

The Ruby Toolbox - Rails Authentication

定期処理

cron で実行したい処理は rake タスクとして実装して、whenever という gem で cron に登録しています。

参考にしたのはここ。
http://morizyun.github.io/blog/whenever-gem-rails-ruby-capistrano/

デプロイ関連

デプロイやアプリケーションサーバは Nginx + Unicorn + Capistrano の組み合わせに。
参考にしたページはこちら。

サーバサイド - インフラ

AWS

EC2 + RDS の構成。

インスタンスの Provisioning は Chef を使って、
* rbenv
* nginx

をインストール。nginx.cong は下記の通り。

nginx.conf

user nginx;
worker_processes 2;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;

events {
    worker_connections 1024;
}

http {
    upstream rails_upstream {
       server 127.0.0.1:3000;
    }
    server {
        listen 80 default_server;
        server_name _;
        default_type  application/octet-stream;
        sendfile        on;
        root /var/www/app/current/public;
        location / {
            include       /etc/nginx/mime.types;
            try_files $uri @unicorn_proxy;
        }

        location @unicorn_proxy {
            proxy_pass http://rails_upstream;
        }

    }
}

インスタンス選定

国内向けなら Tokyo リージョンで、まずは m3.medium 1台から始めてみようと思います。様子を見ながら変更していく予定。
まずは ELB 使わずに 1 台で。

＃最近 T2 という新しいインスタンスタイプが出てきました。

スモールスタートという意味ではこのタイプから始めてみてもいいかもしれません。

New Relic

パフォーマンスモニタリングなどができる＆無料でも使える＆導入が超簡単なので入れない理由がないと思います。

下記リンクからアカウント登録すると本来有料の Standard plan が無料で使えるようです。素敵。

クライアントサイド - 開発

明示的なログインをしない

アカウント作成をする際に Facebook/Twitter アカウントでのログインをやりたくはなるのですが、もうぶっちゃっけログインの作業自体めんどいですよね、使う側としては。

もちろんアプリの性質によりますが、ユーザーを識別できればいいだけならアプリの中でユニークな ID を生成して、ログイン用の ID にしてしまえばいいと思います。

NSString* devId = [[[UIDevice currentDevice] identifierForVendor] UUIDString];

・参考
http://www.atmarkit.co.jp/ait/articles/1211/06/news004_2.html

＃パズドラや黒猫など、ゲームの世界では明示的なログイン操作ってないですよね。

CocoaPods

少し凝った機能を実装しようと思ったら、コード書く前にまずは CocoaPods や Github にないか調べました。

だいたい Github に載っていたりすると思いますが採用するかどうかの基準に、

開発はまだ活発に行われているかどうか
Star の数

を参考にしました。

あとは下記のサイトも参考にしました。
CocoaPods Search

Jenkins + TestFlight

こちらの記事を参考にしました。
http://qiita.com/makoto_kw/items/b23350aed11ea87cd92b

何度も繰り返す作業で、自動化するためのコストが大きくないものはどんどんツールに任せるのがよさそうです。

また、友達に開発版を試してもらう場合は下記の URL を教えるとスムーズにテスター登録ができました。

クライアントサイド - リリース

iTunes Connect からアプリ審査の申請をします。

スクリーンキャプチャ

3.5inch と 4inch スクリーンキャプチャが必要です。手っ取り早いのはシミュレータ起動して Command + s 。

アプリ名

最初のリリース時にはできるだけシンプルなアプリ名にするのが無難です。注目を集めたいがために説明やキーワードをタイトル部分に混ぜ込むと下記のように「キーワードをアプリ名に含めるな」と怒られます。。

ですが App Store 上にはキーワードのようなものが含まれたアプリ名で登録されているものもあるので、アップデート時に少しずつキーワードを含めていくのがいい作戦かもしれません。

審査が終わるまで

だいたい１週間くらいかかるそうです。下記サイトでここ２週間の状況が分かります。

このサイトは twitter 上のハッシュタグ #iosreviewtime 付きのツイートに含まれる “X days” (where X is an integer) の値を見ているようです。リリース後につぶやくと集計してくれます。

本当は

テストとかパフォーマンス計測とかしっかりやらないといけないんだけど、ここで書けてない（そこがいい加減になってしまっている）のはダメなところですね。これから少しずつやっていこうと思います。

最後に

ということで作ってみました。iPhone アプリ「マンガ発売日カレンダーアプリ」。Qiita を見る人はマンガもたくさん読むと思うのでインストールしてみくださいｗ

iPhone アプリ(+ Rails)をリリースするまでにやったこと

概要