Build anywhere. Ship to every phone.
Your web app,
on the App Store and Google Play.
BDK wraps the app you built — with Claude Code, Lovable, Bubble, or any stack — in a native runtime with camera, push, biometrics, and payments, then hands you signed, store-ready builds for both stores. Deploy your site; every installed phone updates instantly.
The demo is itself a BDK-packaged app — the native features in these docs, running on your phone.
BDK Runtime
native runtime + typed SDK
BDK has built apps for thousands of customers — browse the app gallery.
AI can write your app.
Shipping mobile is still a job.
Your tools are good at code — code was never the blocker. What stands between a working web app and a product in people's pockets is everything generation doesn't touch.
Your tools already did this
- Screens and flows
- Business logic
- Auth and database
- APIs and integrations
- Web deploys
Still between you and the stores
- App Store and Play listings — and review
- Signing, provisioning, certificates
- Push notifications, end to end
- Camera, location, and biometric permissions
- In-app purchases and receipt verification
- Deep links that survive install
- A new OS release every year, on two platforms
- A second and third codebase, if you go native
Most of the second list is BDK's job, on both platforms. The store side — listings, submission, review — stays in your own developer accounts, with a step-by-step guide for each store.
One codebase, or three?
Yes — your AI tool can generate a native app, and native is great. Here's what you're signing up for.
| Generate a separate native app | Ship with BDK | |
|---|---|---|
| Codebases you own | Three: web, iOS, Android. | One — the app you already have. |
| Shipping a change | Regenerate, rebuild, resubmit, wait for review. | Deploy. Phones update instantly. |
| Keeping features in sync | Three implementations that drift. | One implementation. Nothing to reconcile. |
| When generation falls short | You debug Swift and Kotlin — or hire someone who does. | You fix it in the stack you already know. |
| Native capabilities | Wire each platform SDK, twice. | One typed SDK for both platforms. |
Camera, push, purchases — from the JavaScript you already write
Typed, documented, and identical on iOS and Android. Every card is a live reference page, and nearly all of them run for real in the demo app.
Three steps. No new stack.
- 1
Install the SDK
npm install @bdk/native— one dependency, fully typed. - 2
Call native features where you want them
Camera, biometrics, purchases, push — from your existing JavaScript. The same build runs in a plain browser tab (native calls resolve safely there), so you ship one app for web and native.
- 3
Connect your URL. Get store-ready builds.
Point BDK at your app's URL in the dashboard. BDK packages and signs iOS and Android builds ready for the App Store and Google Play; you submit them from your own developer accounts, with a step-by-step guide for each store. From then on, deploying your web app updates every phone.
Building with an AI agent?
These docs ship in agent-readable form. Point Claude Code, Cursor, or any agent at docs.native.thebdk.com/llms.txt and it can wire the SDK into your app for you. How it works →
import { createBdkNative } from "@bdk/native/browser";
const bdk = createBdkNative();
await bdk.ready();
// Results arrive on events — subscribe, then call.
bdk.on("photoCaptured", (photo) => upload(photo.fileUrl));
await bdk.media.capturePhoto();
// Native UI, one line.
await bdk.ui.showBanner({
title: "Saved",
description: "Photo uploaded."
});That's the whole integration model. Full reference in the docs, every feature runnable in the live demo.
Prompted, coded, or no-code — same path to the stores
You prompted it into existence
You shipped a product without a team — don't adopt two native codebases now. Keep iterating on the one app your AI tool understands. Every deploy reaches every installed phone.
Start with the docsYou engineered it
Keep your framework, router, and CI. Add a typed SDK where you want camera, biometrics, or purchases — full TypeScript coverage, an objects reference, an event catalog. Nothing changes about how you build, test, or deploy.
Read the SDK referenceYou built it no-code
No terminal, no Xcode. Create your app in the dashboard — BDK packages and signs store-ready builds and guides you through both store submissions. Native features are one action away when you want them.
Create your appThe store listing is the easy part. Staying live is the job.
Mobile isn't hard because of the code. It's hard because it never stops moving.
BDK has spent years keeping customers' production apps alive through exactly that churn. The runtime absorbs it; your app keeps working — and you keep building product.
You can't prompt your way out of platform churn. With BDK, you don't have to think about it.
- Every iOS and Android release
- Permission-model changes
- Push-provider quirks
- Purchase and receipt edge cases
- Store policy churn
- Runtime and WebView updates
Shipped, in their words
From the public app gallery — apps customers took to both stores with BDK.
“Gaurav, You made it so easy for me to have a presence on the App Stores. I could take my idea from Bubble to a Native App in my customers hands. Thank you!”
“Gaurav has made publishing into the app stores very simple. The process is easy to follow, customizable and if you have questions, he is always there to give a hand.”
“Thanks to BDK Native solution, my Bubble app is now on the Google and Apple stores — and I couldn't be happier. I tried a few other solutions before arriving at BDK and came up against difficulties I couldn't resolve. 5+++ stars!!”
The questions you're about to google
What is BDK, exactly?
A native runtime for iOS and Android that renders your live web app full-screen inside a real, store-distributed binary — plus a typed JavaScript SDK, @bdk/native, that bridges your code to the device: camera, biometrics, purchases, push. BDK packages and signs the store-ready binary; you submit it from your own developer accounts, guided step by step. Your web app stays a standard web app, hosted by you.
Won't Apple reject it as a repackaged website?
Apple's guideline 4.2 targets apps that add nothing beyond their website. That's exactly what the SDK is for: biometric login, push notifications, in-app purchases, the share sheet, and deep links integrated into your app are the capabilities that separate an app from a site in a shell. Nobody can guarantee review — but BDK-built apps have been passing it for years, and the live demo is a BDK-packaged app you can judge for yourself.
Aren't instant updates against store rules?
No. Your app renders your live site — deploying your website is how web-based apps are meant to work, not a code-injection trick. Store review applies when the native side changes (icon, entitlements, runtime updates); for those, BDK hands you a fresh signed build to submit.
Do I need to change my web app?
No. It runs as-is. Add @bdk/native only where you want native features; everything else is untouched, and the same build keeps serving your regular website.
Whose developer accounts do the apps ship under?
Yours. You submit through your own Apple and Google developer accounts, so the store listings, ratings, and customer relationships belong to you. BDK hands you the packaged, signed, store-ready builds and a step-by-step guide for each store.
Am I locked in?
Your product is a standard web app on your own domain and hosting, and your store listings live in your own developer accounts — both stay that way. Remove the SDK calls and it's exactly the site it was before.
How is this different from a PWA or Capacitor?
A PWA can't sit in the App Store or sell through in-app purchase. Capacitor hands you native projects to own — building, signing, and rebuilding stay your job, forever. BDK's runtime is managed: packaging, signing, and platform churn are its problem, not yours.
Day 1
You build the app in your tool of choice.
Week 2
Real users. They ask where the app is.
Week 3
You add @bdk/native where it counts: push, login, purchases.
Week 4
You're on the App Store and Google Play. Same codebase.
Build with AI. Ship with BDK.
The app is done. The stores are next — without starting a second codebase.