Advanced iOS Automation Scripts: Shortcuts and Full Keyboard Access in Action

1. Turning the iPhone into a “Programmable Device”

Hidden inside the iPhone’s accessibility features is an underestimated capability: Full Keyboard Access. It lets an external keyboard (or a simulated one) execute system commands via shortcuts — opening Notification Center, switching apps, triggering Shortcuts. Combined with EasyClick’s keyboard shortcut feature, scripts can “press keys” to drive these system capabilities directly.

This combination is the advanced play for iOS automation: hardware solutions (Bluetooth/OTG HID) handle taps and swipes, keyboard shortcuts handle system commands, and Shortcuts handle complex actions. Put the three together and the iPhone becomes a programmable device.

Why “key-driven” is worth learning on its own

Compared with calling system interfaces directly, the shortcut-key path has several practical values:

1. Works without proxy: Full Keyboard Access and Shortcuts are both native system capabilities — paired with Bluetooth/OTG HID they work without a proxy program.
2. Can drive “outside-the-app” actions: opening Notification Center, Control Center and other system-level operations are hard to do directly through script interfaces; the shortcut key is a ready-made channel.
3. Shortcuts are “action packs”: one Shortcut can encapsulate multiple steps (fetch content → process → write), and the script only needs to trigger it once — the complexity is contained inside the Shortcut.
4. Shareable and reusable: configured Shortcuts can be shared with other devices, one config reused across many.

Who this path is for

It suits practitioners who have basic automation working and want to add system-level operations and complex actions; it also suits proxy-free scenarios (no proxy program) that need text input or photo-library downloads. It does not replace proxy mode — it fills in the corners proxy mode doesn’t cover.

2. Principles and Dependencies

Element	Description
Full Keyboard Access	Native iOS accessibility feature (Settings → Accessibility → Keyboards & Typing), no jailbreak required
Keyboard shortcuts	“Add Keyboard Shortcut” in the central control, binding combos to system commands / Shortcuts
Script invocation	bleEvent.keyPressChar (Bluetooth) / otgEvent.keyPressChar (OTG)
Trigger carrier	Bluetooth HID / OTG HID hardware solutions

How Full Keyboard Access works

Full Keyboard Access maps “keyboard key presses” to “system actions”: you press a combo, and the system executes the corresponding command. This mapping table is device-local, configured under “Full Keyboard Access → Commands.” EasyClick’s keyboard-shortcut feature essentially makes the hardware solution (Bluetooth/OTG HID) simulate pressing the same combo, thereby triggering the command already configured locally on the device.

The key point is that the mapping on both sides must match:

Device side: Full Keyboard Access → Commands → combo X → command A
Central-control side: Add Keyboard Shortcut → combo X → send
Script: keyPressChar(combo X) → device executes command A

If the combo is inconsistent on either side, the pipeline breaks. This is also the most error-prone spot in configuration — the device side and the central-control side are each configured once, and must be verified character by character.

What you need

• An iPhone (system accessibility, no jailbreak required);
• A Bluetooth HID or OTG HID hardware solution (as the simulated-keyboard carrier);
• EasyClick central control (for adding keyboard shortcuts and dispatching scripts);
• The target Shortcut already created in the phone’s Shortcuts app.

Why the central-control side needs configuring too

The device-side “Full Keyboard Access → Commands” controls “what happens when the combo is pressed locally on the device”; the central-control-side “Add Keyboard Shortcut” controls “what combo the hardware simulates sending when the script calls keyPressChar.” The two are two halves of the same event:

• Missing the device-side config: the combo is pressed, but the system doesn’t know what to do;
• Missing the central-control-side config: the script calls keyPressChar, but the hardware doesn’t know which combo to send.

So every shortcut binding requires both-side configuration. We recommend maintaining a “shortcut mapping table” ledger, with four columns: device-side combo, central-control-side combo, corresponding command/Shortcut, and script call name. When devices and scripts multiply, this is the only thing you can look up to stay sane.

3. Practice Case 1: Opening Notification Center with a Shortcut

