Make useful personal tools without giving them unrestricted access to your system.
HTML to App uses macOS App Sandbox in both the workspace and exported apps, with a
few-click workflow for local web projects with an HTML entry page.
How you package a project and how its app runs are separate security decisions.
A convenient command or a familiar app window does not tell you what either can access.
While you package
A shell is not a project-only sandbox
Ordinary Terminal commands run with your account's permissions unless you add restrictions.
Changing into a project folder does not confine a script to that folder. Running a downloaded
project's build or install scripts can therefore give that code access beyond the project.
That does not mean Terminal has root privileges or Full Disk Access by default.
File permissions and macOS privacy controls still apply.
See Apple's command-line guide
and file-access protections.
HTML to App packages ready-to-run web projects without running their build scripts.
It copies and configures its precompiled launcher. Projects that need a web build step
must be built separately, with that toolchain's own security considerations.
When your app runs
A web renderer is not the whole app
A browser engine can isolate web content while the native app hosting it remains outside
macOS App Sandbox. If an exploit reaches that host, the host's available permissions matter.
Renderer sandboxing and app-level sandboxing protect different boundaries.
Electron's process-sandboxing guide
explains this distinction between renderer and main processes.
HTML to App also sandboxes the native launcher.
This adds OS-enforced limits on the host's access to files and system resources.
Apple describes App Sandbox as a way to
limit the damage a compromised app can cause,
not a guarantee against every vulnerability.
Other tools can support app-level sandboxing too. For example, Electron documents a
separate App Sandbox configuration.
Compare the actual configuration, not just whether a tool has a terminal or a window.
Specific access, not unlimited access
The sandbox is not zero access. The workspace works with project folders you approve.
Here is what the current exported apps can access.
The app's own container
Each exported app can read and write its own sandbox container for settings and local data.
It does not receive unrestricted access to the rest of your home folder.
Files and folders you authorize
Open and save dialogs authorize selected locations. Reference-mode apps get read-only access
to the selected source folder. Editor-role Finder integration allows write-back within the
specific opened file or folder tree, not arbitrary locations elsewhere on disk.
Read-only Downloads access
Every export includes read-only permission for the Downloads folder by default, even when
individual files there have not been selected. It does not grant write access to Downloads.
macOS privacy protections still apply.
Network and device permissions
Outgoing network access is enabled, so project code can contact online services. Camera,
microphone, and location access depend on your export settings and macOS authorization.
Sandboxing does not mean that every project runs offline.
Creating, editing, and exporting projects happens on your Mac. No project upload is needed.
No app analytics or telemetry
HTML to App and its exported launcher do not collect usage analytics or send project files
to a developer-operated service. Your project list and app settings stay on your Mac.
Your project's code still matters
Your project's JavaScript can call APIs or include tracking. Its HTML pages and CSS
can also reference remote resources. Code with access to a file may send its contents
over the network. Review what you run
and what you share with it. The website's analytics are separate from the app.
Read the privacy policy.
First launch is a separate choice
Packaging does not need a Terminal build pipeline. macOS may still ask you to approve
the first launch of your own trusted export.
The optional script is outside the sandbox
You can review and explicitly install an optional script that removes quarantine from
the specific exported app. The script runs outside App Sandbox and, once installed and
up to date, runs automatically after later exports. Manual handling remains available.
This does not remove the exported app's sandbox, grant privacy permissions, or provide
notarization or App Store approval. Exports remain for personal use and local testing,
not ready-made public distribution. If macOS reports damage or malicious software,
stop and investigate.
A stronger boundary, not a reason to trust every download
Sandboxing reduces risk. It cannot promise to stop every exploit or protect files
you have deliberately made available to a project.
Choose what you run and share
Review downloaded JavaScript, HTML pages, stylesheets, remote dependencies, and requested permissions before running a project.
Test editors with disposable copies. A project allowed to write a document can still damage that document.
Keep the protection in perspective
Keep macOS updated so the system WebKit engine receives security fixes.
Use Check Project to find resource problems. It is not a malware scanner or a security audit.
