Until this week, the only way I found out our app had crashed was when someone told me. Most people don’t. They reopen the app, and if it happens again they stop opening it. The API side was covered (every ERROR log already lands in a team chat channel), but a crash on a phone left no trace anywhere I could see.

The app did have one reporter already. When it puts an error message in front of someone, it posts that message to a small endpoint on the API, which logs it at ERROR, so it reaches the chat channel too. I added it after a delete that had worked left the row in the list, and tapping it again showed “No Item matches the given query”. The server had logged two ordinary 404s and said nothing. That covers errors the app catches and shows. A crash is different: the JavaScript that would send the report is the thing that just died.

The obvious fix is Sentry. I like Sentry’s SDK a lot; it’s the reason crash reporting on React Native is a solved problem. What I didn’t want was another vendor holding user data, another privacy-policy line, and another bill for something that, at our size, is a few reports a day at most. So I kept the SDK and replaced the service: the app’s DSN points at our own API, and a small piece of the Django app there receives what it sends, groups it, alerts on it, and keeps it.

This post is how that works, and how I checked that a real native crash actually makes it through.

The DSN trick

#

A Sentry DSN looks like https://<public-key>@<host>/<project-id>. The SDK turns that into a POST to https://<host>/api/<project-id>/envelope/, with the key in an X-Sentry-Auth header. Nothing about it is specific to sentry.io. So the DSN baked into the app is:

https://<CRASH_REPORT_KEY>@api.example.com/1

and Django has a route that matches what the SDK will call:

path("api/<int:project_id>/envelope/", crash_envelope, name="crash_envelope"),

The key is in every binary, so it isn’t a secret. It’s there so that if the endpoint ever starts attracting junk I can change it, and so that an unset key on the server refuses everything rather than accepting the world:

def crash_envelope(request, project_id):
    expected = settings.CRASH_REPORT_KEY
    if not expected:
        return Response({"detail": "Crash reporting is not configured"}, status=503)
    if not hmac.compare_digest(_key(request).encode(), expected.encode()):
        return Response({"detail": "Unknown key"}, status=401)
    ...

_key reads sentry_key= out of the X-Sentry-Auth header, falling back to the query string, which some SDKs use instead.

What the SDK sends: envelopes

#

Sentry’s wire format is the envelope: one JSON header line, then any number of items, each one a JSON header line followed by a payload. If the item header has a length, the payload is exactly that many bytes; otherwise it runs to the next newline.

{"event_id":"9ec79c33...","dsn":"https://...@api.example.com/1"}
{"type":"event","length":4123}
{ ...the event JSON, 4123 bytes... }
{"type":"client_report"}
{"timestamp":1791400000.5,"discarded_events":[]}

Two details caught me out:

• The native SDKs gzip the body; the JavaScript one doesn’t. A JS error captured by @sentry/react-native arrives as plain text, while a native crash from sentry-cocoa or sentry-android arrives with Content-Encoding: gzip. The decoder handles gzip, zlib-wrapped deflate and raw deflate, and stops decompressing at 1MB, because a crash event is a few kilobytes and anything bigger isn’t one.
• Length-prefixed payloads can contain newlines. If you split on \n you’ll mangle every event the native SDKs send. You have to honour length when it’s there.

The parser is short. It only keeps event items; sessions, transactions, attachments and client reports are accepted and dropped.

Answering in a way the SDK understands

#

This matters more than I expected. The SDK keeps a queue on disk and retries anything it isn’t sure was delivered, so what the server answers decides whether it keeps trying:

• 200 once stored, or deliberately dropped. If I answered a session item with a 4xx, the SDK would keep it and retry forever.
• 429 with Retry-After when throttled. The endpoint has a per-IP throttle (120 an hour), because a phone in a crash loop sends one report per launch, and the SDK backs off on a 429 the way you’d hope.
• 400 for a malformed envelope, logged as a warning, not an error: a broken report says a client is broken, and the next good one will say what crashed.

The SDK also resends the same event if it isn’t sure the first send arrived, so event_id has a unique constraint and a duplicate is a quiet no-op.

