How to automate a Mac app without an API

You can automate a Mac app without a public API by using its scripting commands, Shortcuts actions, file interfaces or user interface. The right route depends on the task: a fixed sequence can work well as a script, while a workflow that needs decisions between steps may benefit from a computer-use agent.

Start with the result you need. An export should produce the right file. A document edit should leave the right text in the right document. The automation is useful when you can check that result, regardless of how impressive the clicking looks.

At a glance: check the app's existing automation surfaces, choose the simplest one that covers your task, run a small trial on disposable data and inspect the output. Use computer use for the steps that genuinely require the interface. Keep a working script or integration for the steps it already handles well.

Define the task before choosing the tool

“Automate this app” is too broad to test. Write down a starting state, a requested change and an observable finish.

For example, consider this illustrative task: open a scratch document, add a specified line and save it under a new name. You can inspect the saved document to see whether it worked. A larger instruction such as “organize my project” leaves too many decisions implicit.

A useful task specification records:

• The app and document or window the automation may use.
• The input and exact output you expect.
• The changes it may make, including whether it may overwrite anything.
• The point at which it should stop and ask for help.

This also tells you which part needs a graphical interface. Preparing text or renaming files may be straightforward outside the app. Applying an app-specific setting may require a command the app exposes, or an interaction with a control.

Check for automation surfaces beyond a web API

An app can expose useful automation without offering a REST API. Look for scripting support, Shortcuts actions, command-line tools, URL schemes and documented import or export formats. Check the app's own documentation for the operation you need.

On macOS, an app's scripting dictionary lists its commands and objects. Apple documents how to open a scripting dictionary in Script Editor. A dictionary's existence is only the beginning: confirm that it covers your intended operation.

Also inspect the action library in Shortcuts or Automator. A workflow may already have an action for the difficult step. Where a documented file format covers your task, you may be able to prepare the file outside the app and use its import function.

Be specific about the gap. “This app has no API” and “this export option is not exposed by the app's automation interface” lead to different solutions. The second describes the step you actually need to solve.

Choose a method for each part of the workflow

You can combine these methods. A script can prepare input files. An agent can handle a remaining interface step. A separate check can inspect the exported result.

Make the handoff between methods explicit. Record which file was created, which window was selected and which state the next step expects. A successful preparation step does not tell you whether the final export succeeded.

Try Shortcuts or Automator when the actions fit

Shortcuts builds workflows from individual actions. Search for your app and the operation in the action library, then inspect what each action accepts and returns. Apple's Shortcuts introduction explains the model.

Automator also offers app and data actions. It can record an interaction for inclusion in a workflow, as described in Apple's workflow guide.

Build the smallest useful workflow first. Give it one disposable input and inspect the result. Expand it after the individual steps behave as expected. A recorded sequence still needs to cope with the state it will encounter: a dialog, changed selection or slow operation can alter what the next input reaches.

Use UI automation when the interface is the available route

UI automation acts through controls, menus, keyboard input or screen coordinates. It can reach operations that an app's scripting interface does not expose. Apple describes this route in its guide to scripting the user interface.

A fixed UI script specifies the sequence in advance. A computer-use agent observes the current interface and chooses actions as the task progresses. That flexibility introduces a different requirement: the agent must obtain enough information to choose the right control and check what happened afterward.

Control labels and accessibility information can help identify a button or field. Screenshots can show visual information those controls do not expose. Each tool combines these sources differently, so test the exact app and workflow you intend to use.

Pay attention to window selection. Two windows from the same app can contain similar controls. A “Save” command is only useful if it reaches the intended document and destination.

Give your first trial an independently checkable output

Use disposable data and a task small enough to inspect yourself. This test specification is an example to adapt to your installed app and automation tool:

In the scratch document named “Automation trial”, add the line “First trial complete”. Save a copy named “Automation trial result”. Keep the original document. Stop if the target document is ambiguous or an unexpected dialog appears. Report the saved file's location.

Before running it, confirm that the scratch document exists and that saving a copy is supported by the method you chose. Afterward, open the output and inspect the text and filename. Check that the original remained intact.

That is a stronger check than an agent saying it finished. A tool can accept an input while its effect remains uncertain. A file can exist while containing the wrong content. Verify the property that matters to the task.

Once the small trial works, add one source of complexity at a time: a longer document, a second window or a different starting state. Record any manual intervention. Those observations reveal what the workflow depends on.

Where Mecum fits

We build Mecum for agents that need to work inside desktop apps on a Mac. Its desktop perception turns the current interface into structured text that the agent can use to identify controls and understand state.

The project documents local MCP connections for Claude Desktop, Claude Code and Codex. MCP connects the client to Mecum's desktop tools; the client still chooses how to use them. The local MCP guide describes the current source baseline and connection lifecycle.

This is useful when a task reaches a GUI step your existing integration does not cover. Start by observing the intended window, then try a bounded change with a result you can inspect. Match the instructions to your installed release; a capability documented in source still needs verification in the package and workflow you use.

Mecum's window-to-text processing runs on the Mac. If you connect a remote model, its requests can include window text and task context. Read the compatibility and data notes before choosing your setup.

Test background work as a workflow requirement

If you want to keep using the Mac during automation, add that condition to the trial. Check the task while you work in another app, then inspect the output and any pauses or interruptions.

Mecum's Driver uses a virtual display within the current Mac session. Desktop work takes turns. The display shares the Mac's user session and filesystem; it does not create a separate virtual machine. These boundaries are described in the background-work documentation.

A background claim should answer a practical question: can this task finish correctly under the conditions in which you plan to use it? Focus changes, another window and an unexpected dialog may matter more than the number of clicks in a demo.

Record failures before expanding the workflow

Keep a short record of the app version, automation version, starting state, requested result and actual output. Separate a completed task from a partial result, a refusal and an uncertain effect.

If the automation stops, inspect the app before retrying. The last action may already have changed a document or started an export. Resuming from the observed state helps avoid doing that operation twice.

For a missing control, record what you expected and what the tool observed. For a failed save, check the selected document, destination and dialog. This gives you a concrete issue to fix instead of a broad conclusion that the entire app is unsupported.

Common questions

Can you automate a Mac app that has no public API?

Often, yes. The app may expose scripting, workflow actions or file formats. UI automation can cover some remaining operations. Success depends on the exact controls, permissions and task, so begin with a small output you can verify.

Is an AI agent necessary for every automation?

Use a fixed script or workflow when it reliably covers the task. A computer-use agent becomes useful when it needs to interpret interface state or choose the next action. Combining the two can keep straightforward steps predictable.

Does a successful click mean the task is complete?

Inspect the final output. A click can be delivered without producing the expected change. Check the document, file or app state that defines success for your task.

Choose one task, write down its finish condition and run a small trial. If the missing step lives inside a desktop app, use the Mecum setup documentation to prepare that trial and verify the result on your Mac.