Questions people ask.

Yes. This is a settled architectural pattern called server-driven UI (SDUI), and it has been clearing App Review at scale for years. Airbnb's Ghost Platform powers search, listing pages, and checkout this way. Netflix, Lyft, DoorDash, Block, and Shopify ship variants of the same pattern. The open-source Hyperview framework — closest in spirit to HypeApps — has been used in Instawork's production app since 2018.

Apple's relevant rule (guideline 2.5.2) prohibits apps from downloading code that introduces or changes features or functionality. The accepted reading across the industry: markup that arranges and parameterizes components already shipped in the binary is data, not code. The Hyperview maintainer puts it bluntly in a public discussion: "the XML responses are not modifying the binary code to unlock new iOS SDKs."

HypeApps holds the same line. Every tag, action, trigger, and reactivity operator is implemented natively in the Flutter binary. The server picks from a fixed vocabulary; it cannot define new widgets or call iOS APIs that aren't already there.

Yes, for anything that's just markup, copy, layout, styling, navigation flow, or reactive state. Change a file on your server, your app reflects it next time someone opens that screen. Same model as a website. This is the whole point.

The exception: if you want to use a new native capability (e.g. a new sensor, a new platform API, or a tag HypeApps hasn't shipped yet), that requires an app update through the store — because the capability has to be in the binary. This is the line that keeps the architecture App-Store-safe.

It shouldn't, for the reasons above — but the things that get apps rejected near this area are worth knowing so you don't accidentally walk into them:

• Minimum functionality (guideline 4.2): if the app does nothing without your server, or feels like a wrapper around a website, it can get bounced. Ship a real native onboarding/baseline experience.
• Webview wrappers: apps that are essentially a WebView pointed at a URL get rejected under 4.2. HypeApps doesn't use WebViews — it renders native widgets — but the framing matters if a reviewer doesn't know what they're looking at. Include a sentence in your review notes.
• "Vibe coding" / dynamic logic engines: Apple has been removing apps in 2025–2026 that download executable logic that can reach into native APIs. HypeApps explicitly doesn't do this.

If you ship a real-feeling app with bundled native content as a baseline, you are on the same side of the line as the established players.

Anything that's markup-shaped — a copy fix, a button reorder, a new screen built from existing tags, a flow change — is server-side. Push it whenever, no store review, no rollout staging.

Anything that needs new platform behavior — a new tag, a new sensor permission, a deeper SDK integration — is a binary change and goes through the normal store update process. That's the trade you're making for App Review safety.

No. There is no browser in the loop. The markup you send is parsed by the HypeApps client and rendered as real native widgets (Flutter, which renders Material and Cupertino components). Scrolling, gestures, animations, keyboard, and accessibility are all native. The reason you're writing HTML-like markup is for the developer experience, not because anything is being shown in a browser.

You don't write JavaScript or Dart. There's no Metro, no bundler, no Xcode toolchain in your day-to-day. Your server returns markup; the app renders it. The whole development experience is "edit a file, refresh the screen" — like building a website.

HypeApps is built on top of Flutter (we use the renderer), but you never interact with Flutter directly. Think of Flutter as the engine you didn't have to write.

Same family. Hyperview uses XML over React Native; HypeApps uses HTML-style markup over Flutter. HypeApps also borrows Alpine-style client reactivity (@click, , @text) and Tailwind-style utility classes for styling — so the day-to-day feel is closer to writing a modern web page than to writing XML.

The shared idea — fetch markup from a server, render native widgets, htmx-style partial swaps — is identical. If Hyperview makes sense to you architecturally, HypeApps will too.

No. Anything that can return HTML works. Laravel, Rails, Django, Express, Go, Phoenix, plain PHP, a static file host — whatever you already use. There's no SDK to install on the server side.

HypeApps is fundamentally server-driven, so the design center is "your server is the source of truth." Cached content and bundled assets work without a connection, but if your app's whole job is offline-first with sync, this isn't the right tool.

Yes — the app is out. Hype Apps: Learn HAM is free on the App Store: every screen in it is HAM, and you can press & hold anything to see the markup that built it. Write your own in the playground, and it mints a five-letter code — type that code into the app and your creation runs native on your phone, live from the server.

The full framework — the SDK for shipping your own standalone apps — lands Fall 2026. Join the waitlist to get that build the day it ships.

Licensing and distribution model haven't been announced yet. Following along on the journey is the best way to be the first to know.