App Maker Mobile: build in a 390 by 844 phone frame, skip every other step
A mobile app maker does not have to mean Xcode, Android Studio, a developer account, or a store review. mk0r renders your idea in a real iPhone-sized viewport inside the same browser tab you typed it into. Here is exactly how that preview works and what it means for how you build.
What a "mobile app maker" usually means, and what mk0r does instead
Most pages that talk about making a mobile app walk you through a native toolchain. Install Xcode. Set up Android Studio. Create a developer account. Build a signing certificate. Pick a template from a drag-and-drop canvas, connect a data source, wait for a build job. The first time you see your idea running on a phone is usually at the end of a long checklist.
mk0r reverses the order. The first thing you see is the running app, at phone dimensions, in your browser. Then, if you decide you care about a store listing or a native wrapper, you can point a Capacitor or Expo shell at the same URL later. The preview comes first because the preview is the product.
The 390 by 844 mobile frame is the anchor
When you switch to mobile in the device toggle, the preview container clamps to 390 pixels wide by 844 pixels tall. Those are the CSS pixel dimensions of the iPhone 14 Pro viewport. They are not a guess, they are a constant. You can read it in the repo:
Why this matters for a mobile app maker: the layout you design against is the layout a phone user sees. Sticky bottom tabs sit where thumbs land. A safe area for the home indicator stays reserved. Font sizes that look right in the frame look right on the device. You are not designing for a generic responsive rectangle and hoping it lands.
The pipeline, from prompt to phone-sized preview
When you submit an idea, a few things happen at once. The client asks the server to keep a warm VM ready. A session key is issued. If you picked VM mode, a Vite plus React plus TypeScript sandbox boots and returns a preview URL. The AppPreview component loads that URL inside the 390 by 844 iframe. From there, every agent file write flows through the HMR pathway below.
Mobile build pipeline
How the iteration loop actually works
Most builders treat iteration as a full rebuild. mk0r treats it as a conversation with a running app. Here is what happens each time the agent writes a file:
Type the idea
A prompt like "a running log that tracks pace per km with a bottom tab for history" is enough. No picker, no template, no wizard.
The preview opens in mobile framing
The AppPreview component sets the iframe to 390 by 844 CSS pixels. The frame does not change size as content loads, so the layout you see is the layout a phone browser will see.
Files stream in
In Quick mode, HTML lands character by character. In VM mode, the agent writes files inside a sandbox, the Vite dev server picks them up, and HMR bubbles the update into the iframe.
800ms HMR window
Each file write bumps a refreshNonce. The preview waits 800ms for the Vite bridge to post hmr:after. If it arrives, nothing reloads. If it does not, the iframe cache-busts and replaces itself without a white flash.
Open the preview URL on a real phone
The VM's dev server is reachable on a public URL. Paste it into your phone browser and the same app appears, same HMR, same session.
What you can actually build in the mobile frame
The 390 by 844 viewport is not a toy. It is the exact real estate a real phone user has. Anything that fits a mobile web app fits the preview. Some examples that work well inside this frame:
Bottom-tab task app
A sticky bottom nav, three screens, local storage. Fits the 390 viewport with space for the home indicator.
Single-screen utility
Tip calculator, unit converter, timer. Quick mode often finishes one of these in under 30 seconds.
Photo prompt journal
Camera capture via the web MediaDevices API, a feed of cards, pull-to-refresh animation.
Checklist with swipe actions
Swipe to complete, swipe to archive. Touch gestures wired with pointer events.
Daily habit ring
A circular progress ring, three rings stacked, haptic-like pulse on tap.
Recipe flow
Ingredient list plus stepwise instructions plus a timer on each step. Routing between screens in VM mode.
Native builder flow vs the mk0r flow
A side by side of what you trade when you skip the native toolchain.
| Feature | Native app makers | mk0r |
|---|---|---|
| Account required to start | Yes, email plus plan tier | No. Type and build |
| Toolchain install | Xcode, Android Studio, JDK, or SDK | None. Runs in a browser tab |
| Preview device | Emulator or paid cloud device | 390 by 844 iframe, live |
| Time to a previewable screen | Tens of minutes, often longer | Quick mode under 30 seconds, VM mode 1 to 3 minutes |
| Iteration loop | Edit in a drag canvas, rebuild | Follow-up prompt, HMR repaints the frame |
| Source code ownership | Proprietary format, export often gated | Plain HTML, CSS, JS, or a Vite React project you can download |
| Share a live build | TestFlight invite, APK sideload, review queue | Copy the preview URL, open on any phone browser |
Ownership: you leave with code, not a locked project
A mobile app maker that hands you a proprietary format is a mobile app maker you will eventually have to migrate away from. mk0r does the opposite. Quick mode outputs a single HTML file with embedded CSS and JavaScript. VM mode outputs a Vite plus React plus TypeScript project you can download, push to GitHub, or continue building in any editor. There is no export tier, because nothing is gated behind export.
If you want to ship to an app store later, you wrap the same code in Capacitor or Expo and submit. Nothing about the mk0r preview prevents that path, the preview is just the fastest way to see the app first.
Why this preview design is hard to copy
The 390 by 844 frame is easy. Any CSS grid can clamp a div to that size. What is less easy is the HMR handshake. When a file changes in the sandbox, the AppPreview component listens for postMessage traffic from a Vite bridge injected into the iframe. If the bridge reports a successful patch inside the 800ms window, no reload happens, and scroll position, input focus, and local state stay intact.
That means iterating on a form does not nuke what you typed. Iterating on a scroll feed does not snap you back to the top. The mobile preview feels like you are hacking on a live phone screen, because, for the cases where HMR lands, you are.
When HMR misses, the fallback is a cache-busted reload that keeps the previous iframe rendered underneath until the new iframe finishes loading. No white flash, no jarring cut.
Want to see your mobile app idea rendered live?
Book a 20 minute walkthrough and we will build one of your app ideas in the mobile preview with you on the call.
Book a call →Frequently asked questions
Does mk0r build native iOS or Android apps?
No. mk0r builds mobile web apps, rendered in a 390 by 844 iframe that matches the iPhone 14 Pro logical viewport. You get real HTML, CSS, and JavaScript that runs on any phone browser. If you want, you can wrap the result as a Progressive Web App and install it from the browser's share sheet, or point a Capacitor or Expo shell at the preview URL later. You do not need Xcode, Android Studio, a developer account, or any native SDK to start.
Why 390 by 844 specifically?
Those are the CSS pixel dimensions of the iPhone 14 Pro viewport. It is a safe middle ground: wide enough to show common mobile layouts, short enough that desktop users see the top of the page without scrolling. The constant lives in DEVICE_SIZE inside src/components/phone-preview.tsx. Switching to desktop mode removes the frame entirely so the preview fills the panel.
How fast does the mobile preview update when I iterate?
When the agent writes a file, the preview waits up to 800 milliseconds for Vite's HMR bridge inside the iframe to paint the change. If HMR hits, there is no reload flash at all. If HMR does not acknowledge within 800ms, the iframe cache-busts with a new query parameter and reloads, keeping the previous frame visible underneath until the new one finishes loading so there is no white flash.
Can I open the same app on my actual phone?
Yes. Every preview is served from a public VM URL. Copy the URL from the preview panel, open it on your phone, and you see the same app running on a real device. Hot reloads from the browser panel propagate to the phone through the same Vite dev server, so you can iterate on a desktop and watch the changes land on a phone beside you.
What is the difference between Quick mode and VM mode for mobile builds?
Quick mode streams a single HTML file with embedded CSS and JS. It is perfect for a static mobile page, a landing screen, or a self-contained tool. VM mode spins up a Vite plus React plus TypeScript project inside a sandboxed cloud VM, runs the dev server there, and points the mobile-framed iframe at the VM's public URL. VM mode is the choice when you want routing, state, a real project you can keep editing, or when your prompt asks for something that needs more than one file.
Do I need to sign up before I can build?
No. Type your idea at mk0r.com and the mobile preview starts filling in. You can build, iterate, and share a preview URL without creating an account, entering a credit card, or confirming an email.
Can I export the code?
Yes. In VM mode the full project tree lives in the sandbox, and you can download it or push it to GitHub. In Quick mode the generated file is plain HTML and CSS and JS you can save from the browser. mk0r is open source, so you can also self-host the builder if you want.
Describe your mobile app idea. Watch it render at 390 by 844. No account, no toolchain, no wait.
Build My Mobile App