Every change, three times
New fall banner
Web
→Deploy< 60s
iOS
→Rebuild→Submit
Waiting for App Review
Android
→Rebuild→Submit
Waiting for App Review
× every change
Every native feature. One SDK.
Seventy-one of them, and 61 run on a real phone in the demo app.
- Push notificationsNew
- In-app purchases
- Native transitions
- Modal sheetsNew
- Face ID login
- QR scannerNew
- Share sheetNew
- Sign in with AppleNew
- Live locationNew
- Photo pickerNew
- Deep linksNew
- App badgeNew
- Incoming sharesNew
- Saved loginNew
- ContactsNew
- Health dataNew
- Audio playerNew
- Voice recorderNew
- Date-time pickerNew
- Rating promptNew
- Tracking promptNew
- NFC scanNew
Docs and a live demo for every one.
Typed, documented, identical on iOS and Android. Call them from the JavaScript you already write.
In-app purchases
Sell digital goods on both stores. Verify receipts server-side.
Every deploy updates every install.
Web, iOS, Android: everyone runs your latest deploy, even users who never update the app.
The old way ships every change three times: a web deploy plus an iOS and an Android rebuild submitted for store review. With BDK you deploy the website once and every installed app and browser shows the update.
Native changes to the icon, entitlements or runtime ship through a store build. Your own developer accounts, built for App Review.
How App Review sees thisWatch your AI wire it up.
Pick the tool you build in. This is the whole integration: the reference it reads, the files it writes, the phone answering.
PreviewCode
SharePublishSend a server push that opens the linked post using env credentials
Read server/onesignal-push
server/notifications/sendReply.ts+12
Send the deep link from the server with env credentials
Server-only push uses env credentials and opens Post 42.
Ask Lovable...
Build
acme-storefront.lovable.app
server/notifications/sendReply.ts+12
1import { sendPushNotification } from "@thebdk/native/server/onesignal";2 3const result = await sendPushNotification({4 message: "New reply on your post",5 title: "Inbox",6 subtitle: "From @jess",7 imageUrl: "https://cdn.example.com/preview.png",8 onLoadUrl: "https://app.example.com/posts/42",9 urlParams: [{ key: "ref", value: "push" }],10 data: { postId: 42, kind: "reply" },11 subscriptionIds: ["a1b2c3d4-1111-2222-3333-444455556666"]12});The full prompt
Integrate @thebdk/native into this app so camera and Face ID work when the deployed site runs inside BDK's native shell, while the normal web app keeps working in a browser.
First read https://docs.thebdk.com/llms-full.txt and the page for each feature you add. Use only the helper names, event names, and option keys documented there — don't invent API.
Then:
1. Add the @thebdk/native package.
2. Create one shared client in src/lib/bdk.ts with a browser-safe import:
import { createBdkNative } from "@thebdk/native/browser";
export const bdk = createBdkNative();
3. Build the features with the typed namespaced helpers only: bdk.media.*, bdk.ui.*,
bdk.navigation.*, bdk.iap.*, bdk.auth.*, bdk.location.*, bdk.device.*, bdk.share.*,
bdk.permissions.*.
4. Subscribe with bdk.on(event, cb) BEFORE you call anything interactive — the result
arrives on the event, not on the returned promise.
5. In a browser the call doesn't run: it resolves with triggered: false. Branch on
!result.triggered and keep a real web fallback so the Lovable preview and the web
build both still work. Don't describe that case as skipped or not_native, and don't
wait for a native event in the web UI.
6. Anything from @thebdk/native/server/* is backend-only. Read credentials from environment
variables — never put keys or server imports in client code.
Don't claim you created iOS or Android apps, wrapped the site, signed builds, submitted to a store, or verified native behaviour in the preview.
Finish with the files you changed, the web fallback you added, and this hand-off: publish this app to its URL, connect that URL at thebdk.com so BDK packages and signs the iOS and Android builds, then test native features in the BDK-packaged app.Running in the BDK-packaged app
Adds camera and Face ID. The web preview keeps working on the fallback path.
- One shared client —
npm install @thebdk/native, one import, everything else untouched. - Results arrive on events. The prompt tells the agent to subscribe with
bdk.on(…)before it calls. - Outside the app, calls resolve untriggered. The integration branches on
!result.triggered, so your web build keeps working.
No codebase? There is nothing to install. Connect your app's URL in the dashboard and the builds come out the same.
Machine-readable reference: llms.txt — the file your agent fetches. How agents use it →
Three steps. No new stack.
- 1
Install the SDK — or don't
Have a codebase?
npm install @thebdk/native— one dependency, fully typed. No codebase? Nothing to install. Step 3 is the whole job. - 2
Call native features where you want them
Camera, biometrics, purchases, push — from your existing JavaScript. One build: browser tab or App Store install, it just runs.
- 3
Connect your URL. Get store-ready builds.
Point BDK at your app's URL in the dashboard. BDK packages and signs the iOS and Android builds for your own developer accounts, and walks you through each store's submission. From then on, deploying your web app updates every phone.
app.ts
import { createBdkNative } from "@thebdk/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.
The long answers.
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. Apps packaged this way have been going through review for years. 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, or a runtime upgrade); for those, BDK hands you a fresh signed build to submit.
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, @thebdk/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.
Do I need to change my web app?
No. It runs as-is. Add @thebdk/native only where you want native features; everything else is untouched, and the same build keeps serving your regular website.
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.