Grouping without source maps

#

This is where a self-built receiver has to make a choice Sentry makes for you. Sentry groups crashes by stack trace. But a release Hermes bundle is minified, so frame names are single letters and line/column positions change with every build. Group by frames, and the same bug opens a new issue every release.

Without source maps (more on that at the end), the most stable thing in a JavaScript error is its type and message. So the fingerprint is the exception type plus the message, with the parts that differ between sightings masked out:

_MASKS = [
    (re.compile(r"0x[0-9a-fA-F]+"), "<addr>"),
    (re.compile(r"\b[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}\b"), "<uuid>"),
    (re.compile(r"\b[0-9a-fA-F]{16,}\b"), "<hex>"),
    (re.compile(r"\d+"), "<n>"),
]

Cannot read property 'title' of undefined (reading index 3) and (reading index 17) become the same issue. If the SDK supplies its own fingerprint without {{ default }} in it, that wins, so I can force grouping from the client when the default is wrong. An event with no exception falls back to its masked log message, and one with neither falls back to the top in-app frame. For a native signal crash the message is something like Signal 6, Code 0, so those group by signal, which is coarse but honest until there’s symbolication.

Alerting without flooding the channel

#

Each fingerprint becomes one issue, and each report is stored as an event under it. The issue only logs at ERROR (which is what the chat alerts listen for) in exactly these cases:

• a new issue
• a resolved issue that comes back, which reopens it
• the 10th, 100th, 1,000th and 10,000th sighting

An ordinary repeat only increments a counter. An issue marked ignored keeps counting and never alerts. With the chat handler’s own rate limit on top, a crash loop on a bad release reads as a handful of messages rather than a wall.

Storage is bounded the same way: each issue keeps its 50 most recent events and deletes older ones as new ones arrive. That broke my first chart, because 50 events can’t tell you how often something happened last week, so each issue also keeps a running count per day for 90 days, updated in the same transaction as the counter. The chart draws from the counts; the events are only for reading.

Two small races are worth handling if you build one of these. When a brand-new crash hits several phones at once, two reports can both try to create the issue, so make the fingerprint unique and have the loser re-read the existing row. And measure the 90-day window from the server’s today, not from the newest report, because a phone with its clock set wrong can date a report anywhere, including next year.

Payloads are capped at 128KB. An event over that loses its breadcrumbs and debug metadata first, and if it’s still too big only the exception, message, release and platform are kept, with a flag so I know it was cut.

Scrubbing

#

The SDK runs with sendDefaultPii: false, so in principle no IP address, cookies or request bodies are sent. The server doesn’t rely on that: before storing anything it keeps only id and username from user and drops request entirely, in case a later SDK version or setting starts sending them.

Testing against a real device turned up two more things to strip:

• Breadcrumbs record full URLs, query strings included. The app’s search requests carry the search term in the query string, so a crash right after a search would have stored what the person searched for. The server now cuts every breadcrumb URL at the ?.
• Console breadcrumbs carry the raw arguments that were passed to console.log, which can be any object the app happened to log. The message text stays (it’s useful), and the arguments are dropped.

I only found those by looking at an actual report, which is the main argument for the next section.

The client side

#

On the app, everything goes through one small module, for the same reason I wrap the over-the-air update SDK: an OTA bundle also runs on binaries built before the native module existed. A top-level import * as Sentry from "@sentry/react-native" on a binary without RNSentry throws on import, and that’s a blank screen. So the SDK is required lazily, and only after checking the native module is actually there:

import { NativeModules, Platform, TurboModuleRegistry } from "react-native";
import Constants from "expo-constants";

const DSN = process.env.EXPO_PUBLIC_CRASH_DSN;

function nativeModulePresent(): boolean {
  try {
    return Boolean(TurboModuleRegistry.get("RNSentry") ?? NativeModules.RNSentry);
  } catch {
    return false;
  }
}

