# Fingertips: showing touches on screen during an iOS presentation

> Fingertips is a single-class iOS library that replaces your UIWindow so every touch and gesture is drawn on screen as a fading circle, which is what a presenter needs when the audience cannot see the device. It uses no private API, requires iOS 11, and it deliberately does not do the mirroring or the screen recording.

**mapbox/Fingertips** — Touch indicators on external displays for iOS applications.

- Repository: https://github.com/mapbox/Fingertips
- Stars: 828 · Forks: 91
- Language: Swift
- License: BSD-3-Clause
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/mapbox-fingertips

## The problem a presenter actually has

Fingertips is described as a presentation mode for your iOS app, and a small library, one class, meant for presentations from iOS devices that shows all touches and gestures so that the audience can see them.

The problem it solves is narrow and real. When a presenter holds a phone and taps small controls, the audience watching a projector sees a cursor-less rectangle and a fingertip covering exactly the thing being discussed. The touch indicator draws a partially transparent circle at each touch point, and it fades out when the touch ends, so the screen shows both the interaction and the result.

What makes it worth a dependency is the framing. The README states the limitation up front: this library does not do the mirroring or screen recording for you. It is not a capture tool with a drawing feature bolted on, it is only the drawing. A presenter who already has a mirroring setup, a screen recording tool or a wired display, adds Fingertips to that and gets the missing piece.

The audience for it is a developer who presents, which is a narrower audience than the iOS developer population but a real one, and the feature set reflects that narrowness rather than trying to be a general purpose overlay library.

## Dropping in the replacement UIWindow

The integration is a subclass of UIWindow, and the README says the app automatically determines when a screen recording is in progress or an external screen is available. In other words, the class decides for itself when the indicators should appear, rather than the developer wiring up a toggle.

For a storyboard based app, the override goes in the application delegate.

```objc
// AppDelegate.m

- (UIWindow *)window {
    if (!_window) {
        _window = [[MBFingerTipWindow alloc] initWithFrame:[UIScreen mainScreen].bounds];
    }
    return _window;
}
```

The Swift version is a single line.

```swift
// AppDelegate.swift (Swift)

var window: UIWindow? = FingerTipWindow(frame: UIScreen.main.bounds)
```

And for iOS 13 and later with a UISceneDelegate, the window is created inside the scene connection callback with the scene's own window scene.

```swift
var windows: [UIWindow] = []

func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
    guard let windowScene = scene as? UIWindowScene else { return }

    let window = FingerTipWindow(windowScene: windowScene)

    window.rootViewController = // Your root view controller
    window.makeKeyAndVisible()

    windows.append(window)
}
```

Three integration paths are documented, and the third one is the one most current apps need, since a project on iOS 13 or later with scenes has no single application delegate window to override. The naming differs between languages, MBFingerTipWindow in the Objective-C example and FingerTipWindow in the Swift ones, which is a small inconsistency worth knowing about before you go looking for a class that appears to be missing.

## The five configuration knobs

The README is clear that you should not need to configure anything, and then lists what can be tweaked if you want to.

`touchImage` takes a UIImage to use for showing touches, which is the escape hatch for a designer who wants a different indicator shape entirely rather than the default circle. `touchAlpha` changes the visible-touch alpha transparency, which is the knob that matters most in a bright room where a faint indicator is invisible.

`fadeDuration` changes how long a lifted touch fades out, and this one is a presentation decision rather than a visual one. A long fade leaves a trail of where the presenter's finger was, which helps the audience follow a drag, and a short fade keeps the screen clean for a tap-and-tap demo.

`strokeColor` changes the default touchImage stroke color, which defaults to black, and `fillColor` changes the default touchImage fill color, which defaults to white. Those two are what let the indicator stay visible on both a white slide and a dark video.

Five properties, all optional, and the defaults are sensible. That is about the right size for a library with one class, and it is worth noting as a contrast with the many-configuration surface of a general overlay framework.

## Debugging the indicators themselves

There is a specific trap here that the README addresses directly, and it is the kind of thing that would otherwise cost an afternoon.

When Fingertips is active only during a screen recording or with an external display attached, a developer testing on a simulator or on a device without a mirror will see nothing at all, and will reasonably conclude the library is broken.

The fix is two ways round. Setting the DEBUG_FINGERTIP_WINDOW environment variable to YES in Xcode, or setting the runtime property alwaysShowTouches to YES, forces the indicators to display regardless of the recording or external display condition. The README phrases it as if you would ever need to debug Fingertips, which is exactly the situation this covers.

For a library whose entire effect is a visual overlay that is conditional on an environment you cannot easily reproduce, having a documented escape hatch is a real design decision rather than a convenience.

## Where Fingertips is the wrong tool

The first limitation is the one the README states, that the library does not do the mirroring or screen recording. If your problem is that the audience cannot see the device screen at all, Fingertips does not help, and you need a capture setup first. The library assumes that part is solved.

The second is that it draws touches, not gestures. The README says it shows all touches and gestures, and the configuration options are all about the touch image, the alpha, the fade and the colours. There is no configuration for drawing a swipe path, a pinch or a rotation, and the default indicator is a point that fades rather than a trail. A presenter whose demo depends on the audience understanding a drag gesture is served by the fade duration rather than by any gesture rendering.

The third is the platform floor and the requirement for ARC. The README states that Fingertips requires iOS 11.0 or greater and ARC, so a project on an older deployment target cannot use it, and a project with manual reference counting cannot use it either. That is a small thing now and would have been a real barrier before.

