TestFlight has moved.とのことなのでひと月ぐらい前から移行先を検討していて、各社の動向を探りつつ(ネットウォッチで)どのプラットフォームに我々の未来を託すべきか・・と熟考した末。全く記憶から消していて昨日いきなり思い出してやばいと思ってどれでもいいからとすぐに移行した。
Crashlyticsはクラッシュレポートを収集する組込みSDKを提供していたサービスなんだけどFabric - Twitter's Mobile Development Platformの一部になって(デプロイツールでもフリマアプリでもない)
「Beta by Crashlytics」というモジュールも追加されたのでこれがTestFlightの代替になる。利用は個人でもビジネスでも無償。
ユビレジではクラッシュレポート分析にCrittercismを利用しているのでCrashlytics SDKは組み込んでいないんだけど(Crittercism > Crashlytics と評価しているわけでもなく。そもそもクラッシュ頻度が少なくCoreDataやUIKit深部のなぞエラーばかり来る)
ベータ配信は実質的に Crashlytics.framework の内部コマンドにIPA形式のファイルとAPIトークンを渡せばできるので、アプリケーションにリンクする必要はなかった。
セットアップは基本的にCrashlytics公式のガイドに従っていくとコンプリートできるようにはなっているんだけど。ちょっとめんどくさいのがFabric, Crashlytics, Twitterのそれぞれのアカウントを使ってセットアップするところが非常にわかりづらかった。これはFabricプラットフォーム自体が整備されたら改善しそう。
またAPIトークンを手に入れるにも一度 Fabric.framework という別物のSDKを組込み作業をMacのXcodeとGUIのセットアップフローでこなす必要があった。個人的にはまわりくどくてめんどくさいと思っていたが、「設定が簡単で気が効いている」という声も結構あるようだ。実際Fabricチームの作るWebアプリのGUIはよくできていると思った。
具体的にやったことはまず、ユビレジアプリはDistributionまわりは可能な限り自働化してあり。Travis-CIをテスト実行だけでなくリモートのOS X上で好きな処理を実行できる汎用のMacマシンとして活用しているので。その過程で肥大化していったRakefileをXCJobsという名前でgem化していて。これに組込めるようなものを想定して
notes = 'notes.txt' # リリースノートのテキストファイル group = 'Dev' # Crashlytics上で設定したグループ名 command = %[./Frameworks/Crashlytics.framework/submit #{FABRIC_API_KEY} #{FABRIC_API_SECRET} -ipaPath #{File.join(BUILD_DIR, "#{SCHEME}.ipa")} -groupAliases #{group} -notesPath #{notes} -notifications YES] # YES でメール通知 sh command do |ok, res| puts res fail 'Submit to Crashlytics-Beta has failed' unless ok end
Beta Distribution with iOS build servers – Support for Crashlytics を参考に。
みたいなことをするRakeタスクを定義してTravis-CI上からアップロードしている。Crashlytics自体Fabricの過渡期に巻き込まれてこれからどんどん変わっていきそうなので、方法とかドキュメントとかが落ち着いてきたら見直そうと思っている。xcjobs-0.0.7でもできるようになった(README参照)
APIキーは https://fabric.io/settings/organizations からリンクを辿るとこのへんからも取得できる。
注意点としてはCocoaPodsでインストールできる Crashlytics.framework はオフィシャルのものではなく有志がメンテしている感じなのでFabricのサーバーからダウンロードできるバイナリと比べると古いバージョンだということがあった。そのため上記のセットアップフローを手動で最後までやってFrameworkをまずダウンロードしてくる必要がある。
https://fabric.io/downloads/xcode
ライブラリの選定基準
今回のように「こういうことを実現したいのでライブラリの力を借りる必要がある」というケースに結構出会す。
以前はその界隈の最新の流行のものをとか自分が気に入っているもの、みたいな基準で選んでいたのだけど最近は「1年後のメンテナに恨まれない選択(なぜならこころがつらいから)」という至極後ろ向きな視点を心掛けているので
Vue.js が辛くなってきた | status code 51
とかも結構共感する。
これは良い面をみると経験を積んで長期的で安定で保守的な思考になっているというといわれはいいんだけど、ずばり老いと筋力の低下が影響して公平な判断ができなくなっているんだと予想している。
つまり、ライブラリを選定する立場の人やシステムアーキテクトに必要なのは強靭な肉体。自重トレをしろ。