export function initCrashReporting(): boolean {
  if (!DSN || Platform.OS === "web" || !nativeModulePresent()) return false;
  const Sentry = require("@sentry/react-native");
  Sentry.init({
    dsn: DSN,
    release: Constants.expoConfig?.version ?? "unknown",
    sendDefaultPii: false,
    tracesSampleRate: 0,
    enableAutoSessionTracking: false,
    // ...turn off the other tracing options the same way
    maxBreadcrumbs: 50,
    beforeSend(event) { /* tag the OTA bundle */ return event; },
  });
  return true;
}

Errors only. The server doesn’t store traces, sessions, profiles or replays, so none of them are switched on. No DSN (development, E2E builds) means the SDK never starts. The build profiles set the DSN and an environment (staging or production), so both kinds of build report to the same endpoint and can be told apart. The signed-in user is set by account ID, never a name or an email.

The error boundaries needed an explicit call. Expo Router’s root ErrorBoundary catches a render error and shows its own screen, so that error never reaches the global handler the SDK hooks into. The fix is a small wrapper that calls captureException in a useEffect and then renders the router’s boundary as before, used for the root and per-route boundaries alike. It’s in an effect rather than in the render so it reports once rather than on every re-render. The root component is also wrapped with Sentry.wrap, and if that throws it falls back to the bare component.

For the web there’s a .web.ts version of the module with every function switched off. Metro picks the platform file, so the SDK never ends up in the web bundle at all. The web app has no native module to run on.

Proving a native crash arrives

#

The unit tests post hand-written envelopes, which proves the parser handles what I think the SDK sends. Two days after release, production had zero crash reports. Only three people had updated yet, so zero was plausible, but “nobody has crashed” and “crashes don’t arrive” look identical from the server. I wanted to see a real one.

So I built a Release simulator binary with the DSN pointed at a local Django on port 8000 and a throwaway key:

EXPO_PUBLIC_CRASH_DSN=http://localcrashtestkey0000@localhost:8000/1 \
EXPO_PUBLIC_CRASH_ENVIRONMENT=local-verify \
xcodebuild -workspace ios/MyApp.xcworkspace -scheme MyApp -configuration Release \
  -destination 'platform=iOS Simulator,id=<udid>' -derivedDataPath /tmp/iosbuild

(Release, not Debug: Debug builds link the dev launcher and behave differently, and Release is what people run.) Then installed it, launched it, waited a few seconds, and killed it the way a real fault would:

xcrun simctl install booted /tmp/iosbuild/Build/Products/Release-iphonesimulator/MyApp.app
xcrun simctl launch booted com.example.myapp      # prints the pid
kill -ABRT <pid>

Simulator apps are ordinary macOS processes, so a signal reaches SentryCrash’s handler exactly as it would on a device. The handler writes the report to disk; nothing is sent while the process is dying. On the next launch the SDK finds it and sends it. I relaunched, and the simulator’s network log showed a connection to :8000 a second later.

Then nothing in the Django log, which had me confused for a minute: the dev server only logs non-2xx responses at the level I had it on. The database had it:

SIGABRT: Signal 6, Code 0 | cocoa 1.4.0 iOS 27.1 iPhone19,4 handled=False
received 09:19:53, crashed 09:19:38
contexts: app, device, os, ota_updates, trace · 24 breadcrumbs

Fifteen seconds from crash to stored, most of which was me relaunching. And looking at the real payload is what taught me things the tests couldn’t:

• The user ID wasn’t the account ID. The test build isn’t really signed in, so sentry-cocoa fell back to its own per-install ID. Worth knowing, and worth saying in the privacy note: a report carries the account’s ID if you’re signed in and a random install ID if you’re not.
• There’s no time zone. I’d assumed the culture context would be there. The device context has locale, memory, screen size, low-power mode and the kernel version, but no time zone.
• Native crashes skip beforeSend. My JS beforeSend adds an ota tag with the running OTA bundle, but a native crash is assembled by the native SDK on the next launch and never passes through the JS hook. To tag native crashes, the tag has to be set on the scope with setTag once the bundle is known, so it syncs down to the native layer.
• The breadcrumbs showed what the app does. Console warnings, view-controller lifecycle, and HTTP calls, including the analytics SDK’s own requests to its collection endpoint, which is a good reminder of what else the app talks to. And the URLs had query strings, which is how I found the search-term problem above.

