Should You Use Cherri for Programmatic iOS Shortcuts?

Posted by Weixiang Zhang on Apr 25, 2026 · Topic: iOS Shortcuts

Apr 25, 2026 iOS Shortcuts web

TL;DR

If you maintain 3+ iOS Shortcuts that share patterns — common API calls, error handling, auth headers — adopt Cherri. Below that threshold, the visual editor is faster. The killer feature isn’t the compiler. It’s git diff on your automation logic.

What Cherri Actually Changes

Cherri is a Go-based compiler that turns .cherri text files into signed .shortcut binaries. It maps 1-to-1 to Shortcut actions with Go/Ruby-flavored syntax, type inference, and file includes.

It does not expand what Shortcuts can do. It changes how you author, version, and deploy them. That distinction matters. Cherri is a maintainability tool, not a capability tool.

The project is healthy: 1.4k GitHub stars, 2,000+ commits, 44 releases as of early 2026. It ships a CLI compiler, a macOS IDE app, a VS Code extension, and an online playground. Actively maintained.

The Case For

Version control. .cherri files are plain text. They go in git. You get diffs, blame, branch-per-feature, and PR review for your Shortcuts. Compare this to the status quo: opaque iCloud-synced plist blobs with no history and no way to compare two versions. This alone justifies adoption at scale.

Reproducible builds. cherri file.cherri produces a deterministic signed .shortcut. No manual editing, no “I think I changed that action last week.” CI can compile and verify on every push.

Parameterized compilation. Includes and macros allow compile-time substitution:

Swap endpoint URLs between dev (http://localhost:8443) and prod (https://your-host.example.com)
Inject bearer tokens per environment
Toggle debug logging actions on/off

Modular libraries. Function scoping and file includes let you factor out common patterns — the JSON body construction, the async subscription flow, the error display logic — into reusable modules. Write the “POST to endpoint and handle response” pattern once, include it everywhere.

Type safety. Type inference catches mismatched variable types before you deploy to the phone. This eliminates a class of silent runtime failures that are painful to debug in the visual editor.

Raw action escape hatch. The #define and raw action syntax means third-party app actions (Scriptable intents, custom app intents) can be invoked without waiting for Cherri to add first-class support.

The Case Against

No OTA push. This is the single biggest friction point. There is no way to push a compiled .shortcut to an iPhone from the CLI. Every recompile requires a manual install: AirDrop, open the file, or share via iCloud link. open file.shortcut on macOS at least automates the Mac side.

Signing requires macOS. Native signing only runs on macOS. If you need Linux CI runners, you need the HubSign fallback or a signing server. Fine if your build machine is a Mac. A problem if it isn’t.

Another DSL to learn. For a solo developer, the question is whether learning Cherri pays back in reduced time wrangling the Shortcuts GUI. For 1-2 simple Shortcuts, it does not. The learning curve is a net loss.

No package manager. Planned but not shipped. File includes within a repo work fine. You just can’t consume community-maintained action libraries yet.

The Decision Framework

Situation	Verdict
1-2 simple Shortcuts, no shared logic	Skip. Use the visual editor.
3+ Shortcuts sharing patterns (e.g., all call the same API)	Adopt. Modular includes pay for themselves.
Need dev/prod endpoint switching	Adopt. Parameterized builds are the cleanest path.
Want CI-compiled Shortcuts on push	Adopt. Nothing else provides this.
Frequently iterating on Shortcut logic	Adopt. Text editor + recompile beats drag-and-drop.

The Integration Pattern

A typical Cherri project structure for an API-calling Shortcut pipeline:

shortcuts/
  common/
    api-call.cherri        # shared: POST to endpoint, handle response
    error-display.cherri   # shared: show error alert
  action-button.cherri     # trigger: Action Button
  nfc-tag.cherri           # trigger: NFC tap
  siri-query.cherri        # trigger: Siri voice

A Makefile compiles all .cherri sources, resolves includes, and signs the output. make install opens the compiled .shortcut files on macOS. A GitHub Action on the main branch compiles on a macOS runner and attaches signed artifacts to the release.

Before adopting, verify one thing: that Cherri’s network actions support Get Contents of URL with custom headers, POST method, and JSON request body. If your Shortcuts are primarily API clients, this is a hard blocker if it doesn’t work. (It does work — but verify it yourself with a test shortcut before committing to the migration.)

Developer Perspective

The real question with Cherri isn’t “does the compiler work?” It does. The real question is whether your Shortcuts workflow has enough complexity and churn to justify a build pipeline. Most people have 2-3 Shortcuts they set up once and never touch. For them, Cherri is over-engineering.

But if you’re building Shortcuts as thin clients for a backend API — multiple triggers, shared auth, environment switching, frequent iteration — the visual editor becomes the bottleneck. You can’t diff it. You can’t review it. You can’t parameterize it. You can’t reproduce it.

Cherri solves all of those problems. The distribution gap (no OTA push) is real friction, but it’s Apple’s friction, not Cherri’s. Until Apple ships a Shortcuts CLI or an install-profile-style deployment path, every programmatic Shortcuts tool will hit the same wall.

Adopt it when you feel the pain. Not before.