Introducing Composer for Keynote.

Don't let the adorable robot fool you: Composer isn't some kind of random A.I. presentation builder. It's a production-grade worker for the factory floor of Keynote itself.
There's been an absolute avalanche of A.I. presentation tools announced this past year – some of it really interesting, conceptual speaking. And who doesn't want to get their next show wrapped up faster?
But it doesn't take long with any of these tools to see the downsides piling up: limited personalization and creativity, generic design sensibilities, inflexible output – not to mention data privacy concerns, subscriptions to yet another walled garden. It's tiring.
Yet there's something undeniably attractive about that premise, isn't there? It would be great if I could just write out what needed to be said and have that magically appear in Keynote – using my theme, with my own customizations, with total control over the output. Something I could actually use on Client decks and real shows, not just one-off novelties. All the upsides of process automation without the massive downsides.
That sounds... actually useful. So we made it.
Meet Composer for Keynote
At its root, Composer is an Automation Engine for Keynote. It takes Plain Text descriptions of Objects, Slides, or entire Presentations & generates AppleScript routines to automate their production in Keynote for MacOS. It's predictable, repeatable, and fully transparent.
To use it, you simply describe the contents of a slide – as native Markdown from apps like Obsidian or Ulysses, or by field through Composer's Scaffold Editor. For example, here's the first part of source script for the Intro show in Obsidian:

The source script for the Intro presentation is written in Markdown format, shown in Obsidian for Mac.
There are a few Tagged items used there (highlighted in purple) to dial in the specific output we're looking for, but it's otherwise vanilla Markdown text – it's extremely lightweight, easy to format, and allows for a complete separation of your content from the confines of any particular file-level implementation.
Composer takes that input, and analyzes your show's Title hierarchy and the types of Body matter used on each slide to map out the Latent Intent of the slide against Keynote's standard layouts – or to layouts you specify yourself with Tags – and generates the AppleScript required to build each slide in Keynote for MacOS:

Composer generates open AppleScript routines to run in MacOS Script Editor.
Composer's generated AppleScript is fully open for review – or further edit if you're handy – in MacOS Script Editor before run-time. Whenever you're ready, you simply click Play in Script Editor to generate the show:
A live Build Script in action in Keynote for MacOS, targeting the Chicago Sans theme.
As we're still in Beta, the output is currently very much geared toward whole-show builds vs patch-ins or edits – that will evolve as we bring more of the supporting logic online.
And it should be noted that while you can target any valid theme target (Composer is 100% Theme Agnostic), we're using Chicago here for a reason: some of the item-level targeting displayed in this clip requires that each of the layout's placeholders be set a particular way to be identified by AppleScript (*Keynote doesn't expose a placeholder's Tag or Display values to Applescript). At the moment, Chicago's the only system in the Library fully-optimized for extended Targeting – but updates are already underway to bring more of the back-catalog up to speed, and we'll have additional formatting information coming online shortly to help you dial in any Custom Themes you've built for better compatibility.
During the initial Limited Beta, we're staging access to Composer by Theme as each system moves from Composer-Compatible to full Composer-Enhanced status. If you'd like to get in early, Join the Waitlist and we'll do our best to accomodate – you'll otherwise receive a Notification once one of the themes in Your Library is updated for full Targeting support.
Something Old, Something New.
Composer is far from the first tool to work with Markdown this way: apps like Deckset or Hyperdeck are available for the Mac – not to mention the venerable md2key, which has bridged Markdown & Keynote for years. We actually ended up standardizing around Markdown as Composer's low-level control surface very recently, thanks to a long-time customer who loves using Deckset for drafting shows, but wished there was a faster way to upscale that to show-grade Keynote output without having to then build it again, slide-by-slide.
The idea of Markdown > Presentation pipelines isn't exactly new – nor is the notion of targeting Keynote with Markdown, for that matter. In Composer for Keynote, though, Markdown is more of a means to an end than a raison dêtre – it's something we have in common with other tools, but also the line where those similarities (mostly) end.
Composer was conceived, first and foremost, as an Author Assistive platform. Composer understands Markdown – but it specializes in Keynote, and speaks Applescript to achieve targeted production objectives. It doesn't convert Markdown to a couple of basic utility layouts and move on – it builds a manifest to understand the sort of slide you're building, and translates it to the native Keynote types required to achieve it.
There's no A.I. black-box making random decisions on your behalf at play here: it's basic deduction. We refer to it as Latent Intent, which is to say that a Layout is generally evidenced by the Content that's present in the description of a slide without it having to be specified: an h2 Title element + a List element = a Title & Bullets Layout, broadly speaking. So if you're going for one of about a dozen standard Keynote layouts, you can just focus on your content & Composer will generally handle the rest, mapping each of the consituent elements of the inferred slide layout to their respective object on the Keynote stage.
And there's nothing to install or changes you'll need to make to your Keynote theme to get that running: Composer's designed with decades of established Keynote architecture in mind, and maps output to Keynote's standard layouts – in every language Keynote supports – automatically (including a host of layouts that used to be standard but aren't anymore, if you're running an older bit of kit):





