Cherri compiles runnable Apple Shortcuts, with signing support

The output is a Shortcut, so the ceiling is Apple's action list

Cherri is a compiler whose target is the Apple Shortcuts app. A program written in Cherri compiles directly to a valid runnable Shortcut, which is the shortest useful description of what it is and also the source of its limits.

The stated primary goal is to make it practical to create large Shortcut projects and maintain them long term, within the limitations of Shortcuts themselves. That parenthetical is the important clause. The compiler is not a general-purpose language implementation that happens to have a Shortcuts backend; it is a text front end for Apple Shortcuts, within the limitations of Shortcuts.

What follows from that is a specific design choice worth naming: the mapping is intended to be one to one where possible, so debugging stays tractable. A line in a Cherri program corresponds to an action in the resulting Shortcut rather than to several layers of abstraction. The feature list also acknowledges where the mapping cannot be clean, by offering Raw Actions for entering an action identifier and its parameters manually. That escape hatch is a tell: when the language does not cover something, you drop to the underlying identifiers.

Two other consequences follow from the target. First, you need Shortcuts, which means Apple platforms, so the platform badge is macOS. Second, the output is a data file. Importing an existing Shortcut from an iCloud link is possible with `--import=`, and decompilation of an existing Shortcut back into source is part of the compiler, which is the direction that makes migration less frightening than it sounds.

The repository reflects the feature set in its file names: `action.go`, `actions/`, `automations.go`, `decompile.go`, `import.go`, `shortcut.go`, `signing.go`, `token.go` and `variables.go` sit beside the parser and standard library files.

Installing the compiler on macOS with Homebrew or Nix

The compiler is a Go program, which makes installation ordinary. The README offers three routes: download a release, Homebrew, or Nix.

With Homebrew, the tap comes first:

brew tap electrikmilk/cherri
brew install electrikmilk/cherri/cherri

With Nix:

nix profile install github:electrikmilk/cherri

The Nix route also supports a per-directory development environment through `nix-direnv`, where Cherri is available based on which directory you are in. The `flake.nix` names the input and puts the package into `buildInputs`, with `use_flake` and then `direnv allow` in the directory holding the file.

Compiling a file is one argument:

cherri file.cherri

Run `cherri` with no arguments and it prints its options. For development there is `--debug` or `-d`, which prints stack traces, debug information and writes out a `.plist` file. That last part is the feature to know about early: when something compiles into the wrong thing, the generated plist is where the discrepancy is visible, and reading it is far faster than guessing from the Shortcuts UI.

The module declares Go 1.24.0 and pulls in a small set of direct dependencies that each say something about the implementation. `howett.net/plist` handles the plist output format that Shortcuts uses. `glebarez/go-sqlite` provides the package manager's storage. `go-git/go-git/v5` is there for the remote Git repositories the package manager is built on, and `google/uuid` plus a Go args parser handle identifiers and the command line.

A package manager over Git, and includes for large projects

Two features are aimed squarely at the long-term maintenance goal rather than at hello world.

The first is the package manager: remote Git repository based, built in, and it handles automatic inclusion and updates. A Cherry project can depend on a repository someone else maintains and get updates without copying files around. The go-sqlite dependency implies a local cache or index, which is what makes remote dependencies resolve quickly and consistently.

The second is the include mechanism, which lets one file be included within another. For a large Shortcut, that is the difference between one enormous source file and a directory of related ones, and the difference between a change you can review and a change you cannot.

Around those sit the ordinary necessities of a real language. There is a type system with type inference. You can define actions with type checking, enums, optionals, default values, raw identifiers and raw keys. You can define functions that run within their own scope at the top of the resulting Shortcut, which is described as a way to reduce duplicate actions in the output. Files can be embedded in base64. VCards can be generated for menus. Import questions can be defined, which is how a Shortcut asks for input at runtime.

Two features deserve suspicion rather than praise. Raw Actions and raw keys both exist to let you bypass the language's modelling and address Shortcuts actions directly, which is necessary for anything the language has not caught up with and is exactly where you lose compile-time checking. And the optimisation claim, that Cherri aims to produce the smallest possible Shortcut and reduce memory usage at runtime, is worth testing on your own project rather than taking on faith, because the one-to-one action mapping and the size optimisation pull in opposite directions.

Magic variables are explicitly not a thing: the README notes they are constants instead, which is a small readability decision that pays off in a language whose output you will sometimes have to read by hand.

Signing is the step that decides where you can run it

Cherri supports signing compiled Shortcuts, and signing is where the platform constraint is most visible.

Cherri signs using macOS when it can. When it cannot, it falls back on HubSign, which is a membership service on RoutineHub, or on another server running scaxyz/shortcut-signing-server. That fallback chain is worth understanding as a design statement rather than a detail: the project is macOS-first for a reason, and the author says so, noting that this stability comes from the project being on macOS rather than iOS, and that they are not aware of another Shortcuts language with macOS as its platform other than Buttermilk.

The consequence for you is concrete. If you have a Mac, signing is local and the loop is self-contained. If you do not, your Shortcut is signed by a third-party server, which means your compiled artifact passes through infrastructure you do not control. Whether that is acceptable depends entirely on what the Shortcut contains, and it is worth deciding before you build rather than after.

The playground changes the calculation for evaluation. It runs on any platform, previews the result, and exports signed Shortcuts. That makes it the right place to try Cherri at all if you do not own a Mac, and the right place to check whether the language fits before you install anything.

Signing failure is also the failure mode you are most likely to hit on a Mac, and the compiler's debug output plus the generated `.plist` are how you diagnose it. The plist is the artefact Shortcuts actually reads, so a shortcut that will not install is usually a plist problem you can see rather than a mystery.

Cherri against ScPL, Jelly and hand-built Shortcuts

The alternative landscape, as the README describes it, is thin and its framing is unusually honest. The stated reason for building Cherri in the first place is that other Shortcuts languages have been abandoned, do not work well, or no longer work, and the author does not want them to die, arguing there should be more of these languages and not fewer.

The named comparisons are ScPL, Jelly and Buttermilk. The README also credits inspiration from Go and Ruby syntax.

The comparison with hand-built Shortcuts in the app is the one that matters most in practice. Building directly in the Shortcuts UI gives you immediate feedback and no toolchain, and it remains the right choice for anything small. Where it fails is version control, review, reuse across projects, and the sheer friction of editing large structures by touch. Cherri's value is entirely in those four things, which is why its stated goal is large projects and long-term maintenance rather than replacing the app.

The credits section also documents where the format knowledge comes from: a Shortcuts file format description, the iOS Shortcuts Reference, and a community tip on reducing memory usage of repeat loops, which is where the runtime-size objective comes from.

The project is GPL-2.0, started on 5 October 2022, and its newest release is v2.3.0 from 2026-05-23 with the last push on 2026-10-14. Editor support exists as a VS Code extension and a Zed extension, with a separate macOS IDE app in its own repository. A glyph search site documents the glyphs the language exposes.

Editorial conclusion

Use Cherri if you are building a Shortcut larger than a single screen of actions, if you want it in version control as text, or if you need the package manager and include files that Apple will never ship. Do not expect it to exceed the Shortcuts app, since Cherri compiles to actions Apple defines and its own feature list is candid about importing actions from a Mac and entering raw identifiers by hand for the rest. Verify first that you have a Mac for signing, because the compiler falls back to HubSign or another signing server when macOS signing is unavailable, and that the version you install matches the Shortcuts app version on your device, then try the playground at playground.cherrilang.org before committing to a large project.

Frequently asked questions

Official sources

1. electrikmilk/cherri on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases