iPhone Keyboard Benchmark 2026

Results at a glance

No keyboard led every category. Apple had the strongest touch total and perfect auto-correction. Gboard was the only keyboard to complete every swipe correctly. Auri 4.0 supplied the expected next word in its top three suggestions for all 20 cases. SwiftKey earned the highest voice score, while Auri 4.0 recognized the most words correctly.

Why we built this benchmark

At Auri, we built Siaru as our internal keyboard SDK and made it the typing engine in Auri 4.0. We needed a repeatable way to improve it and compare it with the keyboards people already use.

Most keyboard comparisons depend on a person typing a few phrases and reporting how the keyboard felt. That is useful, but it is hard to repeat. A different tap, pause, learned word, or correction can change the result.

We wanted a test that could send the same input to every keyboard and record what the keyboard committed or showed on screen.

The benchmark interacts with the installed keyboard through a plain text field on the phone. For typing tests, it taps the keyboard one key at a time. For swipe tests, it sends a continuous finger path across the visible keys. For voice tests, it presses the keyboard's own microphone control and plays the same human speech clips.

What we tested

The touch comparison included six keyboards:

The voice comparison covered Apple, Gboard, SwiftKey, Wispr Flow, and Auri 4.0 in its default Clean mode. Auri 3.8.0 uses the same dictation system, so we did not replay the clips or add a duplicate row.

How the touch score works

The touch score has 100 possible points:

An unsupported feature scores zero. That matters for Auri 3.8.0 and Wispr Flow, which did not offer continuous swipe typing in the builds we tested. An unobservable feature is different: it remains unscored until we can measure it reliably.

Auto-correction

The correction set contains 35 common misspellings, including teh, becuase, recieve, and tommorow. It also contains 15 correctly spelled control words. The controls make sure a keyboard does not earn points by changing everything it sees.

For each case, the benchmark taps the letters, presses Space, and reads the committed word from the text field. The keyboard gets the point only when the final word matches the expected word.

Completion and next-word prediction

The completion test enters a short context and part of the next word. One example is see you tomorr, where the expected completion is tomorrow. The next-word test enters a complete phrase such as peanut butter and, where the expected suggestion is jelly.

We score the visible top three suggestions because that is what a person can choose from without opening another screen. The expected word can appear in any of those three positions.

This method rewards one known answer. A different suggestion may still be useful, natural, or even better in another context. The score measures consistency against the fixed test set and cannot capture the full quality of a keyboard's language model.

Swipe typing

The swipe set uses 20 English words. Each word receives one clean path through the key centres and one deliberately imperfect path, for 40 gestures in total. The harder paths drift toward key boundaries and start or end slightly off-centre.

The list includes easily confused pairs such as quiet and quite, trial and trail, form and from, week and weak, and team and term. Before the run, the benchmark reads the live key positions from the active keyboard and maps the same path design onto that layout.

The committed word must match the target. Suggestions that remain in the strip do not count.

Touch results

For touch testing, the Siaru SDK that powers Auri 4.0 ran in a standalone benchmark keyboard. This isolates the typing engine. Voice testing used Auri 4.0 itself.

These are complete same-device scores under unchanged keyboard settings. Apple and the Auri 4.0 touch run used iOS build 24A5424a for both language and swipe. Gboard and SwiftKey ran the language set on 24A5408d and the swipe set on 24A5424a. Small score differences for Gboard and SwiftKey may reflect the iOS update as well as the keyboards themselves.

What the touch results show

Apple's lead came from perfect correction and the strongest completion result. Its swipe score was the weakest among the four swipe-capable keyboards. Apple returned tail for a noisy trail path, well for both versions of week, and ten for a noisy term path.

Auri 4.0 finished 2.1 points behind Apple. It was the only touch entry to put every expected next word in the top three. Its only swipe miss was a noisy path for weak, which became wreak.

Gboard finished half a point behind Auri 4.0 and was perfect on all 40 swipe paths. It also had strong completion and next-word results, but its 86% correction score held back the total.

SwiftKey matched Auri 4.0's 39/40 swipe result. Its only swipe miss changed term to ten. Its lower correction score, 40 out of 50, produced a wider gap in the full score.

Auri 3.8.0 and Wispr Flow corrected 49 of 50 cases. Both missed adress: Auri produced a dress, while Wispr Flow produced a-dress. Their full scores are much lower because the tested products did not supply several other scored features. Auri 3.8.0 offered limited completion but no measured next-word success or continuous swipe. Wispr Flow replaced the suggestion area with its voice controls and did not offer continuous swipe.

How the voice score works

The voice test uses ten clean human-speech clips from the CMU ARCTIC speech database. The clips contain 94 reference words spoken by two speakers. They include names, numbers, contractions, capitalization, and several kinds of punctuation.

The Mac played every clip through its built-in speakers at a fixed 50% volume. The iPhone stayed in the same USB-C-cabled position for every keyboard, but the cable carried device control rather than audio. The sound travelled through the air from the Mac speakers to the phone's microphone.

The benchmark opened each keyboard's own voice feature, played the clip, stopped recording, and captured the text committed to the same text field. No person repeated the sentences during the runs. SwiftKey and Gboard required a system swipe when their voice flows moved between apps; the benchmark waited for the correct screen before playing or reading a clip.

Voice has its own 100-point score:

Word accuracy uses word error rate, often shortened to WER. A substitution, missing word, or added word counts as an error. Lower WER is better. Punctuation does not affect WER, so the separate checks keep a transcript with perfect words but no punctuation from receiving a perfect score.

Voice results

SwiftKey had two word substitutions in 94 words and passed every name, number, and capitalization check. That balance gave it the highest score.

Auri 4.0 made one word error, the best raw recognition result. It heard Fort Churchill as Sport Churchill. Exact checks for the name and capitalization then counted the same mistake in those categories, which is why its overall score remained 0.2 points below SwiftKey.

Wispr Flow made four word errors: two substitutions, one deletion, and one insertion. One example changed chain to change. It passed every name and number check.

Apple made nine word errors. It heard At sea as Etsy, changed they to then in another clip, and ended the final sentence with in Paris instead of empiricist. Its transcripts also omitted much of the reference punctuation.

Gboard made 16 word errors. On the first clip, the expected sentence was:

There's Fort Churchill, a rifle-shot beyond the ridge, asleep.

Gboard committed only:

asleep

The voice screen had omitted the opening words before the transcript returned to the benchmark app, so we count this as a recognition failure rather than a startup or timing error.

Punctuation has legitimate style choices

The voice score follows the reference transcript literally. That makes it repeatable, but a literal punctuation match can mark good writing as wrong.

For example, the reference said:

I do not blame you for anything; remember that.

Auri 4.0 wrote:

I do not blame you for anything. Remember that.

Both versions are grammatical and preserve the meaning. Auri 4.0 also changed he joined her; and they ate to the more conventional he joined her, and they ate. Another Auri 4.0 transcript added an optional comma after Two years ago, which the current scorer did not penalize because it checks required punctuation but does not subtract points for extra marks.

We left the recorded scores unchanged. Changing only Auri 4.0 after seeing its output would make the comparison less fair, while rescoring every keyboard would create a second result set. Readers should treat small voice-score differences as ties in practical quality when they come from acceptable punctuation choices. WER measures word recognition alone. Auri 4.0 recorded the lowest rate in this run at 1.1%.

Test setup and evidence

All physical tests used the same iPhone 15 Pro, model identifier iPhone16,1, with an English (US) layout and Xcode 26.6. The keyboard settings stayed unchanged across the series. The keyboards also kept their existing personalized state. We did not clear their learned dictionaries or try to make their usage histories identical.

The Gboard, SwiftKey, Auri 3.8.0, and Wispr Flow language runs used iOS 27.0 build 24A5408d. Apple and Auri 4.0 language runs, all current swipe runs, and all voice runs used build 24A5424a.

Some early language files contain systemKeyboardSettingsAttested: false. That field means the run did not capture a formal operator confirmation at the time; it does not mean the settings were disabled or changed. The operator has since confirmed that the same settings remained in place throughout the study.

Each scored run kept a raw JSON result. Depending on the test, it also kept screenshots, the accessibility page source, the exact gesture plan, XCTest logs, and device details. The test sets have fixed digital fingerprints and case order. Validation programs recalculate the scores and reject missing cases, changed evidence, or the wrong active keyboard.

We found and fixed several observation problems while building the benchmark. Apple's first prediction crop included part of the globe-key area and clipped some suggestion text. One Gboard accessibility scan timed out after it had already captured the candidate labels. SwiftKey's first crop also clipped long labels. We recovered affected observations only from retained screenshots or XCTest records, kept the original raw files, and recorded the source hashes in the recovered results.

Auri 3.8.0's early OCR filter could hide suggestions containing spaces, although every expected answer in this corpus is one word. Wispr Flow showed a voice toolbar instead of suggestion cells, so we marked those suggestion features unsupported rather than inventing empty observations.

What this study can and cannot tell us

This study gives us a repeatable picture of these installed keyboards on one phone. A broader ranking would need more devices, users, languages, and repeated runs.

• We ran one fixed-order series, so we cannot estimate run-to-run variation.
• The keyboards used their existing learned state. A long-time user's results may differ from a fresh install or another person's history.
• Gboard and SwiftKey combine language results from build 24A5408d with swipe results from 24A5424a. Small differences could reflect that iOS update as well as the keyboard itself.
• The English corpus is small. It does not cover other languages, slang, emoji, long-form writing, or every kind of typo.
• The voice set contains ten clean clips and two speakers. It does not cover background noise, accents beyond those recordings, whispered speech, or a moving phone.
• Voice punctuation checks sometimes penalize acceptable style choices.
• A keyboard gets zero for a feature it does not offer. This measures the whole product, but it can obscure how well that product performs its narrower job.
• We did not rank speed. Automation timing includes the test runner, app switching, waits, and accessibility reads, so it is not a clean measure of keyboard latency.
• The Auri team conducted this study and develops both Auri and Siaru. We benefit when they perform well. We publish the fixed test sets, case-level observations, and file hashes, but readers should still consider this relationship when interpreting the results.

Evidence behind the benchmark

The public evidence package contains the exact test corpora, a readable cohort record, sanitized case-level results, and checksums. It removes unique device details, signing information, machine-specific paths, commands, and unscored suggestions that could reflect personalized keyboard history. It does not include our internal development tools or instructions.

Feanor Labs hosts the package in a separate public GitHub repository. The links below point to the immutable 2026-08-28 release, so later work cannot change the evidence behind these scores.

• Public evidence repository
• Immutable evidence release
• Language corpus
• Physical swipe corpus
• Voice corpus
• Detailed cohort record
• Case-level results
• File manifest and checksums