Reading them

#

The reports are read in the Django admin, on an issue page loosely modelled on Sentry’s: counts and Resolve / Ignore / Reopen at the top, a bar per day, the split by release, OS, device and OTA bundle, then one event at a time with its exception, its frames (app frames highlighted, library frames folded away), the breadcrumbs and the device context. It didn’t need a new dependency.

One fix came out of building it: for a native crash, the “culprit” frame was the binary’s path on the device, which includes a per-install UUID, so the same crash looked different on every phone. It now shows only the address and the binary name, like 0x1000a1b2c (MyApp).

The privacy policy, all of it

#

Crash reports are personal information, near enough: an account ID, a phone model, and what someone did in the minute before the app died. So the privacy policy needed a paragraph. Writing it properly meant saying exactly what a report carries, so I listed it from the payload I’d just looked at: the error, app version and OTA update, phone model, OS and language, free memory and screen size, the last few dozen steps (screens, web addresses with anything after a ? removed, the app’s own log lines), and the account ID or a random install ID. The policy also says the reports come to our server and not to Sentry or any other crash-reporting company. Retention gets its own line in the table: the 50 most recent reports of each problem, plus a daily count for 90 days.

Once I was checking one paragraph against the code, it was hard not to check the rest. The existing policy didn’t hold up. The delete-account page said push-notification tokens and passkeys were deleted immediately when you close your account, and that server logs were gone within 90 days. None of that was true. Closing an account unlinks the sign-in methods and anonymises the profile, but the push tokens and passkeys stay until someone deletes them by hand, and the log archive has no expiry yet. So the whole policy was rewritten from an inventory of what the code actually does, and those lines now say “not yet removed automatically; email us”. That’s less reassuring, and it’s accurate.

The repo now has a rule for it: the policy describes what the code does, not what we intend, and a change that collects, sends or keeps personal data somewhere new updates it in the same commit. That includes the summary screen in the app, the delete-account page, and the app-store privacy forms, which only live in the store consoles. Crash reporting was the change that made me write that down.

What’s missing

#

Symbolication. This is the real gap, and the one thing sentry.io does that I haven’t replaced. Stacks are minified for JavaScript and unsymbolicated for native code:

• JavaScript: frames point into the Hermes bundle. Fixing it means keeping the composed Hermes source map for every store build and every OTA bundle, keyed by release and bundle, and applying it to JS frames when the page renders. That’s the next piece, because most of our crashes will be JavaScript.
• iOS native: instruction addresses need the build’s dSYMs.
• Android: Java frames are obfuscated by R8 when minification is on (they need mapping.txt), and C++ frames need NDK symbols.

There’s also a smaller gap I found above: native crashes don’t carry the OTA tag yet, because it’s only set in beforeSend. Setting it on the scope once the running bundle is confirmed is a few lines I haven’t written yet.

For now, an issue tells me what crashed, on which release, OTA bundle and device, and what the person was doing just before. It doesn’t tell me where in the source. For a small app that ships a few times a week, the type, the message and the breadcrumbs have been enough to find things so far.

The receiver, the admin page and the tests aren’t a lot of code, and it costs nothing on top of the API that was already running. The SDK does the hard part, which is catching a crash on a phone and getting the report off it on the next launch.

I spend way too much time debugging. Everyone does. These days most of mine happens in Xcode and the simulator, chasing bugs in my own app, and the thing that keeps striking me is how much debugging machinery Xcode ships with that hardly anyone touches. This is the workflow I’ve settled into over the years, the parts that actually save time when something breaks.

Breakpoints Are More Powerful Than You Think

#

Most people click the gutter to set a breakpoint and leave it at that. Right-click one, though, and there’s a whole menu of options that changes how you debug.

Conditional Breakpoints

#

