Input Source Pro: build 1166 tagged twice, and a tracked link to the author's other app

Build 1166 is tagged twice, and the beta tag came after the release tag

Three releases are on record, all published on the same evening. Two of them name the same build.

The stable 2.13.0 carries the build number 1166 in its display name. So does the third release, which is tagged with a beta prefix and carries the same 1166 in its name. The third release is a beta of the identical build.

And the ordering is inverted. The stable tag was published at 18:07:19. The beta tag for the same build was published at 18:08:30, which is seventy-one seconds later. So the beta marker for build 1166 was pushed after the final marker for build 1166.

Whatever the release script was doing, the result is a repository where two tags name one build and the one carrying the word beta is the later of the two. For a utility distributed as a signed build through a cask, that ordering matters: the sequence in which tags appear is the sequence a user's update check walks, and a beta for an already-released build appearing afterwards invites an install of something the stable channel was meant to supersede.

The third release, 2.13.1, is a different build, 1169, published nearly three hours after the pair. So within a single evening the project went 1166 stable, 1166 beta, 1169 stable.

Worth noting what the build numbers are for. Embedding a monotonically increasing build identifier in the release display name, rather than only in the tag, is good practice for a distributed Mac app, because the number is what a bug report can quote unambiguously. Here the practice is right and the tagging around it is not.

The README carries a tracked link to the author's other commercial app

Between two horizontal rules, above the features list, the README announces a second application. It is a writing tool described as a local alternative to a well-known commercial grammar checker that runs entirely offline, and the link to it carries three query parameters: the source is GitHub, the medium is readme, and the campaign is named after this project.

So this is a tracked promotional link, pointing at a different product by the same author, inside the readme of an open-source utility licensed under the GPL.

There is nothing wrong with an author selling something related to their free work, and plenty of projects do it. What is worth noting is the placement and the instrumentation. It sits above the feature list rather than at the bottom, between rules that make it a distinct block, so a reader arriving from the repository page sees a pitch for another app before they see what this one does. And the campaign parameter is the part that makes it a measurement rather than a mention: it exists so the click can be attributed.

The rest of the page is built the same way, incidentally. There is a link to the project's sponsors, a link to the website above the title, two links to the website in a table below the introduction, and a final feature section whose whole content is another link to the website. Six links in this readme point at the project's own site, and their anchor text is empty, so they render as blank space.

Which means the readme is simultaneously promotional about the author's other product and technically empty about its own.

The final feature section is an empty link to the project's own website

The features section ends with a heading that promises more, and then nothing follows it but a link with no text in it.

That pattern is not confined to one place. The same empty-anchor markup appears above the title, twice inside a table below the introduction, on the promotional link to the second app, at the end of the feature list, and on the sponsors line. Six times in a readme of about five hundred words.

The cause is mechanical rather than editorial. Each of those links is almost certainly a badge or a screenshot whose image source was written into the markup as a link wrapped around an image. When the image is stripped or fails to load, the anchor is left with no content, and a link with no content renders as nothing at all. The markdown is still valid; it is just invisible.

The result is a page whose structure promises a good deal more than it delivers. The introduction is followed by a table with two invisible entries. The last feature section is invisible. The sponsors section is an invisible line under a heading about sponsors.

For a project with 3567 stars and a release every few days, this is a rendering artefact rather than a maintenance failure, and it is likely invisible to the author too, since they would be looking at the readme with images loading. But it is the first thing a visitor sees, and it is fixable by adding alt text to the images or by dropping the links.

Force English punctuation is twelve remapped keystrokes, not a locale setting

One of the features is called app-aware punctuation modes, and the headline is a setting called Force English Punctuation that you enable for particular applications.

What it does is listed precisely, and the list is worth reading as an implementation description rather than a feature description. It automatically types the standard forms of twelve symbols, and the twelve are given: backtick, tilde, hyphen, low line, dollar, caret, comma, period, semicolon, apostrophe, double quote, and the two bracket keys. The condition is that the active input source would otherwise produce localized or full-width characters for them.

So this is key remapping. Twelve characters are intercepted and re-emitted in their ASCII form, scoped to the applications you choose. The README suggests enabling it for code editors and terminal windows, which is exactly where you would want it, and it is easy to see why: a full-width comma in a shell command is a confusing bug.

Two things it does not say. It does not say what happens on a collision, which happens whenever the two input sources agree on a character, so every comma typed in a code editor with the feature on goes through the remapping layer whether or not it needed to. And it does not say how the interception is scoped: whether it follows the frontmost application the way the input-source switching does, or whether it is a global layer with an allow list.

The feature is genuinely useful and unusually well targeted. It is also the kind of thing that has to be exactly right, because a mis-scoped remap silently corrupts typing rather than throwing.

Per-app function key behaviour is a system preference, and the app writes an override

The fourth feature group is function key switching, and it is the one that reaches furthest into the operating system without saying so.

For each application you choose whether the function keys behave as standard F1 through F12 keys or as the media keys printed on them. Standard keys are recommended for development environments and games. Media keys are recommended for ordinary use. And there is a stated fallback: when an application has no override, it uses your system-wide default.

