Practical guide · Updated July 25, 2026
Mobile app monitoring for iOS and Android
Mobile app monitoring should answer three questions quickly: is the current release healthy, can users complete the outcomes that matter and who must act when something breaks? This guide covers the client, backend, stores and product alongside crash reporting.
Monitor the whole mobile system
A mobile product can be technically alive while users cannot sign in, sync data, receive messages or access a purchase. Build monitoring as connected layers.
No single vendor covers all five layers. Connect them with consistent release and request context.
Start from critical user journeys
List the smallest set of journeys whose failure makes the product unusable or commercially broken. Instrument the result of each journey rather than only the taps inside it.
- App opens and reaches a usable state
- New user can create an account and activate
- Existing user can authenticate and recover access
- Core content loads, saves and synchronizes
- Upload, search, message or other primary action completes
- Purchase completes and the entitlement appears
- Previous purchases restore after reinstall or on another device
- Notification tap opens the intended authorized destination
- User can get help and delete the account
For each journey define a start event, success event, expected duration, known failure reasons and responsible owner.
Define service levels before alerts
An alert needs a promised level of service. Choose a small number of service-level indicators (SLIs) and objectives (SLOs) that match user outcomes.
Use the product’s own baseline and risk tolerance. Thresholds are operating decisions, not universal industry constants.
Attach release and request context
Every event should make it possible to answer “which users, which build and which operation?” without first asking the user to reproduce it.
- App version and build number
- Release channel or store track
- Environment and backend version
- Operating system, device model and locale
- Anonymous installation and session identifier
- Pseudonymous authenticated user ID when permitted
- Feature-flag and experiment variants
- Screen or workflow name
- Request or correlation ID shared with backend logs
- Connectivity state and relevant provider result code
Upload iOS dSYMs and Android mapping or native symbol files during the release pipeline. Without symbolication, a production stack trace may not identify the failing code.
Track crashes by affected users
Event count alone is misleading: one broken device can generate thousands of reports while one startup crash can block every affected user. Monitor crash-free users and crash-free sessions, then prioritize by affected users, recency and release regression.
- Compare the new build with the previous stable build
- Separate fatal, non-fatal and handled business errors
- Group by device, OS, release track and feature flag
- Add privacy-safe breadcrumbs for actions before failure
- Identify startup and critical-journey crashes first
- Confirm symbols exist for every public build
- Link each high-impact issue to an owner and release decision
Crash-free metrics cover fatal stability, not frozen interfaces, failed requests or incorrect business outcomes.
Treat Android ANRs separately
An Android app can remain running while its main thread stops responding. That produces an Application Not Responding event rather than a conventional crash.
- Review user-perceived ANR rate in Android vitals
- Inspect ANR clusters and the blocked main-thread stack
- Look for disk or network work on the main thread
- Investigate lock contention, slow startup and long callbacks
- Segment by phone model and Android version
- Compare Play Console with the in-app crash tool
- Watch emerging issues and store quality warnings
Google states that core vitals can affect visibility on Google Play. Android vitals also sees some system-level events an SDK may miss, so Play Console remains necessary even when Crashlytics or Sentry is installed.
Use Apple diagnostics and MetricKit
Keep the App Store Connect and Xcode diagnostics path alongside the cross-platform crash tool. Apple crash reports, Organizer diagnostics and MetricKit can add platform-specific evidence from distributed builds.
- Verify production crash reports are symbolicated
- Inspect termination reason, exception type and crashed thread
- Separate crashes from non-fatal diagnostic conditions
- Review hangs, launch behavior, memory and disk-write evidence where available
- Compare affected OS and device cohorts
- Retain the source commit and symbols for every released build
Collect the minimum diagnostic context required; do not copy privacy-sensitive values into custom reports.
Measure performance as users experience it
Average latency hides the slowest users. Track percentiles and the full user-visible operation rather than only one function or backend request.
- Cold and warm startup to usable interface
- Time to render primary screen and meaningful content
- p50, p95 and p99 API latency by endpoint and region
- Slow or frozen frames on important screens
- Long tasks and blocked main-thread work
- Memory pressure, out-of-memory termination and low-memory kills
- Upload and download duration, payload size and failure
- Battery, wake locks and excessive background work on Android
- Offline and poor-network behavior
Performance alerts should identify the affected release, device cohort and operation. “The app is slower” is not a diagnosis.
Connect mobile errors to backend traces
A generic “network error” often originates in authentication, the API, database, queue or a third-party dependency. Give support and engineering a shared trail.
mobile: build=142 operation=checkout result=failed reason=inventory_timeout correlation_id=req_7f3…
backend: req_7f3… → inventory provider → timeout- Return stable machine-readable error codes
- Preserve the correlation ID from client to every service
- Separate timeout, offline, unauthorized, validation and server failure
- Measure retries and duplicate operations
- Expose dependency latency and failure rate
- Alert on exhausted queues, rate limits and webhook delay
- Provide a safe support lookup without exposing secrets
Monitor product outcomes, not vanity events
Analytics becomes operational when it detects a broken outcome. Build a funnel per critical journey and attach explicit failure events.
- Track started, succeeded, cancelled and failed states
- Use controlled enums rather than free-form error messages
- Compare conversion by app version and platform
- Watch event loss or sudden schema changes
- Exclude internal and automated test traffic
- Annotate releases and incidents on the dashboard
A conversion change may be a product effect, analytics defect or technical failure. Validate it against logs, support and store data.
Monitor purchases through entitlement delivery
Store revenue can look healthy while individual users remain locked out. Observe the transaction and access state as connected but separate systems.
- Paywall viewed and purchase initiated
- Store sheet succeeded, failed, was cancelled or remains pending
- Transaction reached backend verification
- Server notification or webhook was processed
- Purchase was acknowledged where required
- Entitlement was granted to the correct user
- Restore completed after reinstall
- Renewal, expiry, grace period, refund and revocation changed access
- Confirmed transactions without access enter a recovery queue
- Duplicate events remain idempotent
Use a direct commercial alert: “A confirmed transaction has no matching entitlement after the allowed processing window.”
Monitor push delivery and destinations
Push is a chain: application event → messaging provider → APNs or FCM → subscription → notification tap → destination. Track each boundary separately.
- Eligible user and trigger event
- Provider accepted or rejected the send
- Subscription and permission state
- Delivery where the provider and platform expose it
- Open or interaction rate by message type
- Deep-link destination loaded successfully
- Expired, unauthorized and deleted destinations
- Duplicate sends and wrong-account delivery
For implementation and troubleshooting, use the OneSignal push notifications guide.
Use structured, privacy-safe logs
Logs should explain state transitions without becoming a copy of user data.
- Use structured fields for operation, result, reason and duration
- Never log passwords, access tokens, private keys or payment data
- Redact email, phone, message content and sensitive health or location data
- Use pseudonymous identifiers and access-controlled support tooling
- Sample high-volume successes but retain important failures
- Define retention by operational need and legal requirement
- Cover connected telemetry in deletion workflows where required
- Match analytics and diagnostics to store privacy disclosures
Design alerts around user impact
Paging on every exception creates noise. An alert should state impact, urgency and owner.
- Alert on rate or affected users, not raw count
- Require a minimum sample size where appropriate
- Compare the current release with its baseline
- Include dashboard, runbook and owner links
- Deduplicate repeats during one incident
- Define who can pause rollout or disable a feature
Build four dashboards for a small team
Every dashboard should filter by version, platform, environment, time and relevant cohort. Add deployment annotations.
Use monitoring as a release gate
- Verify telemetry in the signed TestFlight or Play testing build.
- Record the previous stable version as the baseline.
- Release to a controlled cohort or staged percentage where possible.
- Watch stability, critical journeys and support together.
- Continue, pause, disable a feature or prepare a corrective build.
- Verify recovery before increasing rollout again.
- Every public build appears in crash and analytics tools
- Symbols and release metadata upload automatically
- Critical controlled checks pass
- Dashboard annotations identify rollout time
- Pause criteria and decision owner are documented
- A stable fallback or server-side kill switch exists where feasible
Run a consistent incident workflow
Record impact, timeline, root cause, mitigation and preventive action. “Be more careful” is not a preventive action.
Choose a deliberately small tool stack
- Apple diagnostics and App Store Connect for Apple-specific evidence
- Android vitals and Play Console for Android system and store health
- One cross-platform crash tool such as Crashlytics or Sentry
- One product analytics system with controlled event definitions
- Backend logs, metrics and tracing with correlation IDs
- Payment and messaging provider dashboards for their boundaries
- One alert route and one incident owner
Choose tools after defining events, SLOs and response paths. Installing an SDK is not the same as operating a monitored product.
Production monitoring checklist
- Critical journeys have start, success and controlled failure events
- Version, build, platform and environment accompany telemetry
- Client and backend share a correlation ID
- Every release has symbols and source traceability
- Crash-free users and sessions are compared by release
- Android ANRs and core vitals are reviewed in Play Console
- Apple diagnostics are reviewed alongside the cross-platform tool
- Performance uses percentiles and user-visible duration
- Authentication, sync and API failures have stable reason codes
- Purchase-to-entitlement mismatches have a recovery queue
- Push sends can be followed through destination outcome
- Logs exclude secrets and unnecessary personal data
- Alerts identify impact, threshold, owner and runbook
- Dashboards are annotated with deployments and incidents
- Staged rollout has explicit continue and pause criteria
- Every incident adds a test, monitor or release check