Practise a Foreign Keyboard Layout on a Mac Without Switching Your Input Source

You want to learn ЙЦУКЕН, or AZERTY, or Dvorak. Every answer you have found starts the same way: add the input source in System Settings, learn the shortcut that toggles it, then buy a set of stickers for your keycaps.

A typing tutor — Mochi Type is the one I make — does not need your Mac to be in the layout you are learning. It needs to know which physical key you pressed — and macOS hands every app exactly that, as a number, before any layout is consulted. The rest of this page is that mechanism, what it saves you, and where the claim stops.

What macOS actually sends when you press a key

Your Mac does not decide what letter you typed at the moment you press the key. First it notes which key it was — third one along on the home row, say — and passes that on as a number. The letter is worked out afterwards, by looking that number up in a table belonging to whichever layout is switched on.

The number is the useful part, because it never changes. It describes the key under your finger, so it is the same whether your Mac is set to English, Russian or Dvorak. Anything receiving it knows exactly which key you hit, without knowing or caring which alphabet you are in.

Every key press arrives as an event carrying a virtual key code: a small integer naming a position on the keyboard. macOS assigns it from the physical key, not from the layout. It does not change when you change input source.

Physical key (US QWERTY legend)	Key code
A	0
S	1
D	2
F	3
J	38
K	40
L	37
;	41
Space	49
Return	36
Tab	48
Delete	51

Switch to Russian and key code 0 still arrives as 0. What changes is only the character macOS derives from it, and that derivation is a table lookup against a layout file that ships with the system.

Want the same question put to macOS itself? I asked macOS 26.6 directly, through Carbon’s UCKeyTranslate, what one key code produces on several installed input sources:

key code 6  (the QWERTY Z position)
  com.apple.keylayout.US                  → z
  com.apple.keylayout.Russian             → я
  com.apple.keylayout.Bulgarian-Phonetic  → з
  com.apple.keylayout.Greek               → ζ
  com.apple.keylayout.Dvorak              → ;
  com.apple.keylayout.Turkish-Standard    → j

Those are input source identifiers, not the names in the menu, and on macOS 26.6 the two differ more than you would expect: Bulgarian-Phonetic is listed as Bulgarian – QWERTY, Turkish-Standard as Turkish F, and Ukrainian-PC simply as Ukrainian.

Same key, same number, six different letters. So a trainer has two options. It can ask macOS for the character, which forces you to switch. Or it can take the key code and do the lookup itself, against its own copy of the table for the layout you are studying. The second leaves your system exactly where it was.

What you avoid by not switching

Adding an input source is not one setting. It is a set of behaviours that arrive together, and you get all of them rather than the one you wanted.

A menu appears in your menu bar. Two keyboard shortcuts that had nothing to switch between now have two things to switch between. Your Mac offers to give Caps Lock a second job. And it offers to choose the layout for you, based on the document you are typing into.

Named exactly, as macOS labels them: the Input menu appears in the menu bar — Keyboard settings calls the switch Show Input menu in menu bar. Two shortcuts live under Input Sources in Keyboard Shortcuts: Select the previous input source on ⌃Space and Select next source in Input menu on ⌃⌥Space. Both combinations are seeded into every account’s preferences, shipped switched off, and there is nothing for them to toggle between while you have one source. Add a non-Latin source and macOS offers Use the Caps Lock key to switch to and from last used Latin input source. There is also Automatically switch to a document’s input source, which decides for you and is disorienting exactly when you are least sure what layout you are in.

None of that happens if nothing is added.

The ⌘ question, which is not the same for every layout

This is the part people discover late. Switching your system layout can move your keyboard shortcuts, and whether it does depends on the script.

Plainly: switch your Mac to Dvorak and the key you have pressed for Save for years stops being Save — on that layout it is Open. Switch to Russian instead and Save does not move at all. Neither is a bug, and nothing warns you in advance which of the two you are about to get.

