読者です 読者をやめる 読者になる 読者になる

LCL エンジニアブログ

夜行バス比較なび・格安移動を運営する 株式会社LCLのエンジニアブログ

Bitrise + GradleでAndroidアプリのCI環境構築

弊社では、Bitriseを利用してAndroidアプリのCI環境を構築しています。まだまだBitriseを利用している事例は少ないので、簡単にご紹介いたします。

なお、Bitriseを利用したiOSアプリのCI環境構築については、以下の記事で紹介しています。 techblog.lclco.com

前提条件

  • Gradle(gradlew)でビルドができること

初期設定

まずは、新規作成〜ビルド(apkの作成)までの手順を紹介いたします。

アプリの作成

Bitriseでは、まずビルド等の対象アプリを登録する必要があります。 [Add new app] をクリックすると、ウィザード画面が表示されます。

f:id:lcl-engineer:20161127155850p:plain

以下のマニュアルに沿って、進めればよいので詳細は割愛します。

Creating your first App on Bitrise · Bitrise

Workflowの作成

アプリ作成後のWorkflowはデフォルトでは、このような状態になっています。この時点で、ビルドに必要な基本的な流れは網羅しています。

f:id:lcl-engineer:20161127162140p:plain

Gradleで実行するタスクは、以下の箇所で設定します。

f:id:lcl-engineer:20161127162343p:plain

上記のテキストボックスにタスクを直接入力してもよいですが、GRADLE_TASKという環境変数に設定することもできます。

f:id:lcl-engineer:20161127162813p:plain

環境変数の設定画面で、ビルドタスクを入力します。複数のビルドを実行する場合は、半角スペースで区切りで入力します。

f:id:lcl-engineer:20161127162925p:plain

ビルドする

以上で設定は完了で、あとは[Start a build] ボタンでビルドが行えます。

f:id:lcl-engineer:20161127163227p:plain

BitriseでSigned APKを作成する

keystoreファイルをBitrise上に登録することで、リポジトリにkeystoreファイルを保存することなく、Signed APKを作成できます。

keystoreファイルの登録

Workflowの[Code signing & Files]メニューから、ファイルをアップロードします。

f:id:lcl-engineer:20161127164313p:plain

ファイルをアップロードするとパスワード等の情報の入力画面になります。 必要な情報を入力し、[Save metadata]で保存します。

f:id:lcl-engineer:20161127165232p:plain

この画面で登録した情報は、各項目に記載されている環境変数( $BITRISED_ANDROID_XXX)でアクセスできます。

File Downloader Stepの追加

Bitrise上に登録したkeystoreファイルは、ビルド時にダウンロードが必要です。その為に、File Downloaderというステップを追加します。

今回は、Git Clone の Stepの後に追加します。(Gradle の実行前ならどの場所でも良いはずです)

f:id:lcl-engineer:20161127170245p:plain

f:id:lcl-engineer:20161127170059p:plain

続いて、 File Downloader Stepへ変数を設定します。

  • Download source url には、 $BITRISEIO_ANDROID_KEYSTORE_URL を設定
  • Download destination pathには、任意パスを設定(ここでは、$HOME/keystores/release.jks を設定)

f:id:lcl-engineer:20161127170431p:plain

build.gradleの編集

Bitrise上で登録したkeystoreを利用するように、signingConfigsを書き換えます。

signingConfigs {
    release {
        keyAlias System.getenv("BITRISEIO_ANDROID_KEYSTORE_ALIAS")
        keyPassword System.getenv("BITRISEIO_ANDROID_KEYSTORE_PRIVATE_KEY_PASSWORD")
        storeFile file(System.getenv("HOME") + "/keystores/release.jks") // File Downloaderで指定したパス
        storePassword System.getenv("BITRISEIO_ANDROID_KEYSTORE_PASSWORD")
    }
}

以上で完了です。Gradleでリリースビルドを行うと、Signed APKが生成できます。

まとめ

Bitriseを使えば、単純なビルド環境だけならすぐに用意できます。無料プランもありますので、CI環境未構築の方は、最初のステップとして是非利用してみてください。

Hubot + Jenkins + Mackerelを利用したデプロイの見える化

弊社では最近、今更ながらHubotを利用したデプロイを行うようにしました。

なぜ今更ながら取り組んだのかも踏まえて、構成などを簡単に紹介いたします。

導入の背景

