There should be a pinned topic about macOS 26.
After my own experience and reading in the forum.
Takes almost 40 seconds to actually start vdmx.
This is also my own experience of today.
Ui issues and clock / sync issues.
This is also most likely an tahoe issue.
Thanks! (Great idea!) Just pinned this topic 
We’ll also add this to it:
In general as it is now it feels like vdmx don’t get app focus from macOS 26. The startup (ifs), output window always on top is broken, ui focus.
I’m happy if I can help in any way. Spindumps memory dumps. I’m about to fire up macOS 15 on utm to test some things. I know vm is not optimal but anyway : )
UPDATE!
----------------------------------------------------
SECTION 1 — Summary of the Issue
VDMX may show the following symptoms on macOS 26.2 (Tahoe):
Slow startup (20–40 seconds)
Output window not staying on top
Lag or stuttering when another window overlaps the output window
UI sluggishness
Window ordering inconsistencies
These issues are NOT caused by:
GPU load
Metal fallback
CoreAnimation failures
OpenGL compatibility issues
Compositor throttling
All graphics subsystems appear healthy.
The root cause is macOS 26’s stricter handling of SecureTextInput.
macOS 26 introduced a change in the SkyLight window manager:
When SecureTextInput is active, macOS blocks applications from raising windows or changing window levels unless the action is directly triggered by the user.
SecureTextInput is activated by:
Spotlight search
Save/Open dialogs
Finder rename fields
Notes or any NSTextField
Safari URL bar
Password fields
Autofill scanning for sensitive fields
VDMX relies heavily on:
Custom window levels
Always‑on‑top output windows
Programmatic window ordering
When SecureTextInput is active, macOS denies these operations. This causes:
Slow startup (VDMX repeatedly tries to set window levels)
Output window failing to stay on top
Lag when overlapping windows
UI stuttering
WindowServer “deferring events” spam
This behavior did not occur in earlier macOS versions.
Example log lines confirming the issue:
“CPS: Denying VDMX6 Plus the right to be in front because secureTextInput is active and this process doesn’t have secure text mode enabled, and this request was not caused by user activity”
“Deferring events from frontmost process…”
These appear repeatedly during VDMX startup and window creation.
No GPU or compositor errors appear.
When a text field is focused:
macOS enables SecureTextInput
macOS blocks VDMX from raising its output window
VDMX continues trying to reorder the window
WindowServer defers focus and ordering events
The compositor stalls
Visible lag occurs in the output window
Dragging a save dialog or rename window over the VDMX output window reliably triggers this.
Autofill can activate SecureTextInput in the background while scanning for password fields.
Disabling Autofill reduces the frequency of the issue.
Open Spotlight or any text field.
Launch VDMX.
Observe slow startup.
Drag a save dialog or rename window over the VDMX output window.
Lag and window ordering issues appear.
Close Spotlight and relaunch VDMX.
Behavior disappears.
Disable Autofill
Close Spotlight before launching VDMX
Avoid having text fields active during performance
Launch VDMX immediately after login for a clean input state
Use a second display for the output window
Avoid Safari password fields or URL bar during shows
Avoid Finder rename fields during shows
Avoid renaming or inputing text in any box even inside vdmx when running a live show for now
WindowServer denies window‑ordering requests when SecureTextInput is active.
VDMX attempts to set window levels and bring windows forward during startup. These calls are blocked unless user‑initiated.
Graphics subsystems show no errors.
Recommendations:
Consider explicitly requesting secure text mode during window‑ordering operations
Delay window‑level changes until SecureTextInput is inactive
Provide a fallback window‑ordering path when CPS denies SetFrontProcess
File a report with Apple referencing the CPS denial logs
These are not accurate, not are they helpful. FYI
Ok. This is really weird then as I do this it actually runs better then before. Do any I e know what this is about then as there is more er users then me that got this issue? What can I do more? I’m going to pull all logs, screen record what’s going on. And then make a clean install with mafia and only vdmx.. Last solution. It’s either macros or the m4 chip. It’s impossible to send logs in the bugreport as it don’t have to do anything with the project..
The reason why there’s an update guide to MacOS 26 that said do not update until there’s an update of VDMX6 is primarily due to the massive amount of issues that frequently arise when Apple releases a new version of OSX. Yes, Apple Beta tests, on their users. I remember when OSX 14 was released it took 6 months to resolve an issue that only occured for users with 64GB of RAM. Everyone running 16GB or 32GB didn’t have issues until an OSX patch came and fixed the issue.
There’s a reason why dropbox took well over a year before it made a native Apple Silicon version of their app (partial laziness, and waited for apple to work out the kinks).
With macOS 26 there will inevitably be issues, but it also takes time before they can be fixed in VDMX, because sometimes apple will release an OS update that fixes the issue on their end.
The list of reports of this has been noted, but half of the stuff that copilot, gemini, and chatgpt spits about bugs is speculative if not entirely made up.
If you ask those LLMs how to do something inside VDMX (that it actually can’t do), it will give you a step by step procedure on how to do it with menus and plugins that don’t exist. They don’t have access to the source code, so they don’t know.
All right. Anyhow going to downgrade. What Copilot helped me do was analyze the log from the process windowServer I also read the log myself. Also when looking at the system monitor the autofill process was hooked on and that’s probably normal as WebKit etc. Copilot advised me to try to shut off all “auto fills” as the log was complaining about secure input and the Windows Server. When doing so the stutter and ui lag actually did get minimal but still there. Startup time was below 8 seconds. Did this 5 times on and off to check. Also opening a note or a writepad and covering the output window made it stutter again. What made me suspect the focus part was that on top output window did not work. I have been using VDMX since 2012 so I am not totally new.
When reading the blog post about macOS26 it also said
“ So far we have not run into any issues with using the latest release of VDMX6 in macOS 26, but if you run into any problems, or just want to let us know about your experiences with Tahoe, please send us feedback using the Report Bug option from the Help menu in VDMX, or send an email to support@vidvox.net.”
That made me install 26. Also, there were no actual posts about any issues. I also asked.
macOS 26 got some nice things going on with Metal4 and it would make more use of my m4 chip. Other tools was also working fine. Like td and mm.
I also thought it had to do with the M4 chip first so I thought I could help as I was unsure if David or Ray might have access to a new M4.
Anyhow the advice I got actually made things work better than before and it also solved the questions I had earlier when I asked in the macOS26 thread. Sending the project in the bug report won’t help as it’s not logged there. As more people had the same issue I posted my findings. Don’t be so negative I was trying to help. I was using Copilot as an aid not like some magic wand.
A note on upgrading from Sequoia to Tahoe on Apple Silicon. To my surprise FileVault was automatically turned on during the upgrade process without asking. Really a moot point as internal storage is encrypted by default on Apple Silicon or a Mac with the T2 chip. But worth noting for anyone considering moving to Tahoe and considering optimisation for production machines. Same rule applies → use a fast external drive for your clip library regardless of what version of macOS you are running.
Thank you for clarifying that and sorry for my tone. I just didn’t want someone to read it as a “fix” when it most likely requires an update (from VDMX and/or MacOS).