Monitoring a live app without a team is two screens and a repeating calendar entry.
Both stores are already collecting the numbers for you. Apple keeps them in Analytics inside App Store Connect. Google keeps them in Android vitals inside Play Console, under a menu called Monitor and improve. Neither asks you to add a line of code to the app, and neither charges for it. Both only see the people who agreed to share their data, so both undercount. The difference that matters when there is nobody to delegate to: Google publishes a crash rate you can fail, with consequences attached, and Apple does not. Every screen name and figure below comes from Apple's and Google's own help pages, read on 16 October 2026.
What follows is what each store hands a solo operator free, where the two sets of numbers deliberately disagree, which single figure is worth interrupting your week for, and a routine short enough that one person repeats it. That last part is the actual problem. The data is already sitting there. Nobody opens it.
Start hereThe short version
You do not need a monitoring stack. You need to look.
A small team buys tools because it has people to read them. One person buys tools and then does not read them. The useful move at this size is not another dashboard. It is deciding, once, which three numbers you will look at, where they live, and on which day you will look. Crash rate, not-responding rate, sessions. Two browser tabs, a quarter of an hour, once a week.
The reason the free tools are enough at the start is that they are collected by the operating system rather than by code you added. Nothing to install means nothing to break, nothing to pay for, and no gap between what the store thinks happened and what your own tooling thinks happened. The cost is coverage. Both stores count only the people who opted in to share data, so read these numbers as a sample with a trend, never as a tally.
What does App Store Connect give you for nothing?
Analytics, and more of it than most solo operators realise. Apple describes it as over 100 distinct quantitative measurements covering the journey from discovery through download to engagement, purchases and subscriptions. There are two ways in. The App Store Connect dashboard, which Apple recommends for interactive exploration, filtering, comparisons and quick diagnosis. And downloadable reports plus API access, which Apple recommends for bulk exports and for joining App Store data with your own systems. The dashboard is organised into twelve sections: Overview, Sources, Product Pages, In-App Events, Campaigns, Sales, Subscriptions, Cohorts, Offers, Retention, Benchmarks and Metrics. Opening any of it needs the Account Holder, Admin, Finance or Sales role.
Three numbers carry most of the weight when you are alone. Crashes is defined as the total number of crashes on devices running a minimum of iOS 8, macOS 11, tvOS 9, or visionOS 1. Sessions is the number of times the app has been used for at least two seconds, and a return from the background counts as another session. Active Devices is the number of devices with at least one session during the selected period. There is also a Crashes by App Version widget under App Usage, which segments crash counts by version, and that is the single most useful free thing on the page, because it answers the only question that matters after a release.
Two caveats sit in Apple's own wording and they change how you read everything. Usage metrics are available when you have at least five active devices within the selected date range, and usage data totals are based on App Store users who opt in to share their data with you. Apple also says some usage and quality metrics appear only when there is sufficient data and when users have opted in to share diagnostics and usage information, and that you may find gaps when volume is too low to meet privacy thresholds. A new app with fourteen installs will show you very little, and that is by design rather than a fault.
The important limit: App Store Connect gives you the count, not the report. For the report, Apple's Xcode documentation on acquiring crash reports and diagnostic logs, read on 16 October 2026, points you at the Crashes organizer in Xcode, which it says presents crash reports from customers who share diagnostic and usage information. Select a report and click Generate Recommendations in the Inspector for assisted triage. Two details in that document earn their place in a solo routine. TestFlight and the App Store collect crash reports for every submitted version of your app. And TestFlight users share crash reports with you automatically, regardless of the device settings for sharing diagnostic and use data, which makes your test build a better signal than your release build.
Four kinds of failure never reach that organizer, and Apple names them: watchdog events, such as slow app launch times, invalid code signature crashes, thermal events where a device overheats because an app uses too much CPU, and jetsam events where an app has high memory use. When a customer swears the app quits on launch and your organizer is empty, that list is usually the answer. For one person's log you can ask them to open the Analytics & Improvements section of Settings, tap Analytics Data, and mail you the entry. Crash logs are named after the app binary and the date. High memory logs start with JetsamEvent.
App Store Connect Help, metric definitions, read 16 October 2026
Find the screen
What you want to know, and where each store keeps it
Tick a question. The screen names are the ones Apple and Google use in their own help pages, read on 16 October 2026.
Nothing ticked. If you only ever open one of these, open the Android vitals Overview, because it is the only one with a number attached to a consequence.
What is the Google Play Console equivalent?
Android vitals, and it is a stricter thing than Apple's version. In the left menu of Play Console you open Monitor and improve, then Android vitals. The Overview page puts your core vitals at the top. The Crashes and ANRs page under it is where you work: filters near the centre of the screen, and a View details link beside each item. Crashes are grouped into clusters to help you identify when multiple crashes may share the same root cause, and ANRs are grouped the same way. Set the Issue visibility filter to foreground issues only and you see the clusters a person actually felt, rather than something that happened while the phone was in a pocket.
Where the data comes from is worded almost the same as Apple's. Google says it is collected from users who have opted in to automatically share usage and diagnostics data, and adds that this covers a subset of Android devices and OS versions. Two time windows matter and they are different numbers. Android vitals data is available for the previous 90 days in the console. Google says it will generally consider the last 28 days of data when it evaluates your app. So a bad week is still visible to you two months later, and still counted against you for a month.
The headline Apple has no free answer for is ANR, which stands for application not responding. That is the app alive but frozen, and as a failure mode it is often worse for the person holding the phone than an honest crash. Google treats the user-perceived ANR rate as a core vital with its own number. Usage figures live elsewhere, on the Statistics page: the Reach and device overview, at Release, Reach and devices, Overview, lets you compare two metrics and spells the split out, saying user metrics correspond to the Statistics page and issue or quality metrics correspond to Android vitals.
Two Play Console features are worth more to one person than to a team. The pre-launch report runs your build on real devices before anyone pays for the privilege, and its issues come with crash or ANR detail, the Logcat from the device, and a video of the error, which is as close as you get to someone sitting next to you reproducing a bug. And releasing through a staged rollout on Google Play means the new version's vitals arrive while most of your users are still on the old one. That is the only lever a solo operator has for catching a bad release before it is everybody's bad release.
Play Console Help, monitor your app's technical quality with Android vitals, read 16 October 2026
Which number means you have to drop everything?
One of Google's two, because Google is the only one of the two stores that publishes a line and says what happens when you cross it. Read on 16 October 2026, the bad behaviour threshold for the user-perceived crash rate is at least 1.09% of daily users experiencing a user-perceived crash across all device models, or 8% of daily users on a single phone model. For the user-perceived ANR rate it is 0.47% across all device models, or 8% on a single phone model. Watch form factors have their own figures, 4% for crashes and 5% for ANRs on a single watch model. Those are small numbers. One crash in a hundred sessions is not the bar. One user in a hundred per day is.
The consequence is why this is the figure worth an interruption. Google says an app that exceeds a bad behaviour threshold is likely to be less discoverable on Google Play, that for a problem specific to certain devices it will steer users on those devices towards other titles, and that in some cases a warning could be shown on your app's store listing to set user expectations. A warning on your listing is the one to fear. It is the only operational problem on this page that your prospective customers can read.
Two more core vitals exist and are narrower. Excessive battery usage applies to watch faces, with a threshold of more than 1% of watch face sessions. Excessive partial wake locks is in beta, with a threshold of more than 5% of battery sessions holding one or more partial wake locks totalling more than three hours, and Google says exceeding it does not currently make your app less discoverable. Worth knowing they exist, not worth a weekly look unless you ship a watch face or keep the device awake on purpose. Play Console's technical quality requirements page, read the same day, also lists requirements that are not live yet: reduced memory usage and DEX code optimization from February 2027, and zero-tap sign-in restoration from April 2027. It states plainly that none of the requirements on that page are optional.
Apple publishes no matching crash threshold, and it is a mistake to read that as leniency. Apple polices the app at a different moment, at review, against the guidelines, which is a separate study in why apps get rejected. The practical reading for a solo operator is that on Android your crash rate is a ranking input you can measure, and on iOS it is a review risk and a review problem. One is a dial. The other is a door.
Play Console Help, bad behaviour thresholds for core vitals, read 16 October 2026
What does a routine look like when the team is one person?
Fifteen minutes, one day a week, in a fixed order, starting with the screen that has a consequence attached. Open the Android vitals Overview and read your two core vitals against the thresholds. Then Crashes and ANRs, with Issue visibility set to foreground, and look at the top cluster only. Then App Store Connect, Analytics, Crashes by App Version and Sessions. Write down the two rates and the session count somewhere dull, a note or a spreadsheet, because the number that matters is not this week's value but whether it moved. The stores will not tell you that. They show you now, and you are the only one who remembers last month.
Then a second, shorter pass that is not weekly: after every single release. The most likely cause of a new problem is the thing you just did, so segment by app version rather than reading a total, which is exactly what Apple's Crashes by App Version widget and Google's version filters are for. A total hides a bad release behind a good fortnight. Give a release three or four days before you judge it, because at small volumes one unlucky device can move a percentage.
Decide in advance what you will ignore, because that is the part that keeps the routine alive. A cluster with two affected users and no pattern is not an emergency. A crash rate that rose from 0.3% to 0.4% in a week with forty users is noise. The things that earn an interruption are short: any core vital over its threshold, a new cluster that appeared with your last release, a crash concentrated on one phone model, and a review that describes a failure you cannot see in either console. The same weekly pass is the natural place to read Sales and Subscriptions, though what to do with those numbers is a different subject with its own decisions about app monetisation.
The one thing worth adding before any paid tool is a way for a user to tell you something broke, because the stores will not route that to you. An email address on the listing and in the app, answered within a day, will surface more real bugs in a month than a crash dashboard will, for the simple reason that the worst failures are the ones where nothing crashed: a button that does nothing, a payment that half worked, a login loop. None of those appear in a crash count. All of them appear in a one-star review eventually, which is much more expensive than a reply.
App Store Connect Help, usage metric definitions and the five device minimum, read 16 October 2026
The same job, handed to you differently by each store
| What you are asking | App Store Connect, Analytics | Play Console, Android vitals | Same on both |
|---|---|---|---|
| Where the numbers live | Analytics, organised into twelve sections including Metrics, Retention and Benchmarks | Monitor and improve, then Android vitals, with Overview and Crashes and ANRs under it | No |
| Code you have to add to the app | No | No | Yes |
| Whose devices are counted | App Store users who opt in to share their data with you | Users who have opted in to automatically share usage and diagnostics data | Yes |
| Minimum before a number appears | At least five active devices within the selected date range | No figure published. It says there are not enough data points | No |
| How far back the data goes | Not stated on the Analytics help pages | The previous 90 days | No |
| A published threshold you can fail | No | 1.09% crash rate and 0.47% ANR rate across all device models | No |
| Crash reports grouped for you | In the Crashes organizer in Xcode, not in App Store Connect | Clusters on the Crashes and ANRs page | Yes |
Where this lands if a builder generated your app
It lands in exactly the same place, because both of these are store-side. Analytics and Android vitals are attached to your app record, not to your toolchain, so they work identically whether a team of eight wrote the code or an agent did. What changes with a builder is the next step after you find something: whether you can act on a crash report, or whether you have to ask someone.
Newly is an AI app builder. You describe an app in plain English and it generates a real React Native and Expo project that you own. It uploads iOS builds to TestFlight, publishes to Google Play internal testing, and can build a standalone Android APK. It keeps two-way GitHub sync, so a fix can come from the agent or from an editor, whichever suits the bug. It does not submit to the App Store for you, because Apple requires the owner of the content to submit. It costs $25 a month and there is no free tier.
Two of those facts matter for monitoring specifically. TestFlight is where your crash reports are most complete, because testers share them regardless of their device settings, so an upload to TestFlight before every release is free monitoring rather than a formality. And because the project is yours and synced to GitHub, the loop from an Android vitals cluster to a shipped fix stays in your hands. The honest limit is the same for any builder: generating the app does not watch the app. If money moves through it, the failures you most need to see are payment failures, which neither console reports, and that is part of choosing which payment layer to use.
Questions people ask about watching a live app alone
Use what the two stores already collect, and put one calendar entry against it. Apple gives you Analytics inside App Store Connect, which covers over 100 measurements including Crashes, Sessions and Active Devices. Google gives you Android vitals inside Play Console, under Monitor and improve, with an Overview page and a Crashes and ANRs page. Neither needs you to add code to the app, because both are collected from users who opted in to share their data. Fifteen minutes a week on those two screens, plus a look after every release, is a real monitoring practice for one person.
Ship it, then put the two screens in your calendar
Pick the day before you launch, while you still care. Fifteen minutes, two tabs, three numbers written down. That is the whole practice, and it is the difference between finding out from a console and finding out from a review.
Start building