Problem

Showing touch indicators is an important part of UI tests for debugging issues around animations and timing. We’ve all run into flaky failures where a tap happens mid-animation and the whole test goes sideways. Without tap indicators, debugging those failures becomes pure guesswork.

iOS simulators have a preference you can flip to enable touches:

defaults write com.apple.iphonesimulator ShowSingleTouches 1

Sounds perfect, right? Except it isn’t. The biggest issue is that these indicators don’t show up in the screen recording. And that’s exactly where you need them the most — in CI runs or Maestro cloud for us, where a recording is the only way to see what actually happened.

Exploring Solution: Ray of Light

When we started digging into this, most solutions we found were either hacky or impractical for automation. A lot of them required installing some third-party tool on the machine or running things like QuickTime player to capture the touches. That might work for a one-off demo, but it doesn’t scale when you’re running hundreds of UI tests in CI. At Maestro we run roughly five thousand tests daily, so anything that doesn’t fit cleanly into automation is basically a non-starter.

There’s even a long Reddit thread full of people running into the same wall — you enable touches in Simulator, but they vanish when you are recording screen.

One of the more interesting attempts we came across was ShowTime . The way it works is by intercepting touch events inside the app and then drawing a dot wherever you tapped. Think of it as sitting between iOS and your app’s UI: every time a touch comes in, it drops a little marker on the screen so you can see it. For iOS engineers, this happens through a technique you might be familiar with — method swizzling on the UIWindow object.

But here’s the catch:

It only works if you integrate its code into your app.
It doesn’t help with system interactions (like home screen taps, app switching) or with apps like safari.

So while ShowTime proves the idea is possible, it still doesn’t solve the bigger problem: we need a solution that just works, everywhere — Simulator, SpringBoard, Safari — without needing to change app code.

Eureka! What worked?

Since ShowTime gave us a spark of inspiration, we started digging into how we could take its idea and make it work for any app under test. The concept was straightforward:

Build a dynamic library version of ShowTime.
Inject that library into the app at launch time so it runs automatically.

Let’s break it down.

Generate the framework binary

This part was easy. We didn’t have to rewrite ShowTime — just change its packaging so that instead of being compiled directly into an app, it produced a framework that could be dynamically linked when the app started. This can be done by changing packaging to a dynamic type:

let package = Package(
    name: "ShowTime",
    products: [.library(name: "ShowTime", type: .dynamic, targets: ["ShowTime"])],
     .
     .
     .
)

Injecting the framework

Once we had the framework, we could hook it into the app process at launch using DYLD_INSERT_LIBRARIES. On Simulator, it looks like this:

export SIMCTL_CHILD_DYLD_INSERT_LIBRARIES=path/to/ShowTime.framework/ShowTime &&
xcrun simctl launch booted org.wikimedia.wikipedia

What this does:

SIMCTL_CHILD_DYLD_INSERT_LIBRARIES tells iOS to preload our ShowTime framework into the app process.
xcrun simctl launch boots the app with that environment variable set.

The result: every tap you make during the test gets drawn on screen. VOILA! Here is a sample:

This is not it — you can actually make this work simulator-wide by injecting the library into SpringBoard.

Here are the commands for it:

xcrun simctl spawn booted launchctl setenv DYLD_INSERT_LIBRARIES /path/to/ShowTime.framework/ShowTime
xcrun simctl spawn booted launchctl stop com.apple.SpringBoard

That restarts SpringBoard with the tap indicators enabled, so they show up everywhere — even inside system apps like Safari. Demo here:

What's Next?