Start profiling and SimBuddy relaunches the app with its probe, or joins a Run from Xcode without a relaunch. Every hang shows the line the main thread waited on, and leaks and growing memory name the type that made them.
Free: three profiler sessions a day, 30 minutes each.Pro: no daily limit.
A tap freezes SimBuddyDemo, and the Profiler names the 1528 ms hang in ProfilerLabModel.waitForLock() at ProfilerLab.swift:168. Then a sample of an update storm, a leak with the line that allocated it, and what keeps a cache alive.
The timeline draws hangs, late frames and memory while you use the app. Anything that holds the main thread for 250 ms or more is a hang, and 100 to 249 ms a stall.
When a hang ends, it names the function and the line it was stuck in: here, a lock in ProfilerLab.swift at line 168.
Press Find leaks, then open and close the screen you suspect. SimBuddy keeps watching: each new leak shows up by type and, with allocation stacks on, with the line that allocated it.
For memory that is still referenced but keeps growing, take a Baseline, repeat the interaction and Compare.
Record an Instruments trace and SimBuddy reads it for you: which view’s body ran most, for how long, and which of the app’s functions held the main thread.
SimBuddy from the App Store gives you the Terminal command to record the trace, then reads it from the SimBuddy folder.
Each command answers with findings an agent can act on, the same across runs, so it can fix a hang and check that it went.
$ simbuddy profiler start com.example.app --stack-loggingThe probe and allocation stacks, so leaks name their line.
$ simbuddy profiler hangs com.example.appEvery hang, stall and late frame since the start.
$ simbuddy profiler leaks com.example.appAfter opening and closing the screen you suspect.