Excel for Mac does include VBA, and a lot of macro code written on Windows runs there unchanged. What does not carry over is anything that reaches outside Excel into Windows itself: ActiveX controls, Windows COM objects such as Scripting.FileSystemObject and WScript.Shell, and Windows API declarations. macOS has no equivalent of those, so code depending on them fails with a runtime error rather than degrading gracefully.
That distinction matters because it decides whether a given tool works. A macro that formats cells, loops through rows and builds a report is usually fine. A tool that talks to the operating system is usually not.
What generally does work in Excel for Mac
- The VBA editor itself, under Tools → Macro → Visual Basic Editor
- Ordinary object model work: ranges, sheets, workbooks, formatting, charts, pivot tables
- UserForms, which do work on Mac and are often assumed not to
- Form controls, including buttons that run a macro
- Worksheet and workbook events, and
MsgBoxandInputBoxfor simple prompts
What does not work in Excel for Mac
- ActiveX controls. ActiveX is a Windows technology built on COM, and macOS has no COM, so there is no workaround. The Insert menu on Mac has no ActiveX section at all. Use Form controls instead if a workbook needs to run on both.
- Windows COM objects via
CreateObject.Scripting.FileSystemObject,WScript.Shell,MSXML2.XMLHTTPand Outlook automation all fail with run-time error 429, ActiveX component can’t create object. - Windows API declarations. Any
Declarestatement pointing at a Windows DLL has nothing to bind to. - Registry access, since macOS has no registry.
- Some file and shell operations.
FileDialogandShellbehave inconsistently, andApplication.InputBoxwithType:=8for selecting a range is notably unreliable on macOS.
The sandbox is the underlying reason
macOS runs Excel inside a sandbox that limits what an application may touch outside itself. Even file access that Windows grants freely has to be explicitly permitted on a Mac. That is good security design, and it is also why anything built around Windows-specific components does not simply port across.
Writing VBA that runs on both
If you need one workbook to work on both platforms, three habits cover most of it.
Use Form controls, never ActiveX
A Form control button runs the same macro and works everywhere. ActiveX buys you extra design flexibility on Windows and breaks the file for every Mac user.
Branch with conditional compilation
VBA can compile different code per platform, so a Windows-only routine can be isolated rather than removed:
#If Mac Then
' Mac-safe version
#Else
' Windows version
#End If
This is evaluated when the code compiles, so the Windows-only branch is never even parsed on a Mac.
Never hardcode a path separator
Use Application.PathSeparator rather than typing a backslash, so the same code builds a valid path on either platform.
Why ExcelGurus tools are Windows only
Both of our products, EG Quote & Invoice and Excel Data Cleaner, are Windows-only and will not run in Excel for Mac.
The reason is the category described above rather than anything about the interface. Parts of each tool rely on Windows components that have no equivalent inside the macOS sandbox. Those parts are not cosmetic and cannot be switched off, so a Mac version means rebuilding that layer rather than adjusting a setting. It is on our list, but we would rather say plainly that it does not work today than ship something that half runs.
If you downloaded one of our tools on a Mac, that is why you saw a notice telling you it needs a Windows PC.
What to do if you are on a Mac
- Use a Windows PC if you have access to one. The files are ordinary
.xlsmworkbooks and work normally there. - Run Windows in a virtual machine. Parallels or VMware Fusion with a Windows licence and a Windows copy of Excel works. Note that Boot Camp is not an option on Apple Silicon Macs.
- Use a remote Windows desktop, if your workplace provides one.
- Ask us. If you need something built that must run on a Mac, tell us what the process is. Plenty of automation can be written to be cross-platform when that is a requirement from the start.
Common questions
Does Excel for Mac support macros at all?
Yes. VBA is present and the editor is under Tools, Macro, Visual Basic Editor. The limits are about which external components the code can reach, not about macros as a feature.
Do UserForms work on a Mac?
Yes. UserForms are supported in modern Excel for Mac and are frequently confused with ActiveX controls, which are not.
Why does my macro fail with error 429 on a Mac?
Run-time error 429 means CreateObject tried to create a Windows COM object that does not exist on macOS. Common culprits are Scripting.FileSystemObject, WScript.Shell and Outlook automation.
Can I just convert a Windows macro to work on a Mac?
Sometimes. If it only manipulates the workbook, it may already run. If it uses ActiveX, the registry, Windows APIs or COM objects, those parts need rewriting rather than converting, and occasionally there is no Mac equivalent at all.
Will there be a Mac version of your tools?
It is on the list, but there is no date. It is a rebuild of the parts that depend on Windows rather than a recompile, so we would rather do it properly than rush it.
When Formulas Aren’t Enough
Cross-platform automation is a design decision, not an afterthought:
- Mixed teams — some staff on Windows, some on Mac, one workbook between them
- Files that travel — a tool sent to clients whose setup you do not control
- Existing tools that break — something that worked for years until one person switched machine
A tool built for both platforms from the start avoids the rewrite later.
Need an Excel Tool That Works on Both Platforms?
Tell us who needs to use it and what it has to do, and we’ll build it to suit.
Start a Project