Find the cause of the crash or slowdown, not another workaround.
Intermittent crashes and performance regressions rarely improve through guesswork. I use production evidence, controlled reproduction and Apple’s profiling tools to narrow the problem, verify the cause and measure the result.
Problems I investigate
- Crash clusters, and reports that will not symbolicate.
- Slow cold and warm launch.
- Frozen or unresponsive UI.
- Scrolling hitches and dropped frames.
- Memory growth, retain cycles and termination under pressure.
- Main-thread contention and concurrency defects.
- Expensive SwiftUI view updates or UIKit layout work.
- Networking, image loading or persistence bottlenecks.
- Regressions tied to a release, an OS version or a device class.
How I work through it
- Define the symptom and a baseline. What a user actually experiences, and a number we can compare against later. Without a baseline there is no way to prove a fix.
- Gather the evidence that already exists. Crash reports, traces, version and device distribution, and what changed recently. Most investigations start with data you already have but have not yet cut the right way.
- Reproduce where possible, and profile the real path. Instruments on a physical device, on the OS versions and hardware your users are actually on.
- Form and test hypotheses one at a time. Changing several things at once is how a team ends up with an app that behaves differently and nobody knowing why.
- Implement or recommend the smallest reliable fix. The narrowest change that addresses the cause, rather than a defensive workaround layered over the symptom.
- Compare before and after, then protect the result. Measured evidence that the problem is gone, plus monitoring or a regression test so it does not quietly return.
What you receive
- A written diagnosis with the evidence behind it.
- The code fix, where that is within the agreed scope.
- A measured before-and-after comparison.
- A monitoring or alerting recommendation.
- The related risks I found but did not chase, so you can decide about them.
How the engagement is shaped
Investigation work suits a timebox. We agree a symptom, a baseline and a number of days. At the end of that window you get the evidence gathered, what has been ruled out, and a recommendation: fix it now, keep digging, or accept it and monitor.
Evidence first, then a fix. I will not ship a speculative change to a production app and call it a resolution. If I cannot show the problem before and its absence afterwards, the work is not finished.
Relevant experience
Why this work suits me
At Westpac, diagnosing and fixing performance regressions in a high-traffic national app is part of the job: launch time, scrolling problems, memory growth and main-thread contention, in a codebase used by millions of people.
At Motorway I designed the Firebase and Datadog RUM dashboards the mobile organisation used to see production behaviour, and at GlowUp I ran Crashlytics-led product operations across three years of releases. Instrumenting a product so that the next regression is visible early is as much a part of this service as fixing the current one.
Common questions
Does the crash need to be reproducible?
It helps enormously, but no. Plenty of real production crashes are not reproducible on demand. In those cases the work leans harder on crash reports, device and OS distribution, recent change history and targeted instrumentation to narrow the conditions until the problem becomes reproducible.
Do you need access to Crashlytics and App Store Connect?
Read access to whatever crash reporting and analytics you use is the single most valuable thing you can provide. App Store Connect access helps with version and device distribution and with phased-release evidence. If access is restricted, exported reports can work, though it slows the investigation down.
Do you test on physical devices?
Yes. The simulator is useful for a first look, but launch time, scrolling performance, memory pressure and thermal behaviour only mean something on real hardware, ideally on the device classes where your users are actually seeing the problem.
How long does an investigation take?
A focused investigation into a single symptom is often a few days. Broad, intermittent or long-standing problems take longer, because the work is narrowing possibilities rather than applying a known fix.
Can you guarantee you will find the cause?
No, and I will not pretend otherwise. Non-deterministic problems sometimes resist a fixed initial timebox. What I will do is work in a structured way, tell you what has been ruled out, and be honest at each checkpoint about whether continuing is worth your money.
Related reading
What is the app doing?
Describe the symptom, when it started and what evidence you already have. I will reply by email with a view on how I would narrow it down.