FaceGate-Mac is an application locker for macOS that promises to block access to specific apps until the user authenticates with their face, Touch ID, or a password. My short verdict: the idea is solid, the code shows a genuinely coherent local architecture, but I wouldn’t recommend it to everyone yet without testing on a dedicated Mac. It’s a young system-level app, non-notarized, with sensitive privileges.
What is FaceGate-Mac?
FaceGate-Mac addresses a pretty concrete gap in macOS: locking a specific app (say, Safari, Mail, Notes, Messages, or a password manager) without locking the entire session.
The announced concept is straightforward: you choose which apps to protect, FaceGate monitors their launches, hides or blocks the app, then displays an authentication window. Unlocking can happen via:
- local facial recognition,
- Touch ID,
- password or PIN,
- per-app session timer.
The interesting angle for anyone security-minded is the local-first approach. The repository includes a compiled Core ML model, a cosine similarity matching pipeline, AES GCM encrypted storage, and a key stored in the macOS Keychain. I saw no dependency on a cloud service or any LLM.
| Element | What I checked |
|---|---|
| Platform | macOS 14 listed in project.yml, install script is macOS-only |
| Language | Swift 5.9, SwiftUI, AppKit |
| Authentication | Face, Touch ID, password |
| Face storage | Local encrypted file, key in Keychain |
| Network | Sparkle for updates, no remote AI logic in the core |
| Release tested | v1.2.0 found via the GitHub API |
Installing FaceGate-Mac
I cloned the repository into /tmp, the way you’d approach a proper scout test, then read through the README, the Makefile, project.yml, the Swift files, and the install script.
The core project commands are:
git clone https://github.com/dweep-desai/FaceGate-Mac.git
cd FaceGate-Mac
brew install xcodegen
xcodegen generate
open FaceGate.xcodeproj
The README’s recommended installation method is:
curl -fsSL https://raw.githubusercontent.com/dweep-desai/FaceGate-Mac/main/install.sh | bash
I actually ran the script in my test environment. Since my runner is a Linux container, the script stops immediately at sw_vers, which only exists on macOS. No surprise there, but it matters: FaceGate-Mac is not a portable tool you can fully validate on Linux. You need a real Mac with a camera, either Xcode or the release DMG.
I also queried the GitHub release: the latest version available during my test was v1.2.0, with a FaceGate-v1.2.0.dmg weighing around 11 MB. On a Mac, the script would download that DMG, mount it with hdiutil, copy FaceGate.app into /Applications, then strip the quarantine attribute with xattr -cr.
FaceGate-Mac in Practice
I don’t have a macOS desktop in this container, so I’m not going to pretend I clicked through a menu bar or launched Safari behind a camera. What I could do to test a real use case was run the core observable logic from the code: the scenario where Safari is locked, a face appears in front of the camera, and FaceGate decides whether the app can be reopened.
The matching core lives in FaceMatcher.swift and VectorMath.swift:
- FaceGate receives a live face embedding,
- it compares it against enrolled embeddings,
- it keeps the best cosine similarity score,
- it grants access if the score exceeds the default threshold of
0.65.
I reproduced this flow with test vectors, using the real constants from the repository. Result:
FaceGate concrete test: lock Safari and compare live face vectors
Default face threshold: 0.65
Default unlock session: 300 seconds
Case A, enrolled user returns to Safari: similarity 1.000 => True
Case B, different face tries Safari: similarity 0.375 => False
Case C, no enrolled face: similarity -1.0 => False
This test doesn’t prove that the camera, Vision, Core ML, and the macOS overlay all work flawlessly together across every machine. What it does show is that the decision rule the project advertises is clear, testable, and consistent: a close match gets through, a distant one doesn’t, and no enrolled face means no access.
I also checked the app’s properties: LSUIElement is enabled, so FaceGate runs as a menu bar agent with no Dock icon. The camera usage description states that data stays on the device. The Info.plist also includes the Sparkle configuration for updates.
What I Like About FaceGate-Mac
The first strong point is the consistency of the threat model. The README explicitly states that FaceGate is a convenience layer against opportunistic physical access, not a defense against a targeted attacker using high-quality spoofing. That’s honest, and it’s exactly the right framing for an app that relies on a 2D camera.
I also appreciate the local-first choice. The embeddings are designed to be encrypted, the key goes through the Keychain, and Touch ID authentication uses Apple’s own frameworks. For a personal locking app, that’s far preferable to a SaaS service that would handle biometric data.
Another plus: the planned UX goes beyond a simple padlock. There are per-app sessions, a lock-on-sleep mode, schedules, a Touch ID or password fallback, and a liveness detection mechanism based on head movements.
The Limits of FaceGate-Mac
The first limitation is practical: FaceGate-Mac is deeply macOS-specific. Not just “designed for macOS,” but genuinely dependent on sw_vers, hdiutil, Xcode, AppKit, Vision, Core ML, LocalAuthentication, and system permissions. If you don’t have a test Mac, you can’t validate the product end to end.
Second limitation: the app is not notarized, according to the README. Installation requires stripping the Gatekeeper quarantine flag. For an open source convenience tool, that’s understandable. For a sensitive production machine, I’d be more cautious.
Third limitation: this kind of app needs to request strong permissions. On macOS, monitoring applications, displaying overlays, intercepting launches, and manipulating processes requires a high level of trust. Before adopting it, I’d want to read the code, verify the release, ideally build it myself, and then test it in a separate session.
Finally, the repository notes there are no unit or UI tests yet. For a tool that touches local authentication, that’s a gap. The code is readable, but it deserves a solid test suite covering session logic, camera failures, expirations, schedules, and cancellation paths.
Does FaceGate-Mac Actually Work?
My answer is nuanced: the logic I was able to test works, the installation is well designed for macOS, and the repository contains the expected building blocks for a real locking app. But I didn’t validate the full experience (camera plus overlay plus app launch) because my scout environment runs Linux.
So I’m not going to oversell this. FaceGate-Mac looks serious and promising, but my test primarily confirms the architecture, the release, the install script, and the decision-making core. A proper final verdict requires a physical Mac, a camera, an enrolled face, and several apps locked under normal conditions.
Should You Use FaceGate-Mac?
If you’re curious, a macOS developer, or a power user, yes, it’s worth trying on a non-critical machine. The project is open source, free, local-first, and the idea addresses a real need.
If you’re looking for enterprise-grade protection, or your Mac holds highly sensitive data, I’d say: wait, audit, build it yourself, then test carefully. FaceGate-Mac is a useful friction layer, not a replacement for disk encryption, a locked session, or an MDM policy.
My verdict: try it, but don’t adopt it blindly. I’d put it in the promising tools category for technical users, with good potential if testing, notarization, and security documentation continue to improve.
FAQ
Does FaceGate-Mac send my face to the cloud?
Based on the code and the README, no. Recognition relies on Core ML running locally, and the embeddings are stored locally and encrypted.
Does FaceGate-Mac replace macOS session locking?
No. It’s per-application protection, useful against opportunistic access when the session is already open. You should keep system locking, FileVault, and Touch ID in place.
Can you use FaceGate-Mac without Touch ID?
Yes, the project supports face-based unlocking with a password fallback. Touch ID is optional but handy when the camera struggles with poor lighting or positioning.