Hubot導入前は、以下のような流れでデプロイを行っていました。

  1. デプロイ担当者が、Google Analyticsのアクティブユーザを確認
  2. アクティブユーザが規定の数より少なければ、Jenkinsのビルドを手動で実行

この方法でも手間はそれほどかからないのですが、チーム・サービスの拡大によっていくつか問題が見えてきました。

ミスが起こりやすい

運営するサービス数の増加に伴い、Jenkinsのデプロイビルドも増えてきました。そうすると、弊社サービス「夜行バス比較なび」のデプロイをする際に、別サービス「格安移動」のデプロイビルドを実行してしまうなど単純なミスが発生するようになりました。

状況が見えない

最近リモートワークを行うメンバーが増え、Chatworkがコミュニケーションの主体となっています。そのため、前述のようなミスが発生したとき、以下のような状態になってました。

デプロイ担当: 夜行バス比較なびのデプロイします。
私: お願いします。
・・・
私: 格安移動のデプロイビルドが実行されているみたいですけど、間違ってないですか?
・・・
・・・
私: 大丈夫でしょうか?
・・・
デプロイ担当: 間違って実行してしまったので確認してましたが、特に悪影響ありませんでした。

この場合、リモートのメンバーは特に状況が見えづらく、不安になることが定期的に有りました。 このような問題から、ミスが発生しづらく・状況が見えるデプロイの仕組みへ変える必要があるとの考えに至りました。

デプロイ構成

f:id:lcl-engineer:20161024003432p:plain

  1. Chatworkでデプロイを命令を行う。
  2. Hubotがmackerelから現在のサイトのリクエスト数を取得する。
  3. HubotがJenkinsのデプロイビルドを実行する。
  4. Jenkinsが各サーバに対してデプロイを実行する。

各サイトのNginxのログは、エラー数の監視のためmackerelに随時送信しており、mackerel APIを利用してデプロイ時点でのリクエスト数を取得しています。リクエスト数が規定より多い場合は、デプロイを控えるようにしています

Chatworkでのやりとりは、以下のようになってます。

f:id:lcl-engineer:20161030172757p:plain

構築手順

Hubotのインストールや、基本的な利用法は割愛します。

ChatworkとHubotの連携

Chatwork APIを利用するためには申請が必要です。かれこれ2年以上プレビュー版ですが、問題なく使えます。以下のサイトから申請して、APIトークンを取得します。

チャットワークAPIドキュメント

ChatworkとHubotの連携は、adapterが用意されているのでそれを利用します。

npm install hubot-chatwork --save

環境変数にChatwork APIの情報を設定します。

# 取得したAPI TOKEN
export HUBOT_CHATWORK_TOKEN="XXXXXXXXXXXXXXXXX" 
# 監視するルームID。カンマ区切りで複数指定、botユーザをルームに所属させる必要あり。
export HUBOT_CHATWORK_ROOMS="111111,22222" 
# 1時間当たりのリクエスト数。APIは、5分間100回までの制限あり。
export HUBOT_CHATWORK_API_RATE="500"

以下のコマンドで実行。引数 -n でbot名称を設定

bin/hubot -a chatwork -n hubot

正しく設定が行われていれば、ping に応答があります。

f:id:lcl-engineer:20161030183455p:plain

mackerelとHubotの連携

事前に、Nginxのアクセスログをmackerelに投稿しておきます。

fluentdでサービスメトリックを投稿する - Mackerel ヘルプ

投稿したメトリクスは、APIで取得できます。

curl -X GET -H "X-Api-Key: <API_KEY>" "https://mackerel.io/api/v0/services/xxxxx/metrics?name=nginx_access_num.2xx_count&from=1476325055&to=1476325055"

サービスメトリック - Mackerel API ドキュメント (v0)

Hubotから直近の時刻を指定して上記APIを実行すれば、デプロイ時点でのアクセス数が取得できます。

JenkinsとHubotの連携

Jenkinsの認証を有効にしている場合は、以下の記事などを参考に外部からAPIを実行できるようにしておきます。弊社では、Hubot専用のユーザを作成し、限定されたビルドのみ実行を許可しています。

Jenkins のジョブを外部からビルドするには API Token を利用する - @kyanny's blog

HubotからJenkinsビルド実行は、以下のコードが利用できます。JOBのURLなど必要に応じて適宜修正します。

hubot-scripts/jenkins.coffee at master · github/hubot-scripts · GitHub

Jenkinsの情報は、Chatwork同様に環境変数に設定しておきます。