Here is one key, measured across nine input sources. Tested on macOS 26.6 with UCKeyTranslate, key code 1 — the QWERTY S position:

Input source (name macOS shows)	Key code 1 types	With ⌘ held
U.S.	s	⌘S
Russian	ы	⌘S
Ukrainian	і	⌘S
Bulgarian – QWERTY	с	⌘S
Greek	σ	⌘S
Dvorak	o	⌘O
Dvorak – QWERTY ⌘	o	⌘S
Colemak	r	⌘R
Turkish F	i	⌘I

macOS tags each input source as ASCII-capable or not. Russian, Ukrainian, Bulgarian – QWERTY and Greek are not, so ⌘ falls back to a Latin command layer and ⌘S stays put. Dvorak, Colemak and Turkish F all carry the full Latin alphabet, are tagged ASCII-capable, and get no fallback — under Dvorak, ⌘ plus that key really is Open, not Save. Apple ships a fourth Dvorak input source, named Dvorak – QWERTY ⌘ in the layout list, whose only job is to hand the command layer back to QWERTY.

Practising by key code sidesteps the whole question. Your input source does not change, so ⌘ does not change: a key event carrying ⌘ is handed back to macOS rather than consumed by the session, and a ⌘-shortcut pressed mid-session behaves exactly as it does everywhere else. That is how Mochi Type runs its sessions — it claims one combination for itself, ⌘Delete, which clears the current line, and hands every other ⌘ chord straight back to macOS.

Where the tables have to come from

An app that works out the letter for itself needs a correct map of the layout you are learning. If one square of that map is wrong, you press the right key, the app tells you that you are wrong, and you have no way of telling which of you is mistaken. So the question is not whether an app can do this. It is where its maps came from.

This is what decides whether key-code emulation is trustworthy or merely plausible. A hand-typed layout table is wrong in the corners — the Option layer, the ISO extra key, the dead keys — and you find out only when a character you correctly typed is scored as an error.

Want to check a layout for yourself? macOS holds the authoritative tables. TISGetInputSourceProperty(source, kTISPropertyUnicodeKeyLayoutData) returns the UCKeyboardLayout blob for an input source; UCKeyTranslate turns a key code plus a modifier state into the string that source produces. That is the same API the two measurements above were produced with, and it is available to anybody.

Mochi Type’s 48 layout tables are read out of macOS that same way rather than typed in by hand — every layout, all 48 key codes, four modifier states (plain, Shift, Option, Option+Shift), 9,216 cells in total. They are then re-checked against the live system’s own answers for every Apple input source installed, and a divergence is treated as a bug rather than a shrug.

Three honest caveats about that check. It compares the unshifted and Shift layers, not the Option layers — the extraction covers all four, the regression check covers two. Layouts whose Apple input source is not installed on the test machine are skipped rather than passed, so full coverage requires enabling all of them first. And four cells are recorded as known API quirks rather than silently patched: on the Czech and Slovak layouts, UCKeyTranslate with kUCKeyTranslateNoDeadKeysBit reports key code 24 as U+0027, while the layout actually surfaces the acute dead key U+00B4. Mochi keeps U+00B4 and the test treats the pair as equivalent.

Before you buy keyboard stickers

Of the three steps everybody recommends, this is the one to skip — and not because stickers fail to do their job. It is because they do it, every single time you glance down.

Stickers answer the question “how do I find Щ” with “look at the key”. Touch typing is the practice of not looking at the key. A legend you can read is a legend you will read, every time, and the reflex takes longer to form because of it — you are paying money to slow down the thing you are trying to learn.

Want to see how little that advice has moved? Apple Discussions is where this question goes to die, and the answer to the keycap half of it has not moved in sixteen years. In thread 250025304 (16 December 2018, 7 replies), asking for a Russian typing program for a MacBook Pro, not one of the seven replies names a Mac app — the answers are a Stanford how-to, russian.typeit.org, a FluentU listicle and “search the web”. In thread 255871298 (3 December 2024, 3 replies), about using a Russian keyboard on an M4 MacBook Pro, the top-ranking reply gets the system part right — Settings → Keyboard → Input Sources — and then, for the legends, suggests a typing chart, a marker, and cutting up address labels; a second reply recommends a silicone Russian keyboard cover from Amazon. In thread 2456794, from 10 June 2010, someone asks where to buy Cyrillic stickers and the single reply is: find sticky label material, cut it to fit, write the letters on by hand.

