Firebase Crashlytics or Sentry, which one should we use?

Crashlytics is the cheaper default when Firebase already handles your auth, storage, or notifications, and it ships free inside the Firebase project. Sentry gives sharper grouping and one dashboard across mobile, backend, and web, which helps teams running all three. We pick based on your stack and who will read the reports.

Why do our iOS crashes show as memory addresses instead of code?

The build was uploaded without its dSYM files, so the dashboard has the crash but nothing to match against it. The dSYM comes from the same Xcode build that produced the binary and has to be uploaded for that exact version. Android has the equivalent problem with R8 and ProGuard mapping files. We put the upload in the build pipeline so a release cannot reach the store without it.

Which events should we track in the first release?

Start from the decisions you want to make. Onboarding completion, the first action that shows a user got value, each step of the payment or booking flow, and week one and week four retention cover most products, and that usually lands under thirty events. We write the names and properties into a tracking plan before anything ships.

How do you handle consent and store privacy declarations?

Analytics and crash SDKs collect device and usage data, so both Apple's App Privacy details and Google's Data Safety form have to declare it, even when the app asks the user for nothing else. We configure the SDK without advertising identifiers, keep names, emails, phone numbers, and precise location out of event properties, and hold collection until consent allows it.

Do crash alerts go anywhere useful?

They go to a channel a person watches, with a named primary and a backup. A new crash type in a released version, a crash-free rate under the level we set, and a spike in a payment failure event are the usual triggers. Thresholds stay generous, because a channel that fires daily gets muted inside a week.

App Analytics & Crash Reporting Setup

Crash reporting, symbol upload, funnels, and retention events set up so your app shows which release broke and where users leave.

See our work:

Voice VPN - Fast VPN. Vasilkoff Ltd in-house project→Voteme App→Walking Cure→

Most apps ship with crash reporting attached in the last week of a sprint, plus events named after whichever screen the developer had open at the time. A year later the dashboard has not been opened since launch, the crash count is rising with no release attached to it, and names such as screen_2_open mean nothing to whoever reads the funnel.

A useful setup answers questions your team already asks. Which release introduced this crash? Where do users disappear on the way to payment? Do the people who finish onboarding come back in week two?

What the setup covers

Three jobs share the same SDKs, and each one fails on its own.

Crash and error capture. Firebase Crashlytics, Sentry, or an equivalent records unhandled exceptions with a stack trace, device model, OS version, app version, and the session state before the failure. Non-fatal errors matter just as much: a payment call that fails and gets caught, a parse that throws inside a try block, an upload that times out. Those never reach the crash count, and they are often what support hears about.

Symbol upload. A readable trace needs the dSYM files from the exact iOS build and the matching R8 or ProGuard mapping file from Android, so the upload belongs in the build pipeline.

Product events. Funnels, retention, and screen engagement arrive through Mixpanel, Amplitude, Firebase Analytics, or a comparable tool. A badly named event costs the same to send as a useful one.

Who this is for

Apps that crashed this month and nobody can name the version or the device.
Products with a payment, booking, or signup flow where each step loses users.
Subscription apps where week one and week four retention decides the business.
Privacy-sensitive apps that need crash and product numbers without collecting identities.

What we deliver

Crash, non-fatal, and symbol coverage

We verify the SDK with a forced test crash on a real device in a release configuration, since debug builds behave differently from what reaches users. Grouping rules make four hundred reports of one bug count as one issue, and breadcrumbs record the last screens before a failure. dSYM and mapping uploads run as a build phase or CI step on every release, with older Android mapping files kept, because resolving an old crash needs the mapping from its own release.

An event model with a naming convention

We agree the scheme before the first event ships: object and action, snake_case, past tense for completed actions, screen views separate from interactions, defined types per property. One action carries one name across iOS, Android, and web. Every event goes into a tracking plan with a purpose and an owner.

Funnels, retention, and release health

