Native iOS
application development
in Mountain View

A complaint that an app feels slow rarely points at a cause. Users describe symptoms, not code. Scrolling stutters. A camera screen takes a beat to open. The battery drains faster than other apps on the same home screen. Turning a vague report into a fix means finding the right tool for the right symptom. Xcode Instruments is built around that idea. It is a set of focused recorders, each tuned to one class of problem.

Time Profiler samples the call stack many times a second. It then builds a tree of which methods actually consumed CPU time. A scrolling stutter almost always shows up as a heavy method buried under a table view delegate call. Often it is string formatting or image decoding running on the main thread instead of a background queue. Reading the call tree from the top down beats guessing which function looks suspicious. That habit alone separates a fast fix from a week spent changing code that was never the problem.

Allocations and the Leaks instrument answer a different question. Is memory climbing when it should not be. A healthy screen opens, does its work, and settles at a stable level once the user leaves it. A screen with a retained closure keeps climbing every time it is visited. The generational view in Allocations makes that pattern visible across repeated visits rather than a single snapshot. Catching this in development, on a script that opens and closes a screen fifty times, costs far less than catching it from a support message.

Energy Log breaks battery drain into the parts actually responsible for it. CPU activity. Network requests. Location services. Screen brightness. An app that quietly polls a server every few seconds, or keeps location tracking on after a map screen closes, shows a flat high cost long after the user has moved elsewhere. The fix is rarely to remove the feature. It is to shorten how long the feature keeps running once nobody needs it.

The Core Animation instrument reports frames per second and flags the ones that missed their deadline. On a faster display, a dropped frame is a shorter window than it was on an older screen. Animation that felt fine in development can feel rough on real hardware. Offloading layout work from the main thread helps. So does sizing images to the dimensions they will actually be shown at, and avoiding shadows on views that move.

Launch time gets its own instrument because it happens in phases a stopwatch cannot separate. Time before the app code runs at all. Time in static initializers. Time from the first drawn frame to a usable screen. A slow launch is rarely one big delay. It is usually several small ones stacked together, easy to miss without a breakdown of where the seconds went.

Profiling only on the newest phone in a drawer of test devices hides problems. A person on an older supported model will hit them immediately. Lower core counts and less memory headroom turn a barely noticeable stutter into a visible one. A short pass on an older device before each release catches what a fast development machine cannot reproduce.

None of this ends at release. MetricKit collects launch time, hang rate and memory use from real installs and reports the numbers back in aggregate, without pulling raw logs off the device. A launch that felt instant on a bench can still be slow for real users on older hardware or a weak connection. MetricKit is the only practical way to see that gap once the app is out in general use.

Profiling should not wait for a complaint. A short Instruments pass before each release, checked against earlier numbers, turns performance into something measured on a schedule. That beats arguing about it after a bad review lands on the store page.