Say you’ve got a loop processing 1000 items and only item 347 misbehaves. Hitting the breakpoint 346 times first is a waste of an afternoon.

for i in 0..<users.count {
    processUser(users[i])  // Set breakpoint here with condition: i == 347
}

Right-click the breakpoint, add the condition i == 347, and Xcode only stops when it’s true. Works just as well with things like userId == "abc123" or error != nil.

Symbolic Breakpoints

#

These are for when you don’t know where a method is being called from. Open the breakpoint navigator (Cmd+8), click the + button, and choose “Symbolic Breakpoint”.

Want to see every time any view controller loads? Set the symbol to viewDidLoad and Xcode pauses on every single one. Too noisy? Narrow it down: MyViewController.viewDidLoad.

The ones I keep around permanently:

• UIViewAlertForUnsatisfiableConstraints catches Auto Layout conflicts the moment they happen
• objc_exception_throw breaks on any Objective-C exception before the crash
• malloc_error_break finds memory allocation problems

Exception Breakpoints

#

This should be the first thing you set up in any new project. Add one (breakpoint navigator, + → Exception Breakpoint) and Xcode pauses the moment something throws, instead of after the app has already died.

It’s caught more nil-unwrapping bugs for me than I’d like to admit, the kind that otherwise just show up as mysterious crashes in the console.

Breakpoint Actions

#

Breakpoints don’t have to stop execution at all. Edit one, click “Add Action”, and it can:

• Print variables without stopping: "User count: @(users.count)@"
• Run LLDB commands automatically
• Execute shell scripts
• Play a sound (I use this for rare code paths I want to know about)

Tick “Automatically continue after evaluating actions” and the breakpoint becomes a logger that never interrupts you.

LLDB: The Console Commands You’ll Actually Use

#

When you hit a breakpoint, the console at the bottom isn’t just for reading crash logs. It’s LLDB, and it’s genuinely useful.

The Basics

#

(lldb) po user
▿ User
  - id: "123"
  - name: "John Doe"
  - email: "john@example.com"

po prints objects in a readable format. That’s 90% of my LLDB usage right there.

Need more detail? Try p instead:

(lldb) p user.name
(String) $R0 = "John Doe"

And to see every local variable at once:

(lldb) frame variable

Changing Things at Runtime

#

This is where LLDB earns its keep: you can modify variables without recompiling.

(lldb) expr user.name = "Jane Doe"
(lldb) expr index = 0

Found a bug and want to try a fix without rebuilding? Change the variable and continue. I use this constantly when narrowing down edge cases.

You can call methods too:

(lldb) po self.refreshUI()
(lldb) expr navigationController?.popViewController(animated: true)

Navigation

#

(lldb) bt              # Show the call stack
(lldb) frame select 3  # Jump to a different stack frame
(lldb) continue        # Keep running (or just 'c')
(lldb) n               # Step over (next line)
(lldb) s               # Step into function

Watchpoints

#

Want to know when a variable changes? Set a watchpoint:

(lldb) watchpoint set variable user.isLoggedIn

Execution now pauses whenever that value changes, no matter where in your code it happens. Gold for tracking down unexpected state mutations.

Console.app: The Hidden Debugging Tool

#

Xcode’s console is fine until you need to see everything: system logs, crash reports, the lot. That’s when I open Console.app.

If you’re using OSLog (you should be), Console.app makes those logs searchable and filterable:

import os.log

let logger = Logger(subsystem: "com.example.app", category: "networking")

logger.info("Starting API request")
logger.debug("Request URL: \(url.absoluteString)")
logger.error("Failed to decode: \(error.localizedDescription)")

Then in Console.app:

1. Select your simulator or connected device
2. Filter by your subsystem: subsystem:com.example.app
3. Filter by level: subsystem:com.example.app AND level:error

You can save filter predicates for the sessions you run often. I’ve got one for network requests, one for database operations, and one that shows nothing but errors and warnings.

Why OSLog Over print()?

#

