LockIME: a macOS menu-bar app that re-applies your input source the moment it drifts

What LockIME actually fixes for bilingual Mac users

If you type in more than one language, macOS makes you pay a small tax all day. You set the input source to English, click into a chat window that remembers Japanese, and the next thing you type comes out wrong. The README frames the problem in one line: whenever you or another app switch input methods, LockIME switches back to the locked one. That is the whole product. It is a menu-bar app, not a system extension, and the README states that core locking needs no system permissions. The optional enhanced mode, which adds per-URL and focused-field rules, is gated behind Accessibility. The intended user is someone who already knows which input source they want in which context and is tired of re-asserting it. It is not a tool for someone who wants per-window language memory with no configuration; the rules are the point.

Continuous re-lock versus one-time switch, and why the distinction matters

The README's comparison table puts LockIME against Input Source Pro and KeyboardHolder, and the row that separates them is continuous re-lock: LockIME has it, the other two do not. The mechanism follows from that. LockIME watches for input source changes and immediately switches back to the locked source, rather than switching once when you focus a new app and then leaving you alone. Every rule can still choose between the two behaviours. A per-app or per-URL rule can lock an input source, meaning it is re-applied whenever it drifts, or switch to it once on focus and then step out of the way. The global default has three modes: lock to pin it everywhere, switch to move you into it once whenever an app falls back to the default, or None for no global behaviour at all, in which case only your per-app and per-URL rules act. That three-way choice is the part most people will get wrong on first install, because None and switch sound similar until you watch the activation log.

Conflict detection is the honest part of the design

A lock that re-applies on every drift has an obvious failure mode: an app that also re-asserts its own input source. The README addresses this directly. If another program keeps re-asserting its input source, LockIME notices the tug-of-war and briefly stands down instead of flip-flopping forever, recording Conflict detected in the activation log. The documented remedy is to give that app its own Ignore or Switch to rule. This is a real limitation dressed as a feature, and it is worth reading that way. LockIME does not win against a game with built-in IME management; it declines to play. Also note the bare-process rules: programs launched from a bare executable rather than an .app bundle, such as Minecraft's java spawned by a third-party launcher, appear in the app picker under a synthetic process:<executable> identity, for example process:java. That is a workaround for how macOS identifies processes, and it means the name you pick from the list may not match what you see in the Dock.

Installing LockIME with Homebrew and setting a first rule

The README gives two install paths. The cask picks the build matching your Mac's architecture, which matters because the project ships separate arm64 and x86_64 apps rather than a universal binary. The Makefile confirms the reasoning in a comment: one app per architecture, for download size. Run the cask command:

brew install --cask oomol-lab/tap/lockime

Alternatively, download the .dmg matching your Mac from the latest release, using the -arm64 file for Apple silicon and -x86_64 for Intel. Either way the app keeps itself up to date via Sparkle, and the README notes stable and beta channels. After launching from the menu bar, the first useful thing to set is the global behaviour, then a single per-app rule. The README's three global options are lock, switch and None, and per-app rules add Ignore and Switch to. Start with one app you switch into constantly and give it a lock rule, then open the 24-hour activation log and check what was switched, why, and for how long. If you see Conflict detected against that app, change the rule to Ignore or Switch to rather than leaving the lock in place.

Per-URL rules, the Accessibility gate, and what enhanced mode costs you

Per-URL rules are the feature that distinguishes LockIME from a plain per-app switcher, and they sit behind the optional enhanced mode. The README states that enhanced mode is Accessibility-gated and unlocks finer-grained per-URL and focused-field rules, while core locking needs no system permissions. That trade is worth stating plainly: if you never grant Accessibility, you get global and per-app locking and nothing URL-based. If you do grant it, you get four match types. A rule can match a domain and its subdomains, an exact domain, a domain keyword, or a regular expression over the full URL. They apply in a priority order you drag to arrange, first match wins. The README also lists an address-bar rule for the URL field itself, with lock, switch and priority. Four match types plus drag ordering is enough rope to hang yourself: a keyword rule placed above a regex rule will shadow it, and nothing in the README describes a warning for that. The activation log is the only feedback loop mentioned.

Where LockIME is the wrong tool

LockIME is macOS 14 and later only. The comparison table lists macOS 11 as the minimum for Input Source Pro and 10.15 for KeyboardHolder, so on an older Mac LockIME is not a candidate at all. It is also the wrong tool if you want a one-shot switch and nothing more. Continuous re-lock is the design centre, and while every rule can fall back to switch, you are paying for a watcher you would then be configuring to stay quiet. The third case is an app you cannot rule around. The README's answer to a persistent tug-of-war is to stand down and log it, so if the offending program is one you cannot add an Ignore rule for, LockIME will record conflicts rather than solve them. Finally, this is a menu-bar app with no CLI documented in the README beyond the lockime:// URL scheme, so scripted, headless or server-side use is out of scope.

How LockIME differs from Input Source Pro and KeyboardHolder

The README names Input Source Pro and KeyboardHolder as the two most widely used alternatives. All three are free, all three do per-app and per-website rules. The difference is in behaviour and in matching. Input Source Pro and KeyboardHolder switch the input source as you move between apps or sites; LockIME re-applies a lock the moment it drifts. On URL matching, LockIME supports subdomain, exact, keyword and regex, Input Source Pro supports subdomain, exact and regex, and KeyboardHolder uses a domain wildcard. LockIME and Input Source Pro are both GPL-3.0; KeyboardHolder is closed source. KeyboardHolder supports macOS 10.15 and Input Source Pro macOS 11, both below LockIME's macOS 14 floor. The README also states that LockIME has global keyboard shortcuts and that KeyboardHolder does not. The honest summary is that the three overlap heavily and the deciding factor is whether you want a lock that keeps re-asserting itself or a switch that fires once per focus change.

Licence, maintenance and upgrade cost

LockIME is GPL-3.0. If you only install and use the app, that is the end of it. If you fork it or ship a modified build, the GPL-3.0 obligations attach to what you distribute, and that is a question for your own counsel rather than for this article. On maintenance, the repository is not archived and the last push was on 2026-09-02, which is recent enough to call the project current. The release history shows v1.7.0 on 2026-08-20 followed by two betas, v1.7.1-beta.1 on 2026-08-28 and v1.7.1-beta.2 on 2026-09-02, so the stable channel and the beta channel are moving at different speeds. Upgrade cost is low by design: Sparkle handles updates, and the README describes a config backup feature that exports per-app and per-URL rules to a .lockime file and imports them back with a review step that previews additions, conflicts and removals before anything is applied. That review step is the part to use before any major version jump, because it is the only documented way to see what an import would change before it changes it.

Editorial conclusion

Adopt LockIME if you work on macOS 14 or later with two or more input sources and you are tired of re-selecting the same one after every app switch, and if you accept that a continuous lock is the opposite of a one-shot switch. Skip it if you are on macOS 13 or older, or if the app that keeps stealing your input source is one you cannot give an Ignore rule, because LockIME's documented answer to a tug-of-war is to stand down and log Conflict detected rather than win. Before trusting it with a daily workflow, install the cask, open the activation log, and confirm that a normal app switch produces the switch reason you expect rather than a conflict entry.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. oomol-lab/LockIME on GitHub
4. README
5. Releases