A small set of reports maps to decisions: onboarding completion, first meaningful action, drop-off at each payment step, week one and week four retention, and the crash-free session rate per release. Retention is split by the cohort that completed setup and the cohort that did not, because an aggregate line hides the difference a product change can act on.

Privacy and consent limits

Analytics and crash SDKs collect device and usage data even when the app asks for nothing else, and both stores require that collection on the App Privacy and Data Safety forms. We run without advertising identifiers, keep personal details out of event properties, and hold collection until consent allows it. In a privacy-first product such as Voice VPN, the reporter carries device and build metadata alone.

Alerts that reach a human

Reports sitting in a dashboard get read when somebody remembers them, usually after a user complains. We route the ones that cannot wait: a new crash type in a released version, a crash-free rate under the level you set, a spike in payment failures, a launch time regression past a threshold. Alerts land in a channel a person watches, carry the app version and device breakdown, and link to the issue.

A setup somebody reads

The failure we design against is an account full of data and nobody opening it. Four habits prevent that. The event budget stays small, usually under thirty at launch, and grows only when a question needs an answer. Every dashboard has a named reader and a decision attached, so a chart with no decision gets deleted. Alerts belong to a person on a rota with a backup. We review the tracking plan each release and retire events whose question has been answered.

Where the project starts

Three situations, three different jobs.

A plain idea with nothing built yet. We choose the event model and the crash tooling while the app is being written, so the first release reports what the business needs. Names decided now cost an hour, and data already collected cannot be renamed later.

An existing conventional codebase. We audit what is already collected, map duplicate and abandoned events, and keep history where old names must survive by translating at the point of send. Then we fix symbol upload, set grouping rules, and build reports on what is real.

An AI-built or rapidly assembled prototype. These commonly initialize an analytics SDK with a debug flag left on, keep the project key in client code, and name events per screen. We keep the product and the screens, move credentials behind a backend, correct event names before there is data worth keeping, add symbol upload, and strip personal data from properties already in flight.

How the engagement runs

Discovery starts from your questions and your release process. We agree the events, alert thresholds, and reports, then instrument a staging build, confirm symbols resolve, and check the funnel numbers against a manual walkthrough so a wrong number is caught early. Rollout follows your next release, and we hand over the tracking plan, dashboard definitions, alert rules, and a short guide to what each number means.

What it costs

Analytics and crash reporting work is billed at our flat rate of $39 per hour, or quoted as a fixed scope once we have seen the app and the questions you want answered. Added to a live app, the instrumenting, symbol pipeline, and reports usually fit inside one to three weeks, depending on how many screens and events are involved. Inside a new build the work sits within the mobile MVP typical order of $4,800 to $8,500 across four to six weeks that the pricing page lists, and teams wanting the same capacity monthly can use the plans from $2,699 per month.

Proof

Voice VPN is our in-house Flutter VPN app with native Android Services and iOS NetworkExtension integrations, built for networks where connections get blocked, running with no account and no traffic logs. What it proves for this service: crash reporting still works in a privacy-first product when the reporter carries device and build metadata alone.

Voteme is a Xamarin social app for iOS and Android with photo upload, voting, credits, chat, notifications, and blocking and reporting controls. What it proves for this service: in a feature-dense product the engagement loop is the funnel worth measuring, and event naming has to survive voting, chat, and credits sharing one namespace.

Walking Cure is a WordPress clinic site for a California practice, included for the measurement lesson: the project was judged by enquiries, and the number that mattered was a completed contact form. What it proves for this service: the metric worth instrumenting is the one tied to a business outcome, on a phone or on a page.

Related services

Mobile app development for the app this reporting runs inside
Mobile app bug fixing and performance for acting on what the reports turn up
App store optimization where crash-free rate and ratings feed store visibility
Mobile app privacy and compliance for consent flows and the store declarations analytics SDKs require
Push notification and messaging system when a tracked event should trigger a message

Next step

Send us the app and the three questions you cannot answer about it today. We will say what to instrument and what the first dashboard should hold.