AutoFlowRPA now runs on macOS
The same visual automation editor, the same 339 commands, now as a native Apple silicon app — and a look at what it took to get the engine running inside a .app bundle.
Sep 26, 2026
AutoFlowRPA has been a Windows application since day one. As of v0.1.22 there is a macOS build too: a native Apple silicon app, the same node canvas, the same engine, the same workflows.
You can download it from the dashboard, or straight from the v0.1.22 release.
What you get
339 of the 369 commands work on macOS. Everything that was never tied to Windows internals came across unchanged:
- Web — Playwright-driven browser automation, with real profiles, proxies and fingerprints
- Excel (44 commands), Word, PDF — through openpyxl and python-docx, no Office required for most of them
- AI (19 commands), Gmail, Google Sheets & Drive, HTTP/REST
- Video (27 commands) and media download, via FFmpeg and yt-dlp
- Image and OCR, database, clipboard, encryption, files, triggers, variables, data transforms
What is missing, and why
Thirty commands depend on Windows APIs that have no macOS equivalent. They are hidden from the palette rather than left in to fail:
| Group | Commands | Depends on |
|---|---|---|
| UIAutomation | 11 | Windows UI Automation |
| Window | 10 | Win32 window management |
| Outlook | 6 | Outlook COM |
| Run PowerShell, Run CMD | 2 | Windows shells |
| Run Excel Macro | 1 | Excel VBA over COM |
The desktop element picker and the desktop recorder are hidden for the same reason. Browser picking and browser recording work fine — those never used Windows APIs.
Two things worth knowing before you install
Apple silicon only. There is no Intel build yet. If there is demand we will add one; the build pipeline already supports it.
The app is not notarized yet. Notarization needs a paid Apple Developer account, so macOS will refuse to open it on first launch. The reliable way past that is to clear the quarantine flag:
xattr -dr com.apple.quarantine /Applications/AutoFlowRPA.app
You may also find an Open Anyway button under System Settings → Privacy & Security after the first blocked attempt. Do not rely on the old Control-click trick — macOS removed that override, and an ad-hoc signed app often reports itself as "damaged" with no override offered at all.
Grant two permissions on first use. Keyboard and mouse commands need Accessibility; screenshots need Screen Recording. Both are under System Settings → Privacy & Security. This matters more than it sounds: macOS does not raise an error when they are missing. Input commands quietly do nothing and screenshots come back blank. If a workflow seems to run but changes nothing, check the permissions first.
The interesting part: why a port is never just a recompile
The cross-platform code had been written months earlier and everything compiled. The app still did not work, and the reasons are a decent illustration of why "it builds" and "it runs" are different claims.
The engine could not start inside the bundle. AutoFlowRPA runs its Python
engine as a sidecar process next to the desktop shell. On Windows the shell and
the engine's runtime payload land in the same folder, so the frozen engine finds
what it needs. A macOS .app splits them: executables go in Contents/MacOS,
resources in Contents/Resources. PyInstaller, seeing its binary in
Contents/MacOS, looked for its Python runtime in Contents/Frameworks — where
nothing had been placed. The app opened and the engine was dead on arrival.
Moving the payload into Contents/Frameworks did start the engine. It also made
the bundle unsignable: that directory may only contain frameworks and
dylibs, and code signing refuses the whole app over a stray .dist-info
directory. An unsignable bundle cannot ship on Apple silicon. The fix was to
keep the runtime tree intact under Contents/Resources and teach the Rust shell
to launch it from there.
Stop had to be proven, not assumed. Stopping a workflow has to kill the
whole process tree — the engine plus whatever it spawned: a browser, FFmpeg, a
sleeping subprocess. The Unix implementation puts the engine in its own process
group and kills the group. That code had only ever been compiled, never run. It
turns out a Playwright browser exits on its own when its parent dies, so a naive
test passes whether or not the group logic works. Measured against a workflow
that also spawns a plain sleep: killing the process group left zero orphans,
killing only the process id left the sleep running.
One command lied about succeeding. PDF export reported success and produced no file. The underlying library drives Microsoft Word over AppleScript, and when that times out it prints an error and returns normally rather than raising. For unattended automation a silent success is worse than a crash, so the command now verifies the file exists before it reports anything.
None of these would have been caught by a build server that only checks whether the compiler is happy.
What is next
Intel builds, notarization, and closing the two remaining silent failures — detecting a missing Accessibility or Screen Recording permission up front, instead of letting a workflow run and do nothing.
If you hit something on macOS, tell us from the dashboard. The macOS build is new and your report is the fastest way to get it fixed.