OSLog beats scattering print() statements everywhere. It’s structured, so you can filter by level and category. It’s fast enough that logging won’t slow the app down. It redacts sensitive data in production automatically, and the logs survive your app crashing.

print() is still fine for quick throwaway checks. Anything you might want to look at later belongs in OSLog.

Advanced Console.app Filtering

#

Console.app supports proper predicate queries. The ones I use regularly:

# All errors and faults in your app
subsystem:com.example.app AND (level:error OR level:fault)

# Network requests that failed
subsystem:com.example.app AND category:networking AND eventMessage CONTAINS "failed"

# Everything from the last 5 minutes
subsystem:com.example.app AND timestamp >= now(-5m)

You can also export logs to attach to bug reports, which beats copy-pasting out of Xcode’s console.

View Debugging

#

When the UI is broken and you can’t see why, the view debugger is the fastest way out.

Run the app, navigate to the broken screen, and click the “Debug View Hierarchy” button in Xcode’s debug bar (or press Cmd+Shift+D). You get a 3D exploded view of the whole hierarchy.

Rotate it around and things jump out:

• Views rendering behind other views
• Views sitting way off-screen
• Views with zero size
• The full constraint chain for whatever you select

I’ve used it to find invisible buttons swallowing tap events, labels rendering at 0x0, and an image that was accidentally 10,000 pixels wide.

Auto Layout Debugging

#

Purple warning icons in the view hierarchy mean constraint conflicts. Click one and Xcode shows exactly which constraints are fighting.

Give your constraints identifiers:

heightConstraint.identifier = "ProfileImageHeight"

When a constraint breaks, you’ll see "ProfileImageHeight" in the error instead of a memory address, which makes the log actually readable.

From LLDB you can also print the constraint tree:

(lldb) po view.hasAmbiguousLayout
(lldb) po view._autolayoutTrace()

Simulator Features That Save Time

#

Slow Animations

#

Debug → Slow Animations runs everything at 1/10 speed. Perfect for seeing what’s actually happening during a transition, or why an animation looks off.

Simulate Memory Warnings

#

Debug → Simulate Memory Warning tests how your app copes with low memory. I’ve found plenty of image caching bugs this way: everything works fine until the warning fires and suddenly all your images vanish.

Network Link Conditioner

#

Xcode → Open Developer Tools → Network Link Conditioner

Simulate 3G, LTE, high packet loss, or complete offline mode. If an API request has ever worked fine on WiFi and timed out on cellular, this is how you reproduce it.

I keep a “Bad Network” profile with 500ms latency and 10% packet loss. It surfaces timeout bugs and loading-state problems you’d never see on fast office WiFi.

Status Bar Overrides

#

Right-click the status bar in the simulator and you can override the time, battery level, signal strength, and carrier. Handy for consistent screenshots, or for checking how the UI looks at different battery levels.

Location Simulation

#

Debug → Location simulates different locations without leaving your desk: custom coordinates, city walks, freeway drives. Very useful for location-based features, or bugs that only show up in certain regions.

Memory Debugging

#

Debug Memory Graph

#

Click the Debug Memory Graph button (Cmd+Shift+M) and Xcode shows every object in memory, their relationships, and the part you actually care about: which ones are leaking.

Purple exclamation marks mean leaks. Click one and you can see the retain cycle.

The most common leak I see:

class ViewController: UIViewController {
    var onComplete: (() -> Void)?

    func setupHandler() {
        onComplete = {
            self.dismiss(animated: true)  // ❌ Captures self strongly
        }
    }
}

Fix it with weak self:

onComplete = { [weak self] in
    self?.dismiss(animated: true)  // ✓ No retain cycle
}

Delegates need to be weak too:

weak var delegate: ManagerDelegate?  // Not just 'var'

Instruments

#

For serious memory investigation, use Instruments (Product → Profile, or Cmd+I).

The Allocations instrument shows every object allocation, memory growth over time, which classes are using the most memory, and stack traces for where each allocation happened.

What I’m usually looking for: memory that grows linearly over time (probably a leak), unexpectedly large allocations (did I just load all 1000 images at once?), and objects that should have been deallocated but weren’t.

