Distribution Strategies¶

This guide helps you choose the right distribution strategy for your protected Python application.

Three Approaches¶

Build a native executable for each target OS using PyInstaller, cx_Freeze, or Briefcase.

Best for: Desktop apps distributed to end users who may not have Python installed.

myapp.exe      (Windows)
myapp          (macOS binary)
myapp          (Linux binary)

Build a .whl and protect it. Customers install with pip install.

Best for: Developer tools, libraries, and CLI apps where customers have Python installed.

myapp-1.0.0-py3-none-any.whl

Package your Python source or bytecode into a .zip and protect it.

Best for: Internal tools, quick prototyping, or when you want the simplest packaging step.

myapp.zip

Factor	Executables	Wheel	ZIP
Customer needs Python?	No	Yes	Yes
Single artifact for all OSes?	No (one per OS)	Yes	Yes
Native OS integration (file associations, icons)?	Yes	No	No
Build complexity	Medium	Low	Low
Professional feel	High	Medium	Low
CI/CD matrix required?	Yes	No	No
Can wrap in installer (.msi, .dmg, .deb)?	Yes	No	No

You can offer multiple distribution formats for the same app:

Executables for end users — customers download a native binary from your delivery page
Wheel for developers — developers install via pip for programmatic use or scripting

Both share the same PyLocket app and licensing. A single license key works across all formats and platforms.

Regardless of strategy, upload the raw build output — not installer containers:

Upload This	NOT This
`myapp.exe` (PyInstaller onefile)	`myapp.msi` (Windows installer)
`myapp` (macOS/Linux binary)	`myapp.dmg` (macOS disk image)
`build_dir.zip` (PyInstaller onedir, zipped)	`myapp.deb` (Debian package)
`myapp-1.0.0.whl` (wheel)	`myapp.rpm` (RPM package)

After protection, you can optionally wrap the protected output in an installer for professional distribution. See Multi-OS Publishing for details.