The fourth is the maintenance shape. The recent releases are 0.6.1 from 2026-06-16, v0.6.0 from 2023-05-15 and v0.5.0 from 2016-08-29, and the copyright line reads 2011-2023. The last push was on 2026-06-16, so the code is not abandoned, but a long gap between the 0.5.0 and 0.6.0 tags suggests an infrequent release pattern. For a library with one class and no private API that risk is small, but it is a risk.

The fifth is the app store claim, which is a claim about API usage rather than about behaviour. The README says it uses no private API and is safe for App Store submissions, and that is verifiable by inspection of the source rather than by trusting the sentence. A library that overlays every touch on a window does draw over your interface, which is fine for a presentation build and is something to think about if the same build ships to the store.

## Fingertips compared with screen recording and with a custom overlay view

The first comparison is with the recording tools themselves, and the difference in approach is that those tools capture the display while Fingertips annotates the interface before the capture happens. The order matters: if the touch indicator is drawn into the window, it appears in the recording, in the mirrored display and in the AirPlay output, because it is part of the view hierarchy rather than something added afterwards by a capture tool.

That is the architectural point. A recording tool that composites a cursor over a finished video has to draw the indicator itself and knows nothing about your app. Fingertips knows about your app's touches and is drawn by your app's window, so it appears everywhere your app appears.

The second comparison is with writing your own overlay. The work is not large: a UIWindow subclass that overrides the touch handling, keeps a set of active touches, adds a view per touch and removes it on end. For a one-off demo that a developer writes in an afternoon, that is a reasonable alternative and it avoids a dependency entirely. The case for the library is that it already handles the screen recording and external display detection, which is the fiddly part, and the fade behaviour, which is the part that has to be tuned to look right rather than merely work.

The third comparison is with a remote control app such as a VNC or screen mirroring tool, which is not a competitor but a complement. Fingertips assumes the display is already on a screen the audience can see, which for an iOS presenter usually means a mirroring app such as QuickTime on a Mac or a wired adapter, and the touch indicators then travel with that feed.

## Licence, packaging and the state of the code

The licence field on the repository records BSD-3-Clause, and the repository contains a LICENSE.md file. The README's licence section notes the copyright as Mapbox, Inc. for 2011 to 2023, and asks that the library be accompanied by a LICENSE file, with a note to contact Mapbox if no licence exists in a distribution.

The packaging is straightforward for a modern iOS project. The repository has a Package.swift file, so it is a Swift Package Manager dependency, and a Fingertips.podspec, so it is also available through CocoaPods for projects that still use it. The sources live under Sources/, and there is an Xcode project, Fingertips.xcodeproj, plus a CODEOWNERS file. A FOSSA status badge in the README points to a licence and vulnerability scan of the dependencies, which is the sort of check a company-owned open source project usually carries.

The project is not archived and the last push was on 2026-06-16, the same day as the 0.6.1 release, so the code is current. The gap between the tags is the notable thing, with a seven-year stretch between 0.5.0 in 2016 and 0.6.0 in 2023 and a gap of three years to 0.6.1, which is a pattern consistent with a library that gets occasional attention when a presenter needs it rather than one that is maintained continuously.

For a dependency that does one thing, uses no private API and has a small surface, that is an acceptable profile. The one thing to check before depending on it is the deployment target of your own project, since iOS 11 is the floor and the scene delegate path only applies from iOS 13.

## Conclusion

Fingertips suits anyone giving a conference talk, a demo or a screen recording where the audience has to see where the presenter's fingers are, and who wants a one class change rather than a capture setup. It is the wrong tool if you need the mirrored display or the recording itself, because the README says plainly that the library does not do either, and the wrong tool for a project that wants gestures rather than touch points. Before adopting it, read the licence file, since the library asks to be accompanied by a LICENSE file and the terms live there, and check that your deployment target is iOS 11 or later, which the README states as the minimum.

## FAQ

### What does the Fingertips iOS library do?

It is a single class library that replaces your UIWindow so that every touch is shown on screen as a partially transparent graphic that fades out when the touch ends, which lets the audience see the interaction during a presentation. It does not do the mirroring or the screen recording.

### How do I add Fingertips to an iOS app with a scene delegate?

Create the FingerTipWindow inside the scene connection callback using the scene's windowScene, set its rootViewController, call makeKeyAndVisible and keep it in the windows array, as shown in the README's iOS 13 example.

### What can I configure in Fingertips?

Five optional properties: touchImage for a custom indicator, touchAlpha for the transparency, fadeDuration for how long a lifted touch fades, and strokeColor and fillColor for the default image colours, which default to black and white.

### Why do I not see any touch indicators while testing Fingertips?

The library shows the indicators when a screen recording is in progress or an external screen is available, so a plain test run shows nothing. Set the DEBUG_FINGERTIP_WINDOW environment variable to YES in Xcode, or set the alwaysShowTouches runtime property to YES.

### Does Fingertips use private API?

No. The README states that it uses no private API and is safe for App Store submissions, and it requires iOS 11.0 or greater and ARC.

### How do I install Fingertips in an iOS project?

The repository ships a Package.swift file for Swift Package Manager and a Fingertips.podspec for CocoaPods, so it can be added either way as a dependency of your app.

## Sources

- [Issues](https://github.com/mapbox/Fingertips/issues)
- [License: BSD-3-Clause](https://github.com/mapbox/Fingertips/blob/main/LICENSE)
- [mapbox/Fingertips on GitHub](https://github.com/mapbox/Fingertips)
- [README](https://github.com/mapbox/Fingertips/blob/main/README.md)
- [Releases](https://github.com/mapbox/Fingertips/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mapbox-fingertips