[grub-basket]

What happens

With a hardware keyboard on the iPad, Shift+Return in a text box on the Mac acts as a plain Return. In Claude's desktop app that sends the message instead of starting a new line. Shift+Tab moves focus forward instead of back. The key row's latched shift followed by the software keyboard's return or tab does the same.

Why

ForwardedKeys.goesAsKey (iOSClient/KeyChords.swift) sends a key to the Mac as a key only if it's one of keyUsages, or if ⌘, ⌃ or ⌥ is held. Everything else, shift included, goes through the text system and arrives as insertText. For Return and Tab, the text system hands over "\n" and "\t" without the shift. The host then types those as a plain Return (virtual key 36) and Tab with the modifier flags cleared.

The change

• ForwardedKeys.shiftedKeyUsages (return 0x28, tab 0x2B): with shift held, these go as keys, carrying shift, like a hardware keyboard on the Mac. Alone, or with caps lock only, they still go through the text system, so an IME's Return still confirms its composition.
• InputOverlay.insertText: the key row's latched shift followed by the software keyboard's return or tab now sends Shift+Return or Shift+Tab as a key chord (sendLatched), not as text.
• The host needs no change: KeyStrokes already maps 0x28 to Return and posts a key's down with the device's modifiers.

Tests

• Tests/checks/key-strokes:
  • The check that said shifted return and tab go to the text system now says they go as keys, and not without shift.
  • New checks: ⇧Return's down carries shift, and its up follows.
  • 333 checks, all pass. 2 new mutants, 74 of 74 caught. README row updated.
• On a loopback synthetic host with SILL_TEST_INPUT_LOG=1:
  • The kind 8 this now sends (key 0x28, modifiers shift) posts key 36 down (shift).
  • The old path (text "\n") posts key 36 down (none).
• The iOS app compiles with this change. The Mac it was built on has only Xcode 27.0, so the build was done in a scratch copy with DuoPostureReader's iOS 27.1 calls stubbed out.
• Not tested on a device.

🤖 Generated with Claude Code

[grub-basket]

Merged main in (2b4b279), with no rebase. #80 didn't touch this path: goesAsKey still sent shifted Return and Tab to the text system, so the fix still applies. The only conflicts were Tests/checks/key-strokes/mutants.py (both blocks kept) and the README row, now 351 checks and 83 of 83 mutants. run-all.sh passes, and the iOS app builds.

[Saffsanity]

From a pass over all the open pull requests (nothing is decided yet): #147 (Chinese input and dictation through UITextInput) rewrites the end of InputOverlayView.insertText, where this PR adds the latched-shift Return and Tab branch, so whichever lands second keeps both, with that branch behind !composition.isComposing so that ⇧Return stays with an input method while it composes. The key-strokes row of Tests/checks/README.md also changes in #66 (and #72 and #73, built on it), so the second to land just updates the counts.

[Saffsanity]

Thanks for the fix. On main, ⇧Return and ⇧Tab from a hardware keyboard, and the on-screen keyboard's return and tab with the key row's shift latched, reach the Mac without the shift; this branch fixes both.

Two commits were added on top of the branch:

• 3696fee merges main (fix(checks): quote shell variables in build.sh to handle paths with spaces #153 and fix: preserve saved remote destinations #142 had landed since; no conflicts).
• 921d698 brings the comments, the check and the docs in line with the change (no app code changes):
  • InputOverlay.swift: the comments on the latched-modifier rule, the latched-shift branch and the two keyboard paths still said a shift latch always sends plain text and that the text path owns return and tab. They now describe the new rule: return and tab with shift go out as ⇧Return and ⇧Tab keys, and the latched-shift branch takes any return or tab the text system delivers.
  • KeyChords.swift: the header mentions a latched shift's return and tab.
  • Tests/checks/key-strokes: ⇧Return and ⇧Tab are pressed through the check's hardware-keyboard model, as pressesBegan sees them. The check confirms the down carries shift, the up carries nothing, and neither the current Mac model nor the pre-2026-09-27 one is left holding a modifier. Return and Tab also joined the random device sessions' hardware keys. 353 checks pass and all 83 mutants are caught, including the two this PR added.
  • Tests/checks/README.md (the key-strokes row) and docs/DEVELOPMENT.md (the hardware keyboard section) describe the change.

Verified locally on 921d698: the key-strokes check and its mutants, swift build -c release, and the iOS simulator build as CI runs it, each with only the existing warnings. It merges once CI passes on this head.

[Saffsanity]

Thank you @grub-basket, your fix is in Sill for iPhone and iPad 0.5.5 (5) on TestFlight: Shift+Return and Shift+Tab reach the Mac with the shift, from a hardware keyboard and from the key row's latched shift with the on-screen keyboard. It works with the Mac app people have now (0.5.1). Please tell me here if anything about it behaves differently in the build!

The newest Sill for Mac is the nightly build on GitHub: https://github.com/Saffsanity/sill/releases/tag/nightly. This change works with Sill for Mac 0.5.1 as well.