Mark generations (the little flag button) before and after an action to see what’s persisting when it shouldn’t.

Performance Profiling

#

Time Profiler

#

Product → Profile → Time Profiler. Record while doing the slow thing in your app, then read the call tree.

Sort by “Self Weight” to find the bottlenecks. If a function shows 40% self weight, that’s where your time is going.

I once found a JSON parsing function being called 1000 times a second. Moved it to a background queue and the UI stopped stuttering.

Main Thread Checker

#

Xcode automatically catches UI updates on background threads. If you see this:

Main Thread Checker: UI API called on a background thread: -[UILabel setText:]

you did something like this:

URLSession.shared.dataTask(with: url) { data, response, error in
    self.label.text = "Loaded"  // ❌ Crash!
}

Fix it:

URLSession.shared.dataTask(with: url) { data, response, error in
    DispatchQueue.main.async {
        self.label.text = "Loaded"  // ✓
    }
}

Runtime Diagnostics

#

Edit Scheme → Run → Diagnostics. There’s a row of checkboxes in here that catch bugs you’d never find by hand.

Address Sanitizer

#

Finds memory corruption: use-after-free errors, buffer overflows, memory leaks. It makes the app 2-3x slower, but it catches bugs that are near impossible to track down any other way. I turn it on when chasing crashes that only happen sometimes.

Thread Sanitizer

#

Catches data races and threading bugs. Enable it, run the app, and use it normally; if there’s a race condition in there, Thread Sanitizer will find it.

You can’t run Address Sanitizer and Thread Sanitizer at the same time, so I alternate between them when a crash is being weird.

Zombie Objects

#

Catches messages sent to deallocated objects. With it enabled, Xcode tells you exactly when you’re touching freed memory:

*** -[MyViewController viewDidLoad]: message sent to deallocated instance 0x600001234000

Don’t leave it on permanently. It stops objects from being deallocated, so memory climbs forever. But for pinning down a specific use-after-free bug, it’s great.

Common Debugging Scenarios

#

App Crashes on Launch

#

Add an exception breakpoint first; that usually catches it.

If not, the usual suspects are missing keys in Info.plist, force-unwrapped optionals in initialisation code, or dependency injection failing.

UI Not Updating

#

Every. Single. Time. It’s one of:

1. The update isn’t on the main thread
2. The outlet isn’t connected
3. The view isn’t actually visible (check with po view.window in LLDB; if it returns nil, the view isn’t in the hierarchy)

And for table or collection views: you forgot to call reloadData().

Memory Warnings Crashing the App

#

Use Instruments Allocations to see what’s holding memory. It’s usually images never released from a cache, view controllers that won’t deallocate (retain cycle), or some array or dictionary growing forever.

Simulate memory warnings in the simulator to test your cleanup code.

Mysterious Crashes

#

Turn on the sanitizers. Intermittent usually means threading, so run with Thread Sanitizer. Crashing inside system frameworks usually means memory corruption, so run with Address Sanitizer.

Crashes You Can’t Reproduce

#

When the crash happened on someone else’s phone, the report usually still exists. For TestFlight and App Store builds, Xcode’s Organizer (Window → Organizer → Crashes) collects crash reports from users who share analytics, symbolicated if the dSYMs went up with the build. For a tester’s phone, the reports are on the device itself under Settings → Privacy & Security → Analytics & Improvements → Analytics Data, as .ips files starting with the app’s name, and they can AirDrop one over. Start from the crashed thread’s stack trace, then work through the scenarios above.

Debugging OTA Updates in the Simulator

#

My app ships over-the-air updates, and the simulator is the easiest place to debug that whole flow.

I start by watching the network traffic. Console.app filtered to the app’s subsystem shows the manifest requests and responses in real time, so you can see exactly which headers go out and what the server sends back.

Then I make the network bad on purpose. Network Link Conditioner shows you how the update flow copes with slow connections and packet loss. Does the app hang? Show a loading indicator? Fall back gracefully?

