For years, the Apple Shortcuts app has been a monument to the "visual programming" fallacy. It handles simple, linear tasks adequately. But introduce nested logic, loops, or dynamic data structures, and the system collapses. The visual representation can become a cognitive burden rather than an aid, particularly in complex scenarios. Variables, dubbed "Magic Variables," are just implicit, untyped data flows that frequently fail when data types mismatch unexpectedly or when a block's output changes without explicit re-mapping. Debugging devolves into a nightmare of trial and error, tapping through each block. This inherent complexity is precisely what the new Cherri programming language aims to solve, offering a structured alternative to the visual programming paradigm.
The Illusion of Simplicity: Why Blocks Break Your Brain
The visual programming paradigm, while seemingly intuitive for simple tasks, quickly reveals its limitations when faced with the demands of complex automation. The Apple Shortcuts app, despite its utility, exemplifies this challenge. As tasks grow in scope, the visual representation of blocks and their connections can become an overwhelming cognitive burden. The reliance on "Magic Variables"—implicit, untyped data flows—is a frequent source of frustration, leading to unexpected data type mismatches and failures when block outputs change without explicit re-mapping. This lack of explicit control and visibility transforms debugging into a tedious process of trial and error, tapping through each individual block to trace execution paths.
Cherri Programming Language: Bridging the Gap in Apple Shortcuts
Enter Cherri, a programming language designed to address these fundamental limitations. It's a programming language that compiles directly to an Apple Shortcut. The Cherri programming language introduces proper if/else constructs and for loops for robust control flow, explicit variable declarations like @varName = value and const for constants to manage data state, and string interpolation for dynamic content. Custom actions and #include directives further enhance modularity and project organization, directly improving the development experience. This structured approach, inherent to the Cherri programming language, drastically reduces the cognitive load associated with complex visual workflows, making it a powerful tool for serious automation.
Consider a scenario where you need to process a list of items, applying different logic based on multiple conditions. In Apple Shortcuts, this quickly becomes a sprawling mess of nested "If" blocks and "Repeat with Each" actions, where tracking data flow is a constant struggle. The Cherri programming language, with its familiar textual syntax, allows developers to express such logic clearly and concisely, much like any other modern programming language. This clarity not only speeds up initial development but also makes maintenance and debugging significantly more manageable, transforming what was once a visual puzzle into a readable script.
Cherri as a Compiler: A Fundamental Shift
Unlike a simple wrapper, the Cherri programming language functions as a full compiler. You write filename.cherri, execute ./cherri filename.cherri, and a .shortcut file is generated. This represents a fundamental architectural shift from tools like Scriptable, which runs JavaScript within its own app sandbox, or Jelly, which often relies on more abstract DSLs. Cherri targets a 1-1 translation to Shortcut actions, which is critical for debugging. An opaque compiler output merely shifts the point of obscurity, hindering effective root cause analysis. This direct compilation approach ensures that the generated Shortcut is as efficient and native as possible, leveraging the underlying Apple Shortcuts framework directly.
The Signing Problem: Trust Boundaries and Supply Chains
The compiler output is a .shortcut file. The critical question is how it gets onto your device. The project documentation states the compilation process: "Attempts macOS signing, falls back to HubSign service (unless --skip-sign is used)."
The "HubSign service" presents a significant concern. It introduces a critical trust boundary. Skipping macOS signing means implicitly trusting HubSign with your compiled Shortcut. Critical questions arise regarding HubSign's security posture, their key management strategy, and the audibility of their signing process. This is not merely a technical detail; it's a fundamental security decision point for any developer using the Cherri programming language for deployment.
A remote signing service is a single point of failure and a prime target for supply chain attacks. We've seen this scenario before: Storm-0558 wasn't a logic error; it was stolen keys. If HubSign's signing keys are compromised, every Shortcut signed by them becomes suspect. The potential impact would be enormous, affecting potentially thousands of users who rely on Shortcuts generated by the Cherri programming language. The risk is not theoretical; it's a documented failure mode in the supply chain, demanding rigorous due diligence.
The --skip-sign flag is acceptable for development. However, for any deployed artifact, you're either managing your own macOS signing or you're betting on HubSign's operational security. This represents a non-negotiable decision point, as it directly impacts the integrity and trustworthiness of deployed artifacts. Organizations deploying critical automation via the Cherri programming language must carefully weigh these trust implications.
AI and the Amplification of Flaws
The idea of "teaching AI to write Apple Shortcuts" using Cherri is a prospect that warrants careful consideration due to its potential implications. LLMs excel at generating syntactically correct code. However, they are notoriously bad at generating secure, efficient, or logically sound code without extensive human oversight and precise prompting. While the Cherri programming language provides a structured environment, it doesn't inherently mitigate these AI-generated risks.
If Cherri simplifies Shortcut generation for an LLM, it also simplifies the generation of subtle bugs, unnecessary complexity, or even security vulnerabilities. These issues would then be compiled into a signed, runnable .shortcut file. Cherri's type system might catch basic errors, but it won't prevent a logic bomb or a poorly designed data flow. I've recently reviewed pull requests where AI-generated code included references to non-existent libraries, leading to compilation failures. Beyond that, other instances have produced code that compiles successfully but exhibits critical logical flaws at runtime. The adoption of the Cherri programming language with AI tools requires a robust validation pipeline.
The core problem isn't the language; it's the source of the code. An LLM generating Cherri code shifts the debugging burden from visual blocks to potentially hallucinated text, then to compiler errors, and finally to runtime issues within the Shortcut itself. This does not simplify the overall system; it merely relocates the complexity. Understanding these trade-offs is crucial when integrating AI with the Cherri programming language.
Cherri: A Pragmatic Assessment of Trade-offs
The Cherri programming language represents a necessary evolution for anyone serious about building complex Apple Shortcuts. It directly addresses the fundamental pain points of the visual editor by providing proper programming syntax, control flow, and project structure. This is a substantial improvement over the block-based nightmare, offering a more robust development experience than merely scripting within Scriptable's runtime.
However, it is not a panacea. The reliance on a remote signing service like HubSign introduces a critical supply chain risk. This requires thorough vetting or a bypass via local macOS signing. Furthermore, while LLM integration might accelerate initial development, it will inevitably introduce new classes of bugs and security vulnerabilities if not managed with extreme caution.
The Cherri programming language addresses existing problems, but in doing so, introduces a new set of challenges. It is a tool that requires a thorough understanding of its capabilities and a critical awareness of its potential failure modes. Its adoption necessitates a full comprehension of the new trust boundaries being established, ensuring that its powerful capabilities are harnessed responsibly.