One Script, 4 Stops: Composer can build in any standard Keynote theme, illustrated here in 4 of Apple's default themes.
Engineered for Pros
In a professional setting, the defaults & standards will only get you so far, of course – and we've never been particularly restrained to Keynote's defaults around here (to put it mildly). So to build a truly Author-assistive framework, we need to be able to scale not only into the extended complexity of modern theme & template systems, but also into the lifecycle of presentations themselves as practical, tangible elements of corporate communication. That... is a mouthfull: let's walk that out.
First, theme level. When it comes to AppleScript in Keynote, it's one thing to say Apply Layout XYZ – that's the easy part. It's another matter entirely when you need to zero in on a specific item on that layout (that isn't the Title or Body). As noted above, Keynote doesn't expose a placeholder's Tag or Display values to AppleScript, so it's literally not possible in a Generic Keynote theme: at run time we can only effectively check for any remaining "empty" objects & take a chance, which isn't a great look for production.
So a bit of symbiosis between engine and theme is needed to effectively bridge targeting on the object level – particularly as those layouts scale in object volume or complexity. Hence the notion of a theme being Composer-Enhanced: the layouts needs to be able to fully declare themselves for AppleScript to precisely target whithin them.

When you're targeting a Composer-Enhanced theme, you can script changes to any placeholder on the layout with precision.
That solved, you have the makings for an actual production line taking shape – a state where the show's original script can drive any number of one-off iterations or variations on the resulting Keynote file generated, no matter the complexity of the layout.
And if we scope back out to questions of presentation lifecycle in day-to-day workflows, some obvious benefits emerge. If you run a Daily Stand-Up, for instance: once you've tuned your baseline model, it's essentially effortless to compose today's version of that deck from your latest notes over in Obsidian. You don't even need to bother saving the actual Keynote file afterwards – it's literal emphemera.
Or, as was the case last year on one of the client projects that inspired this entire initiative in the first place: the show looks great – now we also need it French, Spanish, and Chinese. That's a signifigantly smaller lift if we're simply assuring the final translations are slotted into the right segment of the show script: it's just Plain Text, after all.
We've been largely focused on the Theme side of the Theme/Template equation so far: both here, and literally in terms of Composer's current capabilities. So to talk Templates, we're going to be pushing into Roadmap territory a bit.
Long-time customers will remember a time when everything you needed could be included in the Core Theme itself (or even further back, when we had a button that would open a Theme's Extras folder). Over time, though, as the complexity of the presentation landscape itself grew ever more diverse, so too did the requirements for must-have elements to have on hand to pull a contemporary show together as quickly as possible – much of which couldn't even be defined theme-level.
Thus our Elements Templates were born – which now account for the vast majority of layout starters included with any given system. We've always tried to keep the distinction between Theme and Template as easy-to-navigate as possible given the constraints of the file-type differences, one being installed vs the others not, etc. – but from an Author-assistive perspective, there's a huge amount of un-needed complexity involved here that a framework like Composer can rise to address.
And as attractive as the idea of being able to simply declare a Timeline sounds – it also opens the door to all-new (for Keynote) possibilities, like that Timeline being generated on-the-fly according to your specs, instead of you needing to modify the closest starter you could find (in a file that itself included 5 variations because we couldn't be sure how many columns you'd actually need).
Again, this is Roadmap territory – and will take a bit of time to play out – but it should give you a pretty good sense of how we're approaching the juncture of the pre and post-Composer Landscape. There's much more to come on this front, and we'll get into more detail as we're taking each stage live – Stay Tuned.
Moving Forward
As noted above, we're going to be staggering access to Composer by theme during the Beta, as each theme moves from Compatible to Enhanced status – you'll receive a notification once one of the themes is Your Library is cleared for full Targeting Support.
Once you're in, you'll see a Blue Compose button at the top of the Composer page whenever you're signed in. At this stage of deployment, we've opened Markdown and Scaffold routes for Build a New Presentation, and we'll be adding additional routes and options as they've cleared Test.
If you'd like to dig deeper into Composer-flavored Markdown and how the scripts are formatted in the meanwhile, be sure to check out the full Formatting Guide for additional details.
Additional Resources