export HUBOT_JENKINS_URL="[JENKINS_URL]"
export HUBOT_JENKINS_AUTH="[ユーザID]:[パスワード or API TOKEN]"

以上でHubotと各サービスの連携は完了です。Hubotへの命令コマンドに応じて、適切な処理を組み合わせれば、デプロイまでの一連の流れが行えます。

導入の効果

見える化は、各自の行動にたよらず「強制的に見えるようにする」という仕組みづくりが重要ですが、以前までは、デプロイ担当者がチャットに状況を流していたので、結局は個々人による行動に依存していました。 今回、デプロイの全ての状況が"強制的に"チャット上に流れるようになったため、確実に見える仕組みが実現できました。

全ての流れが見えるようになったおかげで、まずデプロイが圧倒的にスムーズになりました。さらに、新しいメンバーでもどのようにデプロイが行われているかが、容易に把握できるようになりました。実際にやってみると、他にも応用したい案が多くでてきたので、今後もHubotを育てていきたいと考えています。

弊社では、エンジニアがより働きやすく・成長できる環境を日々検討していますので、ご興味がある方は是非採用ページからご応募お待ちしております。

株式会社LCL(エルシーエル)

LCLエンジニアのオフィス環境

f:id:lcl-engineer:20161015165208j:plain

弊社は、今年の8月に勝どきにあるトリトンスクエア 40Fにオフィスを移転しました。

移転してから2ヶ月ほどたちましたので、今回は新オフィスを簡単に紹介したいと思います。

景色

40Fだけあって、東京湾を一望できます。目を休めるためにも、たまに眺めてます。

f:id:lcl-engineer:20161014230926j:plain

f:id:lcl-engineer:20161014222939j:plain

カフェスペース

専用のカフェスペースがあり、KUREAという本格派のエスプレッソマシンが用意されています。

www.unimat-life.co.jp

エスプレッソ、カフェラテ、ココア、日本茶など、9種類のドリンクが誰でも飲み放題になってます。

f:id:lcl-engineer:20161014230917j:plain

近くにはくつろげるスペースがあり、ここにはコンセントも設置されているので、コーヒーを飲みながら気分転換に仕事をしているメンバーも多くいます。

f:id:lcl-engineer:20161014230932j:plain

ミーティングスペース

用途に応じて、ミーティング場所が選べるように、色々なタイプのミーティングスペースを用意しています。

こちらは会議室タイプで、主に来客用として利用しています。会議室でミーティングをすると、どうしても会議時間が長くなりがちなので、社内の打ち合わせではなるべく利用しないようにしています。

f:id:lcl-engineer:20161014230922j:plain

こちらは,執務室内にある打ち合わせコーナーです。予約不要で使いたいときにすぐに使えるため、多くの打ち合わせはここで行っています。他にも同タイプの打ち合わせが3つほどあります。

f:id:lcl-engineer:20161017005556p:plain

リラックスして打ち合わせできる土足禁止エリアもあります。ブレスト的な打ち合わせをする場合は、大体この場所でやってます。

MTG以外にもノートPCでリラックスしながらプログラミングをしたり、昼休みには各自が読書したりなどにも活用されています。

f:id:lcl-engineer:20161016004921j:plain

執務エリア

執務エリアは一般的な島形式の配置にしています。 背中合わせでメンバーを配置することで、何かあったときに簡単に相談できるようにしています。

また、移動式のテレビモニタも配備しています。 Applet TVが接続されており、各メンバーのディスプレイをすぐに映せるため、簡単な確認・共有は移動せずこの場所で行っています。 ( エンジニアPCは全員Macです)

f:id:lcl-engineer:20161018090201p:plain

一人あたりのエリアは、iMac27インチと25インチディスプレイを配置してもまだ余裕があるぐらい広く確保されています。

f:id:lcl-engineer:20161017235536j:plain

集中したいときに、周囲から遮断できるブースも設けています。集中してドキュメントをまとめ上げるなど、普段とは異なるタスクを行うときに、この場所を利用することが多いです。

f:id:lcl-engineer:20161017235224j:plain

最後に

新オフィスのご紹介をしましたが、仕事をする上では働き方・仕事内容がより重要だとも考えております。

弊社では、エンジニアがより働きやすく・成長できる環境を日々検討していますので、ご興味がある方は是非採用ページからご応募お待ちしております。

株式会社LCL(エルシーエル)

pgpool-IIでストリーミング・レプリケーションへ対応する

