The Xcode Organizer Hang Report has, for a long time, been the kind of window I would open whenever I happened to remember. Crashes get reported to me daily through Crashlytics, but hangs (those moments when the UI freezes for a second or two and then comes back) quietly pile up in the background. When you run several wallpaper apps as a solo developer, the metrics you watch daily, like crash rate or revenue, eventually turn into habits on their own, but hangs were always the metric I knew mattered for App Store ratings yet somehow never built a habit around. Earlier this year I decided to look at Xcode Organizer's Hang Report for only thirty minutes every Friday afternoon, and this post is what I learned over the first month.
Why I Chose Not to Check It Daily
My first instinct was to check it every morning, the same way I look at Crashlytics. I tried it for a week and gave up almost immediately. The Hang Report's granularity is coarse, so the numbers barely move from day to day. Crashlytics gives me yesterday's crash rate as a clean daily figure, but the Hang Report mostly summarizes the past thirty days, and a daily glance rarely changes my next decision.
Backing off the frequency naturally landed me on a thirty-minute Friday slot. Friday made sense because I want to know whether the hang rate has drifted upward before I commit to the weekend's work order. Starting any new observability habit at the lowest possible cadence, and only raising it when the data actually asks for more, is something indie development has taught me over and over. If you force a low-volume metric into a daily routine, you usually end up dropping every routine you have.
What I Actually Do in the Thirty Minutes
The Friday slot runs from 2:00 PM to 2:30 PM. I do three things, and nothing else.
First, I launch Xcode and open Window → Organizer → Disk Writes / Hangs. At the moment I have six apps in active rotation (four wallpaper apps and two calm-down apps), so I cycle through each project in the sidebar and read the past-thirty-day hang rate for each. My only criterion is whether the most recent week is noticeably higher than the average of the three weeks before it. I do not apply a fixed numeric threshold; each app has its own baseline, and relative shifts are more meaningful than absolute ones.
Second, for any app that is trending up, I open the top three hang signatures for that week. Xcode shows the top stack frames, and I scan them just enough to bucket each one as "asset loading," "network wait," or "image processing on the main thread." I do not decide on fixes during this thirty-minute window. The candidates go into a notes file for Monday onward.
Third, I look across all six apps for hang signatures that appear in more than one project. Wallpaper rendering code and subscription restore code are shared across several of my apps, so a single fix in shared code can improve several apps at once. This is one of the perspectives only available when you run multiple apps in parallel; I felt a similar effect when working on AdMob mediation optimization.
Sorting Out the Roles of Hang Report and Crashlytics
When I first started reading the Hang Report, my immediate question was: how is this different from the freeze-related events I get in Crashlytics? After a month, my mental model has settled like this.
Crashlytics catches events where the app actually died (the process crashed) and surfaces them at a fine time resolution. Its Velocity Alert flags sudden spikes in near real time. It does not, however, capture the experience of "the UI froze for two seconds and then recovered." That kind of slow, on-thread blockage is exactly what Xcode Organizer's Hang Report aggregates.
So in my workflow, the division of labor is now clear. Crashlytics is for catching fatal damage instantly, and the Hang Report is for noticing the slow-creep degradation that shows up in App Store reviews. The former is push-driven, and I have even delegated part of its triage to Claude in Chrome. The latter does not send notifications, and the volume is too small to justify automating, so a human reading it in one weekly sitting is the most honest match.
Hangs are the thing reviewers describe as "laggy" or "freezes a lot." Lining up review text alongside hang numbers, on more than one occasion, I have felt the data side confirm what the words were already saying. That correlation simply did not surface when I was only watching Crashlytics.
What I Actually Shipped in One Month
The summary after one month: three of the six apps showed a gradual uptick in hang rate over the most recent week. Two of those traced back to the wallpaper thumbnail list screen, where shared image-cache code was decoding on the main thread. Moving the decode to a background queue and bouncing back to the main thread cut the hang rate in those screens by more than half.
The third was a calm-down app that was initializing its ad SDK synchronously inside the splash screen at launch. The AdMob SDK initializer provides a completion callback, so I rewrote that flow to let initialization run in parallel with first-frame UI. The change improved actual launch time as well, and AdMob eCPM nudged upward slightly too, because the first impression window opened a fraction earlier.
I verify whether a fix actually lowered the hang rate during the following week's Friday slot. Waiting a week sounds slow, but Xcode Organizer aggregates take a few days to settle anyway, so the cadence prevents the very common failure mode of "I shipped a fix, so I assume it worked."
Small Tricks That Make the Habit Stick
Three small habits ended up mattering after one month.
First, I have the Friday 2:00 PM slot on the calendar. Without it, urgent work always wins. Even just reserving thirty minutes lowers the psychological cost of opening Xcode.
Second, I keep one notes file per app. Six apps, six Markdown files, with weekly headings like "2026-W18" and "2026-W19." Appending to the same file each week lets me see, side by side, what version of me was worried about three weeks ago. I keep these files outside of Xcode itself so I can revisit them on weekdays when Xcode is closed.
Third, I sort fix candidates into three buckets: this week, revisit next month, defer. Of all the hangs the report exposes, only a few truly deserve immediate action. Anything that has not increased recently or that affects only a small slice of users goes to defer. Deciding up front not to fix everything at once keeps the weekly workload to a size I can actually sustain, even while running six apps in parallel.
How My Attention Has Shifted
A month of reading these numbers has subtly changed how I write code. When I sketch a new screen, I notice more quickly what is happening on the main thread. Image sizing math, JSON parsing, settings reads, the small things that pile up on the main thread, are the things that hurt the feel. Seeing those add up in the Hang Report has trained my eye.
The interval between "user touched the screen" and "something visibly responded" is far more present in my decisions now. I used to be satisfied once a screen simply looked right, but these days I think first about what is running between the touch and the response. Reading the numbers once a week, without any deliberate effort, has quietly reshaped the frame I use for design calls.
What I Want to Try Next
The next experiment I have queued up is putting Hang Report data next to App Store review text. When reviews start saying "heavy," "sluggish," or "freezes," I want to check whether those weeks correlate with weeks of higher hang rate. If they do, the next step is to ask Claude in Chrome to classify the review text and cross-reference it against the weekly hang summary.
Building apps that last a long time means staying friendly with the slow, undramatic numbers as well as the flashy ones. If you are also running several apps as a solo developer, I hope reading this gives you a small nudge toward the habit.