Around the update check itself, I log everything: when the check starts, when an update is available, when the download begins, and when the new bundle loads.

import os.log

let logger = Logger(subsystem: "com.example.app", category: "updates")

logger.info("Checking for updates...")
let update = try await Updates.checkForUpdateAsync()
logger.info("Update available: \(update.isAvailable)")

Finally, it’s worth testing the manifest endpoint on its own. You can curl it with the same headers the app sends:

curl -H "expo-protocol-version: 1" \
     -H "expo-platform: ios" \
     -H "expo-runtime-version: 1.0.0" \
     https://updates.example.com/manifest

That confirms the server is returning the right data before you go digging into the client.

Third-Party Tools

#

Charles Proxy / Proxyman

#

See all your network traffic, modify requests and responses, test error conditions. Essential for API debugging.

Proxyman has a nicer UI than Charles and feels more at home on macOS. I switched last year and haven’t looked back.

Reveal

#

Like Xcode’s view debugger, but more capable. It works on physical devices without being attached to Xcode, which makes it great for chasing layout issues on testers’ devices.

Simulator vs Real Device

#

Most of my debugging happens in the simulator because it’s quick: no cable, no signing, no waiting for an install. But the simulator is an iOS build running on your Mac’s processor, with your Mac’s memory and your Mac’s network connection, and some bugs only exist on a phone.

So I build and debug logic in the simulator, and before a release I run the app on the oldest iPhone I still support. Performance, memory pressure and anything that touches hardware haven’t really been tested until they’ve run on a device.

Running on a Device

#

Plug the iPhone in, pick it as the run destination, and set a team under Signing & Capabilities (a free Apple ID is enough for your own phone). Since iOS 16 the phone also needs Developer Mode turned on under Settings → Privacy & Security, which restarts it the first time. Once it’s on, the phone’s own Settings → Developer menu has a Network Link Conditioner with the same bad-network profiles as the Mac’s.

Wireless Debugging

#

Plug the device in over USB once, go to Window → Devices and Simulators, tick “Connect via network”, then unplug. The device stays available in Xcode as long as you’re on the same WiFi.

Device Console

#

Window → Devices and Simulators → Open Console. This shows everything: system logs, app logs, crash reports. Far more detail than Xcode’s own console.

When a tester tells me “the app crashed”, I always ask them to plug their device in so I can grab the console logs. There’s often a system-level error sitting right there that explains the whole thing.

What I Actually Do When Debugging

#

1. Add an exception breakpoint if there isn’t one already
2. Reproduce the bug
3. Set a breakpoint near where I think it’s going wrong
4. Check values with po in LLDB
5. Modify variables to test fixes without recompiling
6. Check the view hierarchy if it’s UI-related
7. Profile with Instruments if it’s performance-related
8. Turn on the sanitizers if it’s memory or threading

The trick is working backwards from the symptom. Crash? Exception breakpoint. Slow? Time Profiler. Memory? Instruments. Weird UI? View debugger.

Tips I Wish I’d Known Earlier

#

Use assertions. They catch logic errors before they turn into bugs:

assert(users.count > 0, "Users array should never be empty here")

Commit before you start debugging. Once you’re changing things to test theories, you’ll want a clean point to revert to.

Delete your print statements when you’re done, or at least wrap them in #if DEBUG. Old debug logs make the next bug harder to see.

Learn LLDB properly. It’s faster than rebuilding your app twenty times.

And remember the simulator is not a real phone. Bugs that only appear on device are almost always threading or memory. Or performance, because the simulator runs on your Mac’s CPU rather than an actual iPhone chip.

Tools I Keep Open

#

• Xcode, obviously
• Console.app filtered to my app’s subsystem
• Proxyman for network debugging
• Instruments when things get serious

No single tool covers everything. The view debugger won’t find a memory leak, and Instruments won’t untangle an Auto Layout conflict, so most of the skill is matching the tool to the symptom. That part just comes with repetition: after enough retain cycles you start to smell them from the stack trace alone. Debugging never becomes fun exactly, but it does stop being miserable.