XLS Padlock compiles your Excel workbook into a native 64-bit Windows application (a Windows .exe). That format runs on Windows only, so the compiled .exe will not run directly on macOS, even when the project has no external links or DLLs. This is by design: the protection layer and the embedded runtime that opens your workbook are Windows components, and the workbook stays protected only inside that Windows runtime.
One important point, because it also explains the "operating system is not presently configured to run this application" error you reported separately: the protected app needs x64 Windows (a normal Intel or AMD processor). It is not supported on Windows on ARM. This matters on a Mac, because on today's Apple Silicon Macs (M1, M2, M3, M4) a virtual machine such as Parallels, VMware Fusion, or UTM runs Windows on ARM, not x64 Windows, so the protected app is not supported there and can fail at launch. So a VM on an Apple Silicon Mac is not a reliable route.
The routes that do work are the ones that give you real x64 Windows:
- A normal Windows PC (Intel or AMD), which is the simplest.
- An Intel-based Mac with Boot Camp, which runs native x64 Windows. Note this applies to Intel Macs only, Boot Camp does not exist on Apple Silicon.
- A remote or cloud x64 Windows machine (for example an Azure or AWS Windows instance, or any Windows remote desktop) that your Mac users connect to.
Wine and CrossOver are sometimes used to run Windows programs on macOS, but they are not supported or tested with XLS Padlock protected applications, and the activation and protection features in particular cannot be guaranteed there, so we do not recommend that route.
There is no macOS build of the protected application, and distributing the original .xlsm to Mac users would leave it unprotected, so pointing your Mac users at a real x64 Windows environment is the practical path. If you tell us what your Mac is (Apple Silicon or Intel) and how you are trying to run it, we can be more specific.
