はじめに

株式会社withでiOSエンジニアをやっている　@PictoMki　です!
withのiOSチームでFirebaseCrashlyticsを使用して導入している仕組みがあるのですが、
数ヶ月運用してみて、導入効果を少し実感できたので紹介させていただきます!

※こちらの記事(Carefully Unwrapping)は姉妹記事になります。

背景

Carefully Unwrappingの登場

元の背景としてはwithアプリにて特定の条件によってクラッシュが起き始めたことがきっかけになります。
直接の原因としてはForce Unwrappingによるものだったので、上記の記事であるCarefully Unwrappingが登場しました。

Carefully Unwrappingの概要

nilでない場合は通常通りアンラップする
nilの場合はCrashlyticsにerrorを送信するかつデフォルト値を渡してアンラップする
詳しくははじめにの記事をお読みください

こちらの導入により、安全にアンラップできるかつ意図しないデータが渡された場合は
Crashlyticsに送信されるようになったため、早期発見できるようになりました。

LogicErrorの登場

Carefully Unwrappingの導入によりアンラップ時の意図しない挙動は築けるようになりましたが、
以下の問題点がありました。

アンラップの時しか使えない
- guardを使っている部分にも使いたい
- if文でアプリの仕様と異なる動きをしている部分にも使いたい
オプショナルの型が決まっていない場合にデフォルト値を設定しづらい
- classの継承を意識しなければいけなくなってしまう
デフォルト値でアプリが正常に動作し続けられないかもしれない

上記を解決するために登場したのが今回のLogicErrorになります。

実装

LogicError

LogicError.swift

import Foundation
import FirebaseCrashlytics

/// ロジックエラーが発生したときに呼び出すと、Crashlyticsにエラー情報を通知した上で、デバッグ環境であればクラッシュさせる。
/// （assertionFailure(_ description: )のラッパー的メソッド）
public func logicError(_ description: String? = nil, needsCrashOnDevelopEnvironment: Bool = true, originFilePath: String = #file, originFileLine: Int = #line, originMethodName: String = #function) {
    let error = LogicError(description: description,
                           originFilePath: originFilePath,
                           originFileLine: originFileLine,
                           originMethodName: originMethodName)
    let infoDic: [String: Any]? = {
        if let _description = error.description {
            // CrashlyticsがDictionary型を求めるので適当なキーでDictionary化
            return ["value": _description]
        } else {
            return nil
        }
    }()
    let nsError: NSError = {
        let tempError = error as NSError
        return NSError(domain: tempError.domain,
                       code: tempError.code,
                       userInfo: infoDic)
    }()
    Crashlytics.crashlytics().record(error: nsError)

    // 開発環境でクラッシュさせたくない時は呼び出し側で制御する
    if needsCrashOnDevelopEnvironment {
        assertionFailure(description ?? "")
    }
}

/// ロジックエラーの発生を雑にFirebaseに通知するためのエラー型。
/// loginError()に渡すと、Crashlyticsにエラーの発生箇所、説明文が記録される。
///
/// 例)
/// ```
/// guard idx < list.count else {
///     loginError("範囲外へのアクセス")
///     return
/// }
/// list[idx]
/// ```
private struct LogicError: Error {

    init(description: String? = nil, originFilePath: String = #file, originFileLine: Int = #line, originMethodName: String = #function) {
        self.description = description
        self.originFilePath = originFilePath
        self.originFileLine = originFileLine
        self.originMethodName = originMethodName
    }

    var _domain: String {
        let originFileName: String = originFilePath.components(separatedBy: "/").last ?? originFilePath
        return "\(String(describing: Self.self))(\(originFileName):\(originFileLine) >>> \(originMethodName))"
    }

    let description: String?
    let originFilePath: String
    let originFileLine: Int
    let originMethodName: String
}

使い方

.swift

let compNumber: Int = 11

// if文などのロジックで使う
if compNumber > 10 {
    logicError("compNumberが10より大きい compNumber:\(compNumber)")
}

var nilNumber: Int?

// アンラップの時に使う
if let number = nilNumber {
    print(number)
} else {
    logicError("nilNumberがnil")
}

// guard文で使う
guard let number = nilNumber else {
    logicError("nilNumberがnil")
    return
}
print(number)

上記のようにアンラップ時だけではなく、より柔軟にCrashlyticsへのエラー通知が行えるようになりました。

エラー確認

一覧での確認

今回テストプロジェクトにてAppDelegate.swiftの34行目と35行目で試しにlogicErrorを起こしました。

上記の画像にようにファイル名、行数、実行関数が一覧にてわかります。

詳細にて内容確認

上記のように値が取れるようになります。

iOSチームでの運用

私たちのチームではissue棚卸し会という名目で、
定期的にチームメンバーでCrashlyticsを見る機会を作っています。

Crashlyticsの中で発生件数が多いものに関しては、Github issueを用いてissue化し
Crashlyticsにメモを残し、時間がある時に調査と修正を行っています。(logicError以外のエラーも含む)

↓メモ

具体的な事例は今回提示できないのですが、再現手順が難しくユーザー環境で起こるエラーの
問題の切り分けにlogicErrorが役立っています！

課題

特に大きな課題感はないのですが、将来的には以下のようなことは起こり得るかなと思います。

課題1. logicErrorが増えると見るのが大変

気軽に追加できるのでlogicErrorの件数が増えると、
Crashlyticsの一覧がlogicErrorに占領されてしまうケースが発生してしまう可能性があります。

解決策として、以下を考えています。

logicError判別用のカスタムキーを追加する
一覧にvalueの値(nilNumberがnil)を表示する(現在は行数、クラス、関数を表示)

現状は特にlogicErrorに支配されているわけではないので、
増えてきた場合には上記の対策を取ろうと思います。

課題2. 同じlogicErrorが重複する可能性

現在のlogicErrorの実装的にファイル名、行数、関数が同じ箇所でのlogicErrorを同じエラーとして認識して記録されるため、
コード改修を行った場合は同じエラーが別のエラーとして記録されるようになってしまいます。

こちらについてはlogicErrorによって多く検出されたものに関して長い間放置するわけではないので、
コード改修が起こる前にlogicErrorが起きる箇所は直していくため、今のところは特に課題感は感じていないです。

将来的に追い切れないくらい重複してしまう場合は検討が必要かなと思います。

最後に

今回はチームで行っているCrashlytics運用のtipsを紹介しました。
今後もサービスの改善に向けてチーム一同精進していきます。