Skip to main content
Every run on a simulator takes four numbers while it checks your flow. They land in perf in results.json, in the HTML report, in the pull request comment and in JUnit (properties perf.launchMs, perf.memoryMb and perf.hangs).

Set a budget

Set limits with budget in a check file (the keys):
A run over a limit fails with class budget_exceeded and says which number and by how much. A limit on a number the run couldn’t take, such as memory_mb on an iPhone, ends the run needs_review with class budget_unmeasured. Mobster never passes a budget it can’t check.

Read what a check measures

What Mobster doesn’t measure is in perf.notMeasured, so a missing number says why:
  • First frame. A simulator writes no log line that marks the app’s first frame, so launch has no firstFrameMs. Cold launch ends at the first stable screen, which comes after the first frame.
  • Dropped frames. A simulator exposes no Core Animation commit times, and MetricKit isn’t available in one.
  • Memory on an iPhone. A phone run takes the two launch times and the hang count, and memory is null.
  • Hangs on a simulator. A simulator may not log hangs at all. A count of 0 means no hang line appeared.

Watch the numbers over time

mobster test --history keeps the numbers per run and marks the last run against the median of the last 10 passes before it. ↑ is 20% more launch time or memory, or more hangs than the median. ↓ is 20% less, and → is in between. It marks nothing until 3 earlier passes have the number.
The marker flags a trend and never fails a check. Only budget fails one. --history --json adds perfLatest (the last run’s numbers) and perf (each number’s marker, latest value, baseline median and run count) to every row.