Input Source Pro: per-app and per-site input source switching on macOS

The problem Input Source Pro solves for multilingual macOS users

macOS remembers an input source globally, not per context. If you write English in one window and Chinese or Japanese in another, you re-select the input source yourself every time you move between them. The switch is small but it happens dozens of times a day, and it lands in the middle of typing.

Input Source Pro targets exactly that. The README describes it as "a free and open-source macOS utility designed for multilingual users who frequently switch input sources," and the two features it leads with are per-application defaults and per-website defaults inside browsers. The intended user is someone whose day is split across languages and across windows, not someone who types in one language and never touches the input menu.

It is a menu-bar-scale utility, not a platform. That narrowness is the point: the whole product is the rule engine that maps a context (frontmost app, or the site loaded in a supported browser) to an input source.

How the context-aware switching engine works

The mechanism the README describes is a mapping from context to input source. You set a default input source per application. Separately, when a browser is frontmost, you can set input sources per website. As focus moves between applications, or between sites inside a supported browser, the utility applies the matching rule and switches the active input source for you.

The browser list is explicit: Safari, Chrome, Arc, Edge, Vivaldi, Opera, Brave, Firefox, Zen, Dia, "and more." Per-site rules therefore depend on the browser being one the project can read the current URL from. That is the load-bearing detail. A per-app rule only needs to know which application is frontmost, which is a coarser signal. A per-site rule needs the URL, and the README does not document the mechanism it uses to obtain it or what happens in a browser outside the list.

Two adjacent features ride on the same app-awareness. Force English Punctuation can be enabled for specific apps so that symbols such as ` ~ - _ $ ^ , . ; ' " [ ] are typed as standard characters even when the current input source would produce localized or full-width forms; the README suggests code editors and terminals. App-based function key switching lets an app use F1 to F12 as standard function keys or as media keys, falling back to the system-wide setting when an app has no override. Neither is input-source switching in the strict sense, but both are configured per app, which tells you the project's model is "the frontmost application is the context key."

Installing Input Source Pro with Homebrew and configuring a first rule

The README gives two installation paths. Homebrew is the shorter one:

brew install --cask input-source-pro

That installs the cask, and you should end up with the app available on the system like any other cask-installed application. The alternative is a manual download from the Releases page at inputsource.pro/changelog.

There is no documented CLI and no config file. Rules are set through the app's own interface, so a "first use" is a sequence of clicks rather than a snippet. The workflow the README implies is: open the app, pick an application you switch languages in, and assign it a default input source. Repeat for the other applications you use. Then, inside a supported browser, add per-site rules for the sites where you want a different source than the browser's default.

If you would rather build it yourself, the README says to clone the repository and build with Xcode 27 or later and Swift 6.4 or later:

git clone [email protected]:runjuu/InputSourcePro.git

Open the resulting project in Xcode and build. The repository layout is a single Xcode project ("Input Source Pro.xcodeproj") with an app target, a Tests directory, and the usual community files. Note that the README does not document what macOS permissions the app requests or how to grant them; if switching does not happen after install, that is the first thing the documentation leaves you to work out.

Where Input Source Pro stops being the right tool

The hard boundary is the platform. This is a macOS utility, and nothing in the README suggests any other target. If your work spans Windows or Linux, the per-app rule model has no equivalent here.

A softer limitation is the browser dependency for per-site rules. The README lists supported browsers but does not describe a fallback for browsers outside that list, so a per-site rule is only as good as the browser's presence on the list. If your daily browser is not there, you are left with per-app rules only, which is a materially smaller feature set.

The third case is a workflow mismatch rather than a defect. If what you actually want is a single global hotkey that cycles input sources, the README does document custom shortcuts, including modifier-only shortcuts triggered by a single press or a double tap. But the product's center of gravity is context rules. Someone who wants one predictable key combination and no per-app configuration is paying for machinery they will not use. Finally, the README does not document rollback or how to undo a rule that misfires, so treat rule changes as something you verify by switching windows rather than something you can undo with a documented command.

Input Source Pro compared with KeyboardHolder and Autokbisw

The related searches around this project name two other macOS utilities, KeyboardHolder and Autokbisw, and a broader phrase, "autoswitchinput." They sit in the same problem space: remembering and restoring input sources on macOS. The difference worth knowing is scope.

Input Source Pro's distinguishing claim is the per-website layer. Per-app switching is the baseline that any tool in this space has to offer; assigning an input source to a site inside a browser, and switching as you move between sites, is the step beyond it. That is also why the supported-browser list matters so much here: it is the boundary of the feature that separates this project from a plain per-app switcher.

This is not a claim that the alternatives are worse. A tool that only does per-app switching is simpler to reason about, and if your language split follows applications rather than websites, it covers you. The honest framing is that Input Source Pro is the one to look at when your language boundary runs through the browser, and possibly more than you need when it does not. The README does not offer a comparison table against either project, so anyone deciding between them should line up the browser support and the shortcut model themselves.

Maintenance, releases, and what GPL-3.0 means for a macOS app

The repository is not archived, and the last push was on 2026-09-16. Releases are frequent enough to suggest the project is being worked on: 2.12.0 on 2026-09-15, 2.11.0 on 2026-06-21, and 2.10.0 on 2026-05-13. The gap between 2.10.0 and 2.11.0 is roughly five weeks, and the gap between 2.11.0 and 2.12.0 is roughly twelve weeks. Those are the numbers; the README does not publish a support policy or a compatibility matrix for macOS versions, so upgrade cost is mostly the cost of reinstalling a cask and re-checking that your rules survived.

On licensing: the project is GPL-3.0. For an end user running the app, that is the ordinary situation of using GPL software. The implication that matters is for anyone who wants to take the source and ship a modified build: the GPL-3.0 terms attach to distribution, and the README points to the LICENSE file rather than summarizing them. The README also states that contributions are welcome and points to CONTRIBUTING.md for setup and code guidelines, which is where a would-be contributor should look before opening a pull request. This is a description of what the repository says, not legal advice; read the LICENSE text itself if distribution is your plan.

Editorial conclusion

Adopt Input Source Pro if you type in more than one language on macOS and lose time re-selecting an input source after every app or tab switch; the per-app and per-site rules plus the Force English Punctuation option are the parts worth the install. Skip it if you work across Windows or Linux, or if you want a single global hotkey rather than context rules. Before relying on it, verify that your browsers are on the supported list, that the app has the macOS permissions it needs to observe the frontmost application, and that the GPL-3.0 terms fit how you intend to redistribute anything you build from the source.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. runjuu/InputSourcePro on GitHub