I've found a repeatable difference in input-to-display latency on macOS depending only on how an application is launched.
Launching an application normally:
open -n /Applications/App.app
consistently produces higher latency than directly running the exact same bundled executable:
/Applications/App.app/Contents/MacOS/App
I've reproduced this with a minimal Qt QPlainTextEdit application as well as Koi, Xcode, BBEdit, Sublime Text, and Zed.
It reproduces across:
- Mac mini M2 Pro, macOS Sequoia 15.7.9
- MacBook Air M4, macOS Tahoe 26.6.1
Minimal reproduction
The Qt application is essentially just:
import sys
from PyQt6.QtWidgets import QApplication, QPlainTextEdit
app = QApplication(sys.argv)
editor = QPlainTextEdit()
editor.resize(1200, 800)
editor.show()
sys.exit(app.exec())
I package this as a normal .app and compare:
open -n dist/QtLaunchTest.app
with:
dist/QtLaunchTest.app/Contents/MacOS/QtLaunchTest
Input-to-display latency is measured externally from generated keyboard input through to the corresponding visible pixel change on the display, with 200 measurements per run.
Results
(Launch method, avg, p95, p99)
At 60 Hz:
- Open normally, 29.676 ms, 37.742 ms, 43.080 ms
- Direct Mach-O, 16.404 ms, 20.500 ms, 24.882 ms
The p95 difference is 17.242 ms, compared with a 60 Hz frame interval of 16.667 ms.
At 100 Hz:
- Open normally, 24.687 ms, 31.182 ms, 33.797 ms
- Direct Mach-O, 16.295 ms, 20.623 ms, 23.286 ms
The p95 difference is 10.559 ms, compared with a 100 Hz frame interval of 10.000 ms.
That relationship is what makes me suspect this is related to presentation/frame scheduling rather than application processing.
This also happens with Xcode
The same effect occurs when comparing normal and direct launches of Xcode.
(Launch method avg p95 p99)
On macOS Sequoia 15.7.9:
- Open normally, 23.433 ms, 29.886 ms, 31.877 ms
- Direct Mach-O, 15.787 ms, 19.494 ms, 20.480 ms
On macOS Tahoe 26.6.1 on an M4 MacBook Air:
- Open normally, 35.830 ms, 40.122 ms, 53.996 ms
- Direct Mach-O, 23.639 ms, 27.233 ms, 37.855 ms
Koi, BBEdit, Sublime Text, and Zed show the same direction of effect.
Things I’ve ruled out so far
The difference does not appear to be caused by Terminal. Direct execution remains fast after detaching the process, and using open on the Mach-O itself is also fast.
Different LaunchServices forms (open -n, open -na, open -nb, open -b) all produce the slower behavior.
I've also compared process QoS and final AppKit activation state, which are the same.
Most importantly, application-side instrumentation does not show the additional latency. Input processing and painting complete quickly in both cases. The difference appears only when measuring through to the actual pixel change on the display.
Question
Is there some presentation, WindowServer, Core Animation, RunningBoard, or application-lifecycle state established when an application is launched through LaunchServices that could affect when completed rendering reaches the display?
The refresh-rate result makes it look as though the normally launched application is reaching the display approximately one presentation opportunity later:
- Direct:
input → update → paint → presentation N - Normal:
input → update → paint → presentation N+1
That's only a model based on the measurements. I haven’t directly observed the presentation sequence.
I'm particularly interested in what APIs or Instruments traces could expose the difference between these two processes after they’ve reached the same active AppKit state.
I've documented the full investigation, including additional measurements and tests, here:
https://hackerman.ai/research/investigating-macos-input-to-display-latency/
Any pointers on what to instrument next would be appreciated.