以下の記事に続いて、pgpool-II+ストリーミング・レプリケーション構成について紹介致します。 (だいぶ時間が空いてしまいましたが。。)

pgpool-II 入門(インストールと簡易設定) - LCL エンジニアブログ

説明に利用する環境

  • PostgreSQL 9.4
  • pgpool-II 3.5.2

pgpool-IIのストリーミング・レプリケーション対応

ストリーミング・レプリケーション自体は、Web上で有用な記事が多く出てきているので説明を割愛します。特に以下の記事を参考にさせていただきました。

pgpool-IIをストリーミング・レプリケーションへ対応するには、pgpool.confを次のように設定します。

load_balance_modeをonにします。

load_balance_mode = on

master_slave_modをonにし、master_slave_sub_modeをstreamに指定します。

master_slave_mode = on
master_slave_sub_mode = 'stream'

backend_hostnameに各DBサーバの接続情報を設定します。

backend_hostname0 = '192.168.56.100'
backend_port0 = 5432
backend_weight0 = 5
backend_flag0 = 'ALLOW_TO_FAILOVER'

上記がDBサーバ1台分の接続情報のセットです。 末尾の数字を1,2,3と増やしていくことで、接続させるDBサーバを増やすことができます。

backend_weightで指定した値が、SQLを振り分ける比率となります。 例えば、以下のように設定すると、5:6:7の比率で振り分けが行われます。

backend_hostname0 = '192.168.56.100'
backend_weight0 = 5

backend_hostname1 = '192.168.56.101'
backend_weight1 = 6

backend_hostname2 = '192.168.56.102'
backend_weight2 = 7

上記で一通りの設定は完了です。

pgpool-IIを起動し、pgpool_statusファイルを確認すると、各ノードへの接続ステータスが確認できます。 設定したノードの行数だけステータスが表示され、全て「up」になっていれば正常です。

# cat /var/log/pgpool/pgpool_status
up
up
up

md5認証への対応

PostgreSQLの認証に md5認証を利用していると、pgpool-II側で更に追加設定が必要となります。

まず、pgpoo.confのenable_pool_hbaをonにします。

enable_pool_hba = on

pg_md5というコマンドで、認証ファイルを生成します。 usernameの引数には、PostgreSQLへ接続するユーザ・パスワードを指定します。

pg_md5 --md5auth --username=test password

実行すると、pool_passwdファイルが生成されます。

#  cat /etc/pgpool-II/pool_passwd
test:md587f77988ccb5aa917c93201ba314fcd4

続いて、pool_hba.confにPostgreSQLへの接続情報を定義します。

host    testdb           test         127.0.0.1/32       md5
host    testdb           test         ::1/128               md5

以上で完了です。

まとめ

pgpool-IIでのストリーミングレプリケーション対応には、今回紹介しなかった「オンラインリカバリ」など他に有用な機能がありますので、より詳しく知りたい人は公式マニュアルもご参照ください。

Webブラウザへのプッシュ通知はpushnateを使うと簡単

フロントエンドエンジニアの岡田です。先月のHTML5 Conferenceに参加してから、プッシュ通知を試したくてしかたがなかったのですが、ようやくまとまった時間が取れたので試してみました。

最初は、Webサイトからプッシュ通知を送ろう! JavaScriptでのプッシュ通知の実装方法 - ICS MEDIAを参考に進めていましたが、今はGoogleの設定画面も微妙に違うようで、なかなかうまくいきません。 そこで記事の最後に5分ほどで導入できるとあったpushnateを試してみました。 しかし初心者にはそこまでスムーズには設定できなかったので、スクリーンショット付きで解説します。 なお、以下はすべて無料で使えました。(2016/09/30時点の情報です)

Webブラウザへのプッシュ通知とは

事前に許可したユーザー宛に、サイト運営者の任意のタイミングで通知を送ることができます。ユーザーがページを開いている必要はないので、運営サイトへの訪問を促す仕組みとして使えます。対応ブラウザが限られていて、デスクトップのChromeやFirefoxでは使えますが、スマホのiOSでは動作しないので注意が必要です。

対応ブラウザでは、以下のような通知が届きます。(Mac Google Chromeの場合)
f:id:lcl-engineer:20161006235433p:plain
今回は、弊社で使っている勤怠システムのプッシュ通知を作ってみました。

前提