They have a legitimate use: a machine shared with somebody who has not learned the layout, or a keyboard you use for a second script a few times a month. That is not the same purchase as learning.

During learning, the substitute is an on-screen keyboard drawn in the layout you are studying, sitting under the text. It costs nothing, it is correct for the layout rather than for the keycaps, and it goes away when you stop needing it — which a sticker does not. And nothing on your MacBook’s keycaps changes what a key does; the hardware question has its own page.

Where this stops helping

It trains the mapping, not your daily typing. The day you actually write Russian, you add the input source like everybody else. What you skip is the switching during practice, and that is a smaller claim than it sounds — but it is the difference between a habit that survives the first week and one that does not.

The layout you practise is bound to the language you practise. In Mochi Type the layout list only offers layouts whose language matches the session language, and changing language resets the layout, so there is no Dvorak-for-Russian and no cross-combination. Dvorak and Colemak exist for English only; Turkish F and Turkish Q for Turkish, under the names macOS itself shows for Turkish-Standard and Turkish-QWERTY-PC. Each of the 48 layouts can be drawn on either an ANSI or an ISO body, which is 96 selectable combinations, and no other physical shape exists — no JIS, no split, no ortholinear.

Progress is tracked per language-and-layout pair, so switching from QWERTY to Dvorak starts a fresh course track and a separate set of statistics. The curriculum itself does not change — the same stage sequence, in the same order, with your progress through it starting at zero. That is structural support for a layout switch, not a dedicated transition course: there are no side-by-side old-versus-new drills.

What Mochi Type is, and what about it is not unique

In plain terms, here is what you get. A Mac app you download and open, where you choose the language you are learning and the layout you want to learn it in, and start typing. Your Mac is not asked to change anything: no input source is added, so there is nothing new in the menu bar and nothing to switch back out of when you go and answer an email. It does not ask permission to watch your keyboard either, because it does not watch your keyboard — only the keys pressed into its own window.

None of that is exotic, and the honest thing is to say where the line falls. So: what is actually specific here?

Not the mechanism. keybr emulates layouts in the browser — its own help text for the setting says emulation “ignores the keyboard layout configured in your system and allows you to practice the selected keyboard regardless of how your system is configured” — and aTypeTrainer4Mac has offered non-system layouts on the Mac for years, Dvorak and Colemak among them, plus custom layouts built in Ukelele. “You don’t have to switch your system layout” is table stakes, and a page that presents it as a differentiator is selling.

If you do want the mechanical version: the narrower claim that survives contact with those two is a native, sandboxed macOS app whose layout tables were extracted from your own operating system’s keyboard layout files and are re-checked against the live system by its own test suite, reading only the key events delivered to its own windows — no event tap, no Accessibility permission, no Input Monitoring permission, no input source installed. That is what Mochi Type is, and it is the whole of what makes the mechanism worth trusting rather than novel.

The limit, stated once more, because it decides whether this page was any use to you: it is a typing tutor, not a system utility. It changes no macOS setting, installs no layout, and repairs nothing on your Mac — and the day you actually write Russian, you add the input source like everybody else. What it takes off your hands is the switching during practice, and nothing beyond that.

If you already know which layout you are learning, the decision that actually matters is which variant: Russian versus Russian – PC versus phonetic, the Ukrainian apostrophe and the missing Щ, Bulgarian phonetic versus what macOS calls Bulgarian – QWERTY, or Greek tonos and dialytika. Each of those is a decision you live with for years. This page is only the part that says you can start today without touching your Mac’s settings.