By | 2014年11月6日

logo

Bugsnag という Crash レポート解析サービスがあるんですが、最近 Crashlytics から乗り換えたので、なぜ変えたのかをツラツラと書いていこうかなと思います。
実際 Bugsnag じゃなくてもこのような機能があるサービスの方が個人的には使い勝手がいいかなと思います。

Bugsnag は$29/monthかかります

なぜ Crashlytics から移行しようとしたのか

Crashlytics は便利なんでずっと使ってるんですけど、 Crash した場合にしかレポートを送信することができないのが一番の不満(※Fabric で改善されているかもしれません)

このあとに言及しますが、Social.framework 等を利用した場合のエラーを集めたかったんですけど、そのために Crash しないといけないとか、ありえませんし。なのでそれを取得するために自分でエラー情報を集めようとして、API を用意したりしてたんですけどアプリが増えると管理も億劫になるし、なにより情報が分散してしまうせいで管理にしづらいので乗り換えることにしました。

なぜ Bugsnag に移行したのか

任意のタイミングでレポートを送信できる

さきほど少しふれましたがこれが一番重要な機能です。なぜなら端末側の設定や状況によるエラーを取得したいからです。

例えばアプリのサインインに SNS(Twitter, Facebook等) を認証に利用している場合や IAP (In-App Purchase)など、エラーの原因が端末側でしか分からない場合があります。画面には「失敗しました」などのエラー文言を表示して終わっていることが大半だと思います。

この場合、端末やユーザーの状態に依存した場合もあるし、何が原因で起きたのかが判断できないケースが多いのでデバッグするのは正直不可能です。エラー情報(NSError や NSException や API のレスポンス)があるかないかで全然違うので取得しておきたかったわけです。

Xcode 上でビルドする際にソフトウェアをインストール、設定する必要がない

Bugsnag の場合、dSYM の送信等は Run Script Phase で行っています。

デバッグしようとして気軽に試そうとしたら、Crashlytics のソフトウェアをインストールし設定しておかないとビルドできません。まぁソフトウェアの方が Crashlytics が柔軟にメンテナンスできたりするのも分かるんですけど、とはいえ初期セットアップの工程を減らしたい思いもあります。

Bugnag SDK が Github 上で公開されている

なんだかんだでソースコードが公開されてることがとてもよかったです。意図した挙動をしない時などソースコードみればどうとなりますし、バグをふんでも自分でなおして PR おくればいいので、これは本当によかったです。

あって便利だなと思ったもの

CocoaPods で SDK を管理できる

リポジトリに入れて管理するわけではないので、バージョン管理がしやすい。

iOS のみでなく Application や他のプラットフォームのエラーレポートを一元管理できる

API や Android のレポートを同じサービスで集約して管理できるのは便利ですね

Github に issue をおこせる

ボタンひとつで issue を作成することができます。これがとても便利!
issue を close すると Bugsnag へも連携して…とかはできませんが、ただ作るだけでも相当便利です。

Adhoc や Release など Build Configuration によって分けられる

あるにこしたことがないですけど、この機能がなくても Adhoc 配布の場合は拙作の dealforest/DFTDebugScreenshot をつかえば、気軽に Adhock で配布した際の情報をを集めることができます。

Adhock 配布時の効率的なデバッグについて考えてみた」辺りが参考になります。

まとめ

今のところ Bugsnag で満足しています。Bugsnag 以外でも他に良さそうなサービスがあったら教えてください。
ではでは。

Posted in ios | Tagged