プッシュ通知を送るためには、サーバーがSSLに対応している必要があります。 pushnateを使う場合は、「共有ドメイン型」を選択すればSSL非対応のサーバーでも設置できます。ただ、プッシュ通知内に表示されるドメインがpushnate.comになります

設定方法

  1. pushnateの会員登録をする
  2. pushnateの「設置方法」ページからSDKをダウンロード f:id:lcl-engineer:20161002235335p:plain
  3. 別タブでGoogle Firebase Consoleを開き、アプリを登録
  4. Google Firebase Consoleで新規プロジェクトを作成f:id:lcl-engineer:20161001093548p:plain
  5. 「ウェブアプリに Firebase を追加」を選択してf:id:lcl-engineer:20161001093913p:plain スニペットを表示しておく(「apiKey」と「messagingSenderId」を使います) f:id:lcl-engineer:20161007004028p:plain
  6. pushnateに戻り、「サイト設定」ページで、情報を入力 f:id:lcl-engineer:20161007004056p:plain Google API KEYには、5で表示したスニペット中の「apiKey」を使います
  7. 2でダウンロードしたSDKファイルの中のmanifest.jsonを編集 f:id:lcl-engineer:20161002222314p:plain gcm_sender_id部分に5で表示したスニペット中の「messagingSenderId」を貼り付け
  8. pushnateの「設置方法」ページ下のサンプルコードを参考に「プッシュ通知設定用ページ」を作成
    ※ サンプルコードそのままで動きます。必要であれば文言等を変えます。 f:id:lcl-engineer:20161001102231p:plain

  9. SDKファイル2つと、8で作成した「プッシュ通知設定用ページ」をルート直下に設置
    /manifest.json
    /pushnateSDK.js
    /index.html (設定画面)

  10. 9でサーバーにアップした「プッシュ通知設定用ページ」をブラウザで開いて「設定する」ボタンを押す f:id:lcl-engineer:20161001133443p:plain すると以下のようなボックスが表示されます(Google Chromeの場合) f:id:lcl-engineer:20161001143331p:plain

  11. pushnateで新規プッシュ通知登録 f:id:lcl-engineer:20161002235642p:plain ※いろいろな種類のプッシュ通知を設定できますが、有効にできるのは1つのようです

以上です。
やっぱり5分では難しそうですが… でも確実に楽です。

あと、この設定が終わると、Webサイトからプッシュ通知を送ろう! JavaScriptでのプッシュ通知の実装方法 - ICS MEDIAの方も動くようになっていました。Google Firebase Consoleを登録すると動くようです。

ESLintでnot definedが出るときに確認すること

フロントエンドエンジニアの岡田です。
弊社では現在、フロントエンド環境の見直し中です。

現在はjQueryが中心ですが、サービスを運用しながら、少しずつ以下の環境へ移行していく予定です。

Webpack + babel + ESLint(Airbnb)+ ES6 + React

ひとまず開発環境はできて、徐々に置き換え作業を進めているところなのですが、ESLintの以下のエラーが解消できず放置していました。

error  '$' is not defined  no-undef
error  'window' is not defined  no-undef

他のエラーが片付いてきたので調べたところ、.eslintrcファイルを以下のようにすると解消しました。

{
  "extends": "airbnb",
  "env": {
    "browser": true,
    "jquery" : true
  },
}

※envにbrowserとjqueryを追加しています。

上記の設定は、package.jsonでもできるようです。 eslint.org

フロントエンドエンジニアをしていると忘れてしまいますが、JavaScriptはブラウザ以外でも動く時代なんですよね。 jQueryは廃止予定ですが、残したほうが楽な部分もあるかもしれないので、まだ残しています。

以上です。 誰かのお役に立てば幸いです。

2016年 新規iOSアプリ開発で採用した技術・プロセス

弊社では、2016年07月に「高速バス比較」というiOSアプリをリリースしました。

www.bushikaku.net

リリースして1ヶ月ほどたちましたので、本記事では、今回の開発で採用した技術・ツール・プロセスを一通りご紹介します。

言語

Swift 2.2を採用しています。

サポートiOSバージョン

iOS 8.0 以上をサポートしています。

利用ユーザ数や開発生産性を考慮し、iOS 8.0未満は対象外にすることにしました。

リリース後1ヶ月の時点では、iOS 8.X系でご利用いただいているユーザは 5%弱ですので、当面はiOS 8.X系はサポート対象に入れておいたほうが良いと考えてます。

ライブラリ

ライブラリ管理には、CocoaPods , Carthage を利用しています。

