Firebase vs Supabase
Googleの包括的モバイルプラットフォームFirebaseと、オープンソースのPostgreSQL代替Supabaseが対決。Backend-as-a-Service選定の際に何を優先すべきか?
Googleが提供する無料・軽量なクラッシュトラッキングSDK
エラートラッキング+パフォーマンス+セッションリプレイを一つのプラットフォームに統合、セルフホストも可能
明確な基準:「アプリがいつクラッシュしたか」だけを知りたく、予算がゼロならCrashlytics一択です—導入は数分で終わり、請求リスクもありません。エラー・パフォーマンス・セッションリプレイを一つのダッシュボードで管理したい、あるいは法令上データを自社インフラに保持する必要があるならSentryの守備範囲がそのコストに見合います。多くのチームは両方を併用していますが、その道を選ぶなら二重SDKがアプリサイズと起動時間に与える影響を自分のビルドで必ず測定してください。
| カテゴリー | Firebase Crashlytics | Sentry |
|---|---|---|
| パフォーマンス | 7/10 | 9/10 |
| 学習のしやすさ | 9/10 | 6/10 |
| エコシステム | 6/10 | 9/10 |
| コミュニティ | 8/10 | 8/10 |
| 求人市場 | 6/10 | 7/10 |
| 将来性 | 7/10 | 8/10 |
// Firebase Crashlytics - Android (Kotlin) セットアップとnon-fatalロギング
// build.gradle.kts (app)
// plugins { id("com.google.gms.google-services"); id("com.google.firebase.crashlytics") }
// dependencies { implementation(platform("com.google.firebase:firebase-bom:34.19.0"))
// implementation("com.google.firebase:firebase-crashlytics") }
import com.google.firebase.Firebase
import com.google.firebase.crashlytics.crashlytics
import com.google.firebase.crashlytics.setCustomKeys
class CheckoutViewModel {
private val crashlytics = Firebase.crashlytics
fun onPaymentStarted(orderId: String, amount: Double) {
// Breadcrumb: クラッシュ発生時にどのステップにいたか把握するため
crashlytics.log("payment_started order=$orderId amount=$amount")
crashlytics.setCustomKeys {
key("order_id", orderId)
key("payment_amount", amount)
key("user_tier", "premium")
}
}
fun onPaymentFailed(error: Throwable, orderId: String) {
// アプリをクラッシュさせずにエラーを記録(non-fatal)
crashlytics.setCustomKey("order_id", orderId)
crashlytics.recordException(error)
}
fun identifyUser(userId: String) {
crashlytics.setUserId(userId)
}
}
// AndroidManifest.xml: firebase_crashlytics_collection_enabled=false(同意取得後に有効化)
// Runtime: Firebase.crashlytics.setCrashlyticsCollectionEnabled(true)// Sentry - iOS (Swift): エラー+パフォーマンス+セッションリプレイを単一SDKで
// Package.swift / SPM: https://github.com/getsentry/sentry-cocoa
import Sentry
func configureSentry() {
SentrySDK.start { options in
options.dsn = "https://<public-key>@o<org-id>.ingest.sentry.io/<project-id>"
options.debug = false
// パフォーマンストレーシング
options.tracesSampleRate = 0.2
// UI Profiling (sentry-cocoa 9.x): trace のライフサイクルに連動
options.configureProfiling = {
$0.lifecycle = .trace
$0.sessionSampleRate = 1.0
}
// Session Replay: クラッシュ前の画面遷移を記録
options.sessionReplay.onErrorSampleRate = 1.0
options.sessionReplay.sessionSampleRate = 0.1
// エラー発生時にスクリーンショット+ビュー階層を添付
options.attachScreenshot = true
options.attachViewHierarchy = true
}
}
// Breadcrumb + カスタムコンテキスト + non-fatalキャプチャ
func onPaymentFailed(_ error: Error, orderId: String) {
let crumb = Breadcrumb(level: .error, category: "payment")
crumb.message = "payment_failed order=\(orderId)"
SentrySDK.addBreadcrumb(crumb)
SentrySDK.configureScope { scope in
scope.setTag(value: orderId, key: "order_id")
scope.setUser(User(userId: "u_123"))
}
SentrySDK.capture(error: error)
}
// dSYM自動アップロード (Xcode Run Script Build Phase):
// sentry-cli debug-files upload --include-sources "$DWARF_DSYM_FOLDER_PATH"明確な基準:「アプリがいつクラッシュしたか」だけを知りたく、予算がゼロならCrashlytics一択です—導入は数分で終わり、請求リスクもありません。エラー・パフォーマンス・セッションリプレイを一つのダッシュボードで管理したい、あるいは法令上データを自社インフラに保持する必要があるならSentryの守備範囲がそのコストに見合います。多くのチームは両方を併用していますが、その道を選ぶなら二重SDKがアプリサイズと起動時間に与える影響を自分のビルドで必ず測定してください。
無料相談を受けるクラッシュの追跡だけで十分で予算をゼロに抑えたいならCrashlytics、エラー追跡に加えてパフォーマンストレーシングやセッションリプレイ、必要に応じてセルフホストも求めるチームにはSentryが適しています。どちらも導入が簡単なSDKを提供しており、判断は守備範囲と予算の問題に帰着します。