Xenon v4.11.3: macOS stops forgetting Xenon’s permissions
A Mac release. Installing Xenon on a Mac did not finish, uninstalling it did not finish, and once it was running macOS kept asking for permission to read folders you never pointed it at. All of it came from two causes, and both are fixed here.
Windows and Linux are untouched by everything below; the update is small and you can take it whenever.
Added
macOS stops forgetting Xenon's permissions every time it updates. macOS ties a permission — Full Disk Access above all — to the app's code signature, and Xenon's signature was generated fresh at every build. So every release looked to macOS like a completely different app, and everything you had allowed silently stopped applying. The switch in System Settings still showed as on, and did nothing: that list shows a name, while macOS compares a signature.
Xenon now carries its own certificate, which stays the same from one release to the next, so a permission granted once keeps working. This update resets it one last time, because this is the release where the identity changes — grant it again here and you should not have to think about it afterwards.
Two honest notes. This does not remove the warning macOS shows the first time you open Xenon: that needs Apple's paid notarization, which this project still does not have. And the certificate is Xenon's own rather than Apple-issued, which is exactly why it is free and why it is enough for this particular problem.
Fixed
No more storm of permission requests. With that permission lapsed, Xenon's file index kept trying to read your home folder anyway, so macOS asked for the Desktop, then Documents, then Downloads, then Photos, then Music — and asked again on the next pass, and the next. It made the machine genuinely hard to use, and nothing on screen connected it to Xenon having lost a permission after an update.
Xenon now checks whether the permission is really in force, and while it is not it stays out of your home folder rather than knocking on every protected door in it. Instead you get one notice that says what happened, with a button that opens the right settings pane — it is four levels deep and named differently on each macOS version. A folder you picked yourself is still indexed: you chose that one. When you grant the permission, search and the disk map come back on their own within a minute, with nothing to restart.
Installing Xenon from the .dmg now finishes. The setup window found the release, downloaded it, verified its signature, and then stopped on the line right before it copied anything, with INSTALL_ROOT: unbound variable. macOS still ships bash 3.2, from 2007, and that version reads the bytes of the ellipsis glued to the end of a variable name as part of the name — so a message meant to say "Installing to <folder>…" asked for a variable that does not exist. Every other shell handles it, which is why it only ever happened on a Mac. The same line was in the uninstaller, where it quit before removing anything: if you ran it and Xenon was still there afterwards, that is why.
And the install now ends with the dashboard on screen. Even once it ran to the end, nothing started the dashboard: the piece that starts it is Xenon itself, and Xenon was already open — it is what opened the setup window. It looks for a dashboard once, at launch, and at that moment there was nothing installed yet to find. The installer now reopens the app itself once the install is done.
Buttons on notifications did nothing. Any notification offering a choice swallowed the tap: the card's swipe-to-dismiss gesture captured it before the button saw it. Worse on the update notice, where the tap fell through to the card's own action, so declining a version installed it instead.
The full changelog is in CHANGELOG.md.