The main points users usually ask about are offline behavior, sandboxing, and how exported apps interact with local files and remote resources.
No. The main app works completely offline and does not send requests to a server. An exported app also works fully offline when the embedded or selected HTML project is self-contained. If your source HTML references external APIs, scripts, fonts, media, or other internet resources, the exported app will request those because the HTML itself requested them.
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.
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 only to the selected source HTML location. This lets you update the HTML files without rebuilding while keeping the app source scope limited. That source-folder access is separate from Open With document access, which can be writable only for the specific opened files or folders 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.
Yes. If you want the generated app to always open a remote website instead of packaged local content, you can create a simple local HTML file that contains an iframe pointing to the online page, then package that HTML file with HTML to App. In that setup, the app shell is local, but the website content still loads from the internet.
HTML to App is made by Ihor July, the same independent developer behind Parall and DockLock Pro.
Both HTML to App and the generated HTML apps it exports work on macOS 10.12 and newer. If you need compatibility confirmation for a specific macOS release or hardware setup, contact [email protected] before relying on it in production.