The phrase system-wide default is the important one. On macOS, whether F1 through F12 act as function keys or as media keys is a single global preference in the keyboard settings, alongside the modifier key swap. It is not something macOS offers per application.

So the feature describes a per-application override of a setting the operating system exposes globally, and the fallback wording acknowledges that the underlying preference is global. That means the app is maintaining its own table of per-application decisions and applying them when the frontmost application changes, which is the same trigger the input-source switching uses.

It is a coherent design and it is the kind of feature that makes a utility like this worth having, since there is no built-in way to get it. But it is also the feature with the largest blast radius: the keys you press for brightness and volume in one application become function keys in another, based on a table this app owns, and the README describes it in three bullets with no note about where those decisions are stored or how to inspect them.

Which matters more than it might seem, because the function key setting also governs Escape. On a laptop with no physical Escape key, a wrong override is not a minor annoyance.

Double-tapping a modifier key switches input sources mid-word

The custom shortcuts feature offers two mechanisms. The first is ordinary: standard key combinations, the kind you would expect from any menu.

The second is a single modifier key, or a combination of modifiers, triggered either by pressing once or by double-tapping.

Press-once is already unusual, since it removes the modifier from anything you would otherwise use it with. Double-tapping is stranger still. It means an input source switch can be triggered by a gesture that is not a combination at all but a repetition, and repetition is exactly what happens when someone holds a key down too long or types a stuttered character.

For an input source utility, that is a genuine hazard rather than a theoretical one. Switch input source in the middle of composing a word in a language you are typing, and the composition is interrupted by a change of keyboard layout. Switch it while typing a command in a terminal, and the command line now contains characters from the wrong layout.

The README does not say whether the double-tap has a timing threshold, whether it must be a double-tap and not a triple, whether a press longer than some interval cancels it, or whether there is a way to disable the gesture entirely while keeping the single-press shortcut.

Compare that with the way the rest of the document is written. The punctuation feature enumerates twelve exact characters. The function key feature names both modes and explains the fallback. The browser list for per-website switching names ten browsers. This one paragraph, describing the mechanism with the most room for error in the whole app, is the one that does not specify its behaviour.

Building from source is an SSH clone with no dependency step

The building section gives one fence, and the whole of it is:

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

Then one sentence: open the project in Xcode and hit Build.

Three things are missing from that, and the first one will stop people outright.

The clone URL uses the SSH form of the GitHub remote, not HTTPS. There is no alternative given and no mention of needing an SSH key registered with the account. A contributor who has never used an SSH key to GitHub cannot get past this line, and the failure is an access-denied message from the server rather than anything that points at the cause. Every contribution instruction in the same document sends people to a pull request template, so the intent is clearly to receive contributions.

Second, there is no dependency resolution step. No package manager invocation, no resolve command, nothing. Either the project genuinely has no external dependencies, in which case that is worth saying, or it does and the readme omits the step that makes the build work.

Third, the fence contains only the clone. There is no directory change, so the sentence after it refers to a project you have not moved into.

The toolchain floor is stated, which is more than many projects do: Xcode 27 or later, and Swift 6.4 or later.

For contrast, the installation section above it is impeccable. One Homebrew cask command, and a manual route that points at the project's own releases page.

The Xcode project directory has spaces in its name and there is no package manifest

Look at the top level of the repository and two entries stand out. There is a directory for the Xcode project and a directory for the app sources, and both are named after the application with spaces in it. The project file is literally called the application name with a dot project extension.

That is what Xcode produces when you create a project and type the product name with spaces, and it is the Apple default. It is not wrong. It does mean every path in a build script, a test invocation or a documentation example has to be quoted, and that any tool assuming a conventional layout will not find the sources where it expects them.

There is no package manifest. So this is an application project rather than a library, built and shipped as a bundle rather than consumed as a package. For a utility distributed through a cask and a release page that is the correct choice, and there is nothing here to fix.

The rest of the top level is conventional for a Mac app with the addition of four capitalised directories, plus a documentation directory, an images directory and a scripts directory. There is an agents instructions file at the root, a code of conduct and a contributing guide that are both linked from the readme, which is more than most projects manage, and a licence file whose name matches what the tooling expects.

That last point is worth contrasting with the packaging metadata elsewhere in this ecosystem: the licence here is detected correctly, because the file is named the way the detector looks for and its contents match the string in the manifest.

Editorial conclusion

Install it from the cask if you switch languages often and you want per-site switching, because the per-browser coverage and the punctuation remapping are the two things no built-in setting does. Two things to know before you rely on it. The function key override reaches a preference macOS only exposes globally, and Escape is governed by it on machines without a physical Escape key, so check the override table before assuming the keys behave the same in every app. And the double-tap modifier gesture has no documented threshold, so if you find your input source switching mid-word, that is the setting to look at first. Nothing here needs the source build, which is the weakest instruction in the readme.

Frequently asked questions

Official sources

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