1. On the phone, go to Settings → Accessibility → Keyboards & Typing → Full Keyboard Access → Commands, find Notification Center, and tap it — a “Keyboard Shortcut” dialog appears;
2. Right-click in the central control → Bluetooth BLE Settings → Add Keyboard Shortcut: pick gui as the modifier, enter b as the character, and click Send;
3. In the phone’s “Keyboard Shortcut” dialog, the shortcut has changed — tap Done;
4. Enter the Add Shortcut page again, type the same combo (gui+b), and send — the phone switches to Notification Center;
5. In scripts, trigger the same effect with bleEvent.keyPressChar.

Other system commands and Shortcuts follow the same binding process.

What this case teaches

Case 1 is simple, but it walks through the most critical verification of the whole pipeline: device-side command → central-control shortcut → script trigger. Getting it running confirms that the hardware solution can correctly send the combo and the device side responds correctly — every more complex scenario afterward is just stacking on top of this pipeline.

Two details to watch in practice: first, after the device-side dialog pops up, check on the phone whether the current combo is already taken; second, after the central control sends the combo, wait for the device-side dialog to confirm the change before tapping “Done” — getting the order wrong means the mapping won’t take effect.

4. Practice Case 2: Automating Text Input with Shortcuts

This is one of the three-level text input solutions for iOS automation (see the text input article for details). The core chain:

Phone Shortcut: request the computer-side API → content written to clipboard → paste
↓
Full Keyboard Access → Commands: find the Shortcut → bind a keyboard shortcut
↓
Central control: add the same shortcut (e.g., gui+u)
↓
Script: trigger → Shortcut executes → text lands in the input field

Key points: add a “device vibration” action in the Shortcut so data can still be fetched in the background; finally call back the suc API to notify the program of completion. Once configured, the Shortcut can be shared with other phones for reuse.

Why text input goes through Shortcuts

In proxy-free scenarios there is no inputText system-level input interface, so the most common way to get text into an input field is “clipboard + paste.” But where does the clipboard content come from? The Shortcut plays the “fetch content” role — through the computer-side API it passes the text to be input to the device, writes it to the clipboard, and then triggers paste. Three steps in one, and the script side only triggers one shortcut key.

Horizontal comparison of the three input approaches

Approach	Dependency	Characteristics	Best for
inputText	Proxy mode	System-level direct input, fast	Proxy scenarios, system-level input needed
imeApi input method	Offline main program	Proxy-free input, needs input-method config	Offline / proxy-free scenarios
Shortcuts clipboard	Shortcuts + shortcut keys	Proxy-free, simple chain, shareable and reusable	Proxy-free scenarios, combined actions

Selection logic: with proxy, prefer inputText; proxy-free and high-frequency input, use imeApi; low-frequency or needing extra processing (download, fetch data), use Shortcuts. The three are complementary — mix and match by business.

Stability design

• Add vibration for confirmation: after the Shortcut runs “device vibration,” the script side can confirm completion via a sensor or log, instead of waiting blindly;
• suc callback: the Shortcut finally calls back the suc API to notify the program of completion, and the script proceeds based on the callback, avoiding timing skew;
• Leave a wait window: after triggering, leave a 0.5–2 second execution window before moving to the next action, to prevent starting the next action before the Shortcut has finished.

5. Practice Case 3: Downloading Videos to the Photo Library with Shortcuts

Without a proxy IPA, use a Shortcut to download videos:

1. Create a new Shortcut that calls “Get Contents of URL” twice — the first call fetches the real resource URL, the second fetches the resource content;
2. Bind a keyboard shortcut (gui+i in this example);
3. After the script triggers it, the video automatically lands in the photo library.

Principle: the first “Get Contents of URL” handles redirects/short links and fetches the real resource URL; the second uses the real URL to pull the video data and save it. Both steps are encapsulated in the Shortcut, and the script only presses gui+i.

Applicable boundary: this approach suits download scenarios with a direct link or a parseable redirect. Resources that need a login state or encrypted signatures are beyond what a Shortcut can handle — fall back to proxy mode or a dedicated script. The decision criterion is simple: first run the Shortcut manually on the phone; only bind the shortcut key if the manual run succeeds. Don’t expect to script something that can’t even be done manually.

The debugging rhythm for Shortcuts

Most Shortcut pitfalls are “runs manually, won’t run from script.” Debug in three steps:

