Common questions

HTML to App is coming soon to the Mac App Store. It is not available to download yet. You can request launch updates from the homepage.

Yes. The main window has a project list and source editor. Use the + menu to create a new project folder, add an existing folder, or create an editable copy from the Example Gallery. Select a source file to edit HTML, CSS, JavaScript, and other supported UTF-8 text, then save, run a preview, or export an app.

Yes. Save and Command-S write to the original project folder. Adding a folder to the workspace does not copy it. Use Duplicate Project if you want a separate copy for experiments. Remove from List removes the workspace entry without deleting the source folder.

No. Convert HTML to App can package an existing HTML file or website folder directly. Use the project workspace when you want to keep editing the source, previewing changes, and reusing app settings for later exports.

Export copies the bundled, precompiled launcher and configures its name, icon, resources, and settings. It embeds your HTML content or references its original location, then applies an ad hoc signature for personal use and local testing. It does not compile new native code or use a Developer ID distribution certificate.

No. HTML to App is for personal tools and local testing, not preparing apps for public distribution or App Store submission. Exports are ad hoc signed, not notarized or approved by Apple. HTML to App does not replace the Apple Developer Program or Apple's applicable signing, notarization, and review processes. The builder's planned Mac App Store listing does not cover the apps you export.

Choose Open App on the completion screen. macOS may require local launch confirmation for your own trusted export. The screen offers manual guidance and an optional script you can review and install. Local approval is only launch handling on your Mac, not Developer ID signing, notarization, an Apple malware review, or App Store approval. If macOS reports damage or malicious software, stop and investigate. Read the first-launch guidance.

After you explicitly install it, the script handles the current export and runs automatically after later exports while it is up to date. It runs outside the App Sandbox to remove quarantine from the specific exported bundle for local use. It does not change the signature, grant privacy permissions, or disable Gatekeeper across your Mac. Use View Script to review it, Update Script when offered, or Scripts Folder to remove it and disable automation. Manual handling remains available.

The built-in gallery includes Geometry Pad, Text Editor, Image Viewer, Audio Player, Video Player, Folder Board, Menu Bar Controls, Notifications and Badge, Camera Viewer, and Native Integration Demo. Create Project saves an editable copy in a new folder. Each example includes instructions for trying it.

It checks the saved entry page and static HTML and CSS resource paths, reporting missing local resources, paths outside the project, and external URLs. It does not test JavaScript-generated paths or run a backend server. Use Run and test the exported app to check behavior. Checks & Output also shows JavaScript errors and console messages from the preview.

The preview uses the same local HTML renderer and is useful for layout, navigation, and supported bridge features. Test camera, microphone, location, notifications, Dock badges, and Finder Open With in the exported app. Preview storage and exported app storage are separate.

Creating, editing, and exporting local projects works offline. Previews and exported apps also work offline when the HTML project is self-contained. If your source references external APIs, scripts, fonts, media, or other internet resources, that content can make network requests in both the preview and the exported app.

No. The exported bundle sends no data on its own. Whether the final app is completely offline depends on the source HTML you package. If your wrapped HTML includes JavaScript calls to APIs, CDNs, fonts, analytics, or other internet resources, those requests will still happen because the embedded HTML content requested them.

Exports are sandboxed. Besides their own app container, they include read-only permission for the Downloads folder by default, even when individual Downloads files have not been selected. Reference-mode exports also receive read-only access to the selected source folder. Open and save dialogs can authorize other locations, and Editor-role Open With handling supports scoped write-back. macOS privacy protections still apply.

No. The exported app bundle is sandboxed and does not get broad write access to arbitrary locations. When Open With is enabled and the role is Editor, the JavaScript bridge can write only inside the specific file or folder that the user opened into the app. For anything outside that scope, file writes still depend on explicit user-approved save or export dialogs.

Yes. If the generated app is registered with Open With role Editor, JavaScript can overwrite the opened file directly, or create, replace, move, and remove files and subfolders inside an opened folder item. That write-back scope stays limited to the exact opened item tree.

The exported app stays sandboxed and receives read-only access to the selected source folder so it can load later HTML edits without exporting again. That folder must remain available. This is in addition to the default read-only Downloads permission. Source-folder access is separate from Open With document access, which can be writable within the specific opened file or folder when the app role is Editor.

It works best with self-contained local HTML projects where files are linked by relative paths. The HTML app should include its own HTML, CSS, JavaScript, images, and other assets locally instead of depending on a server-side backend or absolute local paths. HTML-based tools that use native macOS open and save dialogs are also a good fit.

Only if the destination allows embedding. A local HTML page can contain an iframe pointing to an online page, but sites can block it with X-Frame-Options or Content-Security-Policy frame-ancestors restrictions. HTML to App does not bypass those restrictions. The remote content still requires an internet connection. Self-contained local HTML projects remain the intended use case.

HTML to App is made by Ihor July, the same independent developer behind Parall and DockLock Pro.

The current builder requires macOS 12 or newer. Its export process includes an ad hoc signing step that also requires macOS 12 or newer. On macOS 11 or earlier, that step fails before the app is saved to the selected export destination.

The current bundled launcher targets macOS 12 or newer. This is separate from the builder's requirements. Your HTML and chosen native features also depend on the system WebKit engine and macOS capabilities, so test them on the version you use. Export does not add support for older macOS releases.