Web apps
Web app builds produce an installable PWA by default. You get a live preview subdomain and a GitHub repository for the project.
What you receive
Section titled “What you receive”- A responsive web app with an installable PWA baseline.
- A live preview URL for review and sharing.
- A GitHub repository containing the project source.
- Follow-up editing through Visual Edit or Revise.
Install the app
Section titled “Install the app”The generated app includes the pieces a browser needs for installation, including an app manifest, icons, and offline support. You can install it from a supported browser and open it like an app.
Edit after delivery
Section titled “Edit after delivery”Use Visual Edit to change a theme or a specific element in a finished web app. Use Revise for functional changes and describe the behavior you want in plain words. LoopCodeLab plans targeted follow-up stories instead of rebuilding the whole project.
| Change | Use |
|---|---|
| Colors, typography, spacing, or one visible element | Visual Edit |
| New behavior, data, integrations, or multiple coordinated screens | Revise |
Preview and manage a finished app
Section titled “Preview and manage a finished app”On the finished build page, the Preview tab has its own Collapse control. On desktop, collapsing Preview expands the Stories and main content area and leaves a slim Build preview dock on the right. On mobile it leaves a horizontal reopen bar. Reopen the dock at any time; collapsing it does not stop the preview from refreshing after a story merge or asset change.
Open Assets to inspect the app’s Git-tracked images, video, audio, and documents. Filter the list with All, Images, Video, Audio, or Documents. Images, video, and audio have native previews, PDFs can open in an embedded preview, and other documents use a file card. Open and Download appear when the file supports them.
For a completed Web app or an Auto build that produced a web app, choose Add from URL to bring an online file into the build. Enter a direct HTTPS file URL and optionally select every story it supports; no selection imports it as Unassigned. LoopCodeLab creates a Git-tracked managed copy under the build, while the source website and its original file remain unchanged. The imported copy then supports the same story management, replacement, rebuild, and version history as other editable local assets.
Imports accept the supported image, video, audio, and document formats shown in Assets. Media can be up to 25 MB and documents up to 20 MB. For safety, LoopCodeLab rejects URLs with embedded credentials and any local, private, reserved, or special-purpose network destination. It checks DNS again after every redirect, allows at most five redirects, applies connection/download timeouts and a streamed size limit, and verifies that the downloaded bytes match the server’s declared supported file type.
The available change buttons depend on the file:
- Regenerate on an editable image opens its prompt and a Regenerate image action.
- Replace opens Replace build asset with side-by-side Current and Selected replacement previews where the browser supports them. Check the filename, size, and type, then choose Replace & rebuild. The same project path is rebuilt and the previous file remains in Versions.
- Versions previews or downloads earlier committed versions. Restore confirms the selection and makes it current as a new version, preserving the rest of the history.
- Manage stories opens a checklist of every build story. Select all stories the asset supports and choose Save story links. With nothing selected, the asset is Unassigned and stays in the build-wide gallery.
The main Assets tab is always the complete build gallery. A story’s Edit, Schedule, or Regenerate dialog also has a compact Story assets section containing every file linked to that story. A shared file appears in each linked story. When more than three assets are linked, the strip offers View all and Collapse. It keeps Open, Download, Regenerate, and Replace where supported; version history and Restore remain in the main Assets tab.
Story-linked editable assets can be replaced, and supported images regenerated, after a Web app or Auto build settles as Done, Failed, or Push failed. A failed status does not discard assets from stories that already merged, so you can repair one while a different story or finalization remains failed. These actions stay locked during queued work, building, review, finalization, and delivery. If another asset change is running, wait for it to finish before retrying or editing a story.
The separate Assets destination in the account/sidebar area is broader still: it is the reusable workspace library across builds. Story assets do not replace that overall gallery.
Older assets, or files whose history does not identify one story reliably, stay Unassigned in the main gallery until you link them with Manage stories. LoopCodeLab does not guess from filenames.
Compiled output can appear as read-only, while hidden, configuration, lock, and credential-like files are not listed. If an asset changed after you opened it, reload Assets before trying again. Changes also wait while another asset update is running or a code edit still needs Keep or Discard.
External deliverables stay in their provider. If the web app records one, Assets shows a read-only Primary deliverable with Open / edit. Edit a Google Doc, Sheet, or Slides file and manage its versions in Google. Drive-delivered media is not copied into Assets; use the build’s Open in Drive link instead.
Online media is supported when its license and permitted use allow it. Build agents are instructed to download, record the source, and commit that media as a local build asset instead of leaving a user-facing image, video, or audio file hotlinked. This keeps it available for inspection, versions, and replacement. Remote CDN code and fonts can remain remote, and user-entered runtime URLs are not treated as build assets.
Package for Windows
Section titled “Package for Windows”You can package a completed web app as a Windows installer or a Microsoft Store package. The packaging build runs on GitHub Actions and the resulting file is shared through Drive.