1. Manual verification: run the Shortcut once manually in the Shortcuts app to confirm the action itself is fine;
2. Semi-auto verification: manually press the combo on the phone once to confirm the shortcut-key trigger chain works;
3. Full-auto verification: trigger from the script and confirm the result with a screenshot, making “trigger → wait → confirm” an observable loop.

Verify each step independently — fix whichever step breaks, and avoid mixing “action problems” with “pipeline problems” in the same troubleshooting pass.

6. Common Issues and Troubleshooting

Symptom	Cause	Fix
Pressing the shortcut does nothing	Device-side command not configured, or combo mismatch	Verify the device-side and central-control-side combos match character by character
Combo taken by the system	Conflicts with an existing system shortcut	Switch to a business-specific combo; avoid common system keys
Shortcut doesn’t execute	That Shortcut isn’t bound in the command list	Find the Shortcut under “Full Keyboard Access → Commands” and bind it
Text doesn’t land in the input field	Clipboard write failed or paste timing is off	Confirm the Shortcut can fetch data; make sure the input field is focused before triggering
Download fails	Resource needs a login state or isn’t a direct link	Manually verify the Shortcut’s feasibility; if it doesn’t work, switch approaches

Handling combo conflicts

Full Keyboard Access reserves quite a few combos (like gui+h for Home, gui+space for Search). Before defining a custom combo, we recommend:

1. Browse the device-side “Commands” list for already-occupied combos;
2. Avoid common system actions and pick a letter with clear business meaning;
3. On conflict, prefer changing the letter over changing the modifier — gui (Command) + a letter is the most stable combo; shift/ctrl combos have special meanings inside some apps.

Script invocation summary

Scenario	Invocation
Trigger a shortcut via Bluetooth	bleEvent.keyPressChar(modifier, character)
Trigger a shortcut via OTG	otgEvent.keyPressChar(modifier, character)
Combine multiple actions	Call multiple keyPressChar in sequence
Pair with text input	Trigger the clipboard-paste Shortcut

Multi-device rollout pointers

When promoting from a single configured device to many, note three things: first, Shortcuts can be batch-pushed via the share feature, but each device’s “Full Keyboard Access → Commands” binding still needs to be confirmed on the device side; second, the shortcut mapping-table ledger is your troubleshooting basis once devices multiply — keep it in sync; third, for a new iOS version, verify the binding flow on one test device first before deciding on a full upgrade.

7. FAQ

Understand the overall framework before diving in: this play = native system capability (Full Keyboard Access / Shortcuts) + hardware solution (Bluetooth/OTG HID) + central-control script trigger — only with all three pieces do you get a “programmable device.” Common questions below.

Q1: What is Full Keyboard Access? A: A native system accessibility feature that executes system commands and Shortcuts via shortcut keys — no jailbreak needed, and EasyClick can bind it to scripts.

Q2: How do I make a Shortcut triggerable by automation? A: Bind a shortcut in Full Keyboard Access → Commands → add the same combo in the central control → trigger from the script with keyPressChar.

Q3: What can keyboard shortcuts trigger? A: System commands, Shortcuts, and custom actions — commonly gui + a letter combos.

Q4: Is jailbreaking required? A: No — a native accessibility feature plus a hardware solution is enough.

Q5: Typical scenarios? A: Clipboard input, photo-library downloads, opening apps, system actions — combinable into complex flows.

Q6: What if a combo conflicts? A: Avoid common system combos; switch to a business-specific letter. Confirm on the device before binding that it isn’t taken.

Q7: How long does a Shortcut take? Can it retry on failure? A: Usually a fraction of a second to a few seconds; on the script side leave enough wait time, and confirm the result with vibration/suc callback/screenshot — retry or fall back on failure.

Q8: Is it compatible across iOS versions? A: The core mechanism is consistent; the entry point and command list may differ slightly. After a system upgrade, verify the bindings once on a test device.

Q9: How do Shortcuts and inputText work together? A: Use inputText for system-level input in proxy mode; in proxy-free scenarios use the Shortcuts clipboard-paste approach. Mix and match by scenario — they’re complementary.

---

About EasyClick: A phone automation AI-agent platform covering Android no-root, iOS no-jailbreak (proxy / Bluetooth HID / OTG HID) and HarmonyOS Next, offering script development, Apple cluster control, local central control & mirroring, and cloud control systems. → Explore all products

---