主要なライブラリとしては、次のようなものを利用しています。

  • HTTP通信
    • Alamofire
  • 画像ダウンロード
    • SDWebImage
  • データ永続化
    • realm
  • ローディング表示
    • SVProgressHUD
  • カレンダー
    • FSCalendar

FSCalendarは、カレンダー関係のロジックを実装する必要がなく楽なのですが、制約が厳しくデザイン上あまり凝ったことはできません。 弊社アプリはカレンダーが、UIとして重要なパーツのため、かなりカスタマイズをしてデザインを変更しました。 ただ、今となってはデザインが重要な場合はFSCalendarは利用せず、自作したほうがよかったと判断しています。

f:id:lcl-engineer:20160824170952p:plain

ブランチ運用

ブランチ運用は、Git Flowを利用しています。 以下の記事を参考にさせていただいています。

iOSアプリ開発のGit運用 · hikarock blog

ビルド・テスト配布

iOSアプリ開発において、良いサービスを早く作り上げていくためには、開発の初期段階でのビルド・テスト配布の自動化は必須だと思っています。ビルド・テスト配布が手動の場合は、どうしてもある程度まとまった単位でのテスト配布となってしまい、フィードバックサイクルが長くなってしまいます。

弊社では、ビルド・テスト配布の自動化は、fastlane + Crashlytics(fabric) + Bitrise を利用し、1日に何度もテストアプリを配布し、短いサイクルでフィードバックを回しています。

各種サービスの詳細や、環境によるアプリの使い分けは以下の記事で紹介しています。

techblog.lclco.com techblog.lclco.com

クラッシュ監視

どれだけ入念にテストを実施しても、クラッシュは発生してしまいますので、クラッシュ監視のサービスは導入必須だと考えています。

現在は、以下のクラッシュ監視サービスを利用しています。

  • Crashlytics
  • bugsnag

テスト配布アプリにも仕込んでおくことで、テスト中に発生したクラッシュを即把握できるので、テスト担当者からわざわざ詳細な報告を受ける必要がありません。また、発生したクラッシュを元にすぐIssueを作成でき、クラッシュ検知 → Issue作成 → 修正という流れが開発者のみで完結できます。

ログ

アプリ起動、主要なボタン操作のタイミングでログを取得しています。以下の項目をサーバ側に随時送信し、サーバ側のデータベースに格納するようにしています。

  • 端末種類 ( iphone 5s,6sなど)
  • iOSバージョン
  • アプリバージョン
  • 任意パラメータ (JSON)

PUSH通知

PUSH通知サービス

PUSH通知は、Amazon Simple Notification Service (SNS) を利用しています。

数あるサービスのなかから、以下の理由でSNSを選定しています。

  • コストが圧倒的に安い
  • 開封率などの分析・セグメント別配信などほぼ全て自前での実装になるが、将来的に発生する可能性がある要件に柔軟に対応できる

SNSのノウハウについては、Gunosyさんの資料がとても参考になりました。

900万ダウンロードアプリ『Gunosy』を支える大規模モバイルプッシュ通知基盤 // Speaker Deck

証明書

PUSH関連の証明書はややこしいので、こちらは完全にfastlaneを頼ってます。

fastlane pemで、iOSのPUSH通知用証明書を自動生成する - LCL 開発者ブログ

AppStore 申請

AppStoreの申請に必要な文言・スクリーンショットは、fastlane deliverを利用して登録しています。

手動でも大きな手間ではありませんが、各種情報をGit管理でき確実に反映できるのが利点です。

fastlane/deliver at master · fastlane/fastlane · GitHub

UIプロトタイプ

Prottを利用しました。

iPhone実機にProttアプリを入れると、実際のアプリに近いイメージでプロトタイプが確認できるので、早い段階でのUIブラッシュアップが可能です。

ただし、他のツールの調査が不十分ですので、継続して良い物を探していきたいと考えてます。

アクセス解析

今のところは、GTMを利用して、Google Analyticsのみを利用している状態です。この辺りも引き続き必要に応じて、他のサービスの導入を考えています。

iOSアプリ(Swift)へのGTM導入 & TIPS - LCL 開発者ブログ

まとめ

今回の新規アプリ開発で採用している技術について紹介しました。 現時点では、できるだけ広く利用している技術を選定しましたが、アプリ界隈はどんどん新しいサービスが出てくるので、うまく見極めてよいものは導入していきたいと考えてます。