BDK Native
- iOS + Android apps$99
Total, once$99
1 build + 4 rebuilds, the rebuilds banked for 12 months
The apps are yours for good. No renewal.
Introductory pricing, valid until Thanksgiving.
For Cursor apps
Put your Cursor app in the App Store and Google Play
Try a sample purchase, the camera, a deep link, Face ID and push on your own phone, free, while you build in Cursor. Pay once when it's right.
- Free on your phone first, before you pay and before an Apple developer account.
- $99 once for both apps. No monthly fee.
- Nothing to lapse. Your app keeps working.
Sample products in Preview. Your own products in your build.
All five run in the free BDK Preview app.
Keep your code and your repository private. BDK needs just your app's public address. On iPhone, BDK Preview opens your own previews.
Try it on your phone first.
Natively's own docs say in-app purchases, deep links, the camera and audio don't work in their preview app. All four run in BDK Preview, free, on your own phone (purchases with sample products).
What you can test in each service's free preview, before you pay. From each company's own docs, as of October 29, 2026.
BDK Preview next to Natively Preview.
 BDK Preview | Natively Preview | Median | Despia | MobiLoud | |
|---|---|---|---|---|---|
| Push notifications | Yes¹ | Yes | No shared preview app. You test in a browser simulator, where some native features can't be tested, or in a watermarked build of your own app. | No shared preview app. You test free watermarked builds of your own app. | Their team arranges a preview of your site before purchase. Native-feature testing on a phone isn't documented. |
| Camera | Yes² | No | |||
| Record and play audio | Yes² | No | |||
| Deep links | Yes³ | No | |||
| In-app purchases | Sample products⁴ | No | |||
| Face ID / fingerprint | Yes² | Not documented | |||
| Google / Apple sign-in | Shows the hand-off⁵ | No (social login) | |||
| Your own loading screen | Yes⁶ | No (custom loading screen) | |||
| Needs an Apple developer account to try on iPhone? | No (public TestFlight)⁷ | No (App Store) | Yes ($99 a year) | Yes ($99 a year) | Not documented |
✗ where their docs say it doesn't work. “Not documented” means we found nothing either way. Sources below.
- Push in BDK Preview runs on BDK's own keys; your own OneSignal and Firebase keys are used in your build.
- Phone features that need no account of your own run in Preview, as they will in your build.
- Deep links in Preview run through BDK's Branch / ChottuLink setup, under BDK's branding.
- Purchases in Preview use BDK's sample products; your own products work in your own build.
- BDK Preview can show the hand-off, but it doesn't prove your store app's Google or Apple sign-in setup.
- Your loading screen, in Preview. Your own icon shows in your build.
- On iPhone, BDK Preview opens your own previews. It doesn't prove store review.
Sources, as of October 29, 2026 (15)
Pay once. Not every month.
Like buying a bike instead of renting one every month. BDK is one payment; a wrapper subscription keeps charging.
One payment
If you stop paying: There's nothing to stop. No subscription, no banner, no kill switch. Your app keeps working.
Natively Unlimited, monthly
- Month 1$49
- Month 2$49
- Month 3$49past BDK
So far$147
Or Lifetime, paid once$699
and every month after
Yearly, $384, passes BDK on the first payment.
If you stop paying: Their FAQ says a blocking banner covers the app until you reactivate.
Prices from each company's pricing page as of October 29, 2026; BDK prices as of October 19, 2026. Apple ($99 a year) and Google ($25 once) charge for their own developer accounts with every service. Median: $229 activation, then $179 a year on Starter; its free tier is for limited use.See pricing
Yours to keep.
Your own listing.
Published from your own Apple and Google accounts. Ratings, reviews and installs are yours.
The Android signing key.
It comes with every Android build.
Go fully native later.
When it pays, your team can build a fully native app. It can ship as an update to the same listing: same name, same reviews.
Point the app at a new address from your BDK dashboard, with no new store submission.
Closer to native.
Screens slide in, sheets pull down, prompts appear when they're needed. Each one is a call from your app's code, through the free @thebdk/native package.
71 native features in total. Try most of them live in the demo app.Open demo.thebdk.com
- Native transitions
- Modal sheetsNew
- Share sheetNew
- Sign in with AppleNew
- Live locationNew
- App badgeNew
- Incoming sharesNew
- Saved loginNew
- ContactsNew
- Health dataNew
- Audio playerNew
- Voice recorderNew
- Date-time pickerNew
- Rating promptNew
- Tracking promptNew
- NFC scanNew
- Push notificationsNew
- In-app purchases
- Face ID login
- Deep linksNew
- QR scannerNew
- Photo pickerNew
How it works with Cursor.
Deploy your app.
Deploy it to a public HTTPS address on Vercel, Netlify, Railway, Render or your own server. Use the production address, like yourapp.vercel.app or your own domain. Not localhost, and not a preview deployment that asks for a sign-in.
Open it on your phone.
Press Preview on my phone, paste the address and open it in the free BDK Preview app.
Add phone features.
Push to everyone needs no code: you send it from your own OneSignal account. For the rest, Cursor's agent runs npm install @thebdk/native and adds the calls to your code. Face ID, the camera, external Google sign-in, in-app purchases and push to one person start there. Your backend still sends one-person notifications and decides who has paid.
Order, then submit.
Pick iOS, Android or both, and fill in one short form. Create your App Store Connect entry and push key. BDK builds, signs and uploads to TestFlight. You test and submit for review; Apple and Google decide.
Ask for it in plain words.
Tell Cursor's agent what you want, in plain words. Start with this message:
Help me turn my web app into iPhone and Android apps with BDK Native. Fetch https://thebdk.com/agent/skill.md and follow it.
For each appointment, send the customer a push notification an hour before it starts, and don't send it if they cancel. Let returning members sign back in with Face ID, and show the usual sign-in if it doesn't work.
When an AI report finishes, send a push notification to the person who asked for it and show an unread badge on the app icon. When they run out of credits, offer more as an in-app purchase.
When a teammate is assigned a job, send them a push notification with the address, and let them attach a photo from the phone's camera when they finish.
Cursor's agent adds these with the free @thebdk/native package. Reminders, push to one person, credits and ticket checks still need your backend: it knows each booking, sends each notification, decides who has paid and marks each ticket as used. On iPhone the badge can be a number; on Android it follows the notification. Face ID unlocks your existing sign-in rather than replacing it.
Before you buy.
Check these on your phone first.
Your production address
Open the address on your phone in a private browser window, signed out of your host. If it asks you to log in to Vercel, it's a protected deployment, and the app would ask too. A vercel.app address with a long code in it is one fixed deployment. A deploy-preview address on Netlify is a preview. Use your production address. Localhost and a tunnel from your laptop stop when your laptop does. Free hosting has limits too. Render says its free instances aren't for production and can sleep. Netlify's Free plan can pause a site that runs out of its monthly credits.
Sign-in
Cursor doesn't add a sign-in system of its own: your app uses what you set up, like Supabase, Clerk, Auth.js or Firebase. Make sure its allowed redirect and callback addresses name your production address, not a preview or localhost. Sign in, close the app and open it again. Google doesn't allow its sign-in page inside an app's embedded browser, so Google sign-in has to open in the phone's browser and come back. BDK's external sign-in does that hand-off, called from your code; check that your session comes back with it rather than assuming it does. BDK Preview can show the hand-off, but it doesn't prove your store app's Google or Apple sign-in setup.
Links from your emails
On the phone, open a new-account email, a sign-in link, and a password reset. See whether each one opens your app or the phone's browser, and whether the person is still signed in. If those emails should open the installed app, set that up with Branch or ChottuLink before you order the build.
Paid access
If you charge with Stripe Checkout, walk through a real purchase, a cancelled one and the return to the app. Ask Cursor's agent to give paid access after your server receives and checks Stripe's payment confirmation, not because the customer reached a success page. Physical goods and real-world services, including real-world subscriptions like a gym or a meal kit, generally keep your web checkout. Digital things used in the app, like credits or a digital subscription, generally must use Apple's and Google's in-app purchases. That's the stores' rule, not BDK's. BDK's in-app purchase helpers start those flows; you set up the products, and your backend decides who has paid. In BDK Preview, purchases run against BDK's own sample products; your own products work in your own build.
Photos and uploads
Pick a photo, take one with the camera and upload it, on both phones, and try a full-size photo against your upload limits. Uploads still go to your own storage. For a native camera or photo picker, BDK has helpers your code can call.
BDK Preview runs your real site, so what works there is strong evidence. It doesn't prove your store app's sign-in or push setup, or how store review will go, and its purchases use BDK's sample products.
Building a mobile app with Cursor and Expo, and how it differs. Cursor writes code, so it can also write a separate React Native app with Expo. Cursor's own iPhone app is for you, the maker.
What Cursor says
Cursor's docs describe Cursor for iOS as an app for “controlling agents running in the cloud and on your local computer.” They say Android is planned. Opening that companion app starts on Cursor's Premium plan. Premium is for using Cursor on your phone. Your own store app, and the Expo route, work on Cursor's Free plan.
Cursor's pricing lists a Free plan with limited Agent and Chat use, and paid plans that add more AI use.
Why keep your web app
Cursor can write a React Native app with Expo too, and Expo's docs cover building with Cursor. That route is real: Expo's EAS tools build and submit for both stores, and it fits an app you want designed for phones from scratch. If your web app already works, rebuilding its interface as native screens means separate web and mobile screens to build, test and release. Expo can also reuse web components inside a native app, so how much stays separate depends on how you build it. BDK puts the web app you already have in the stores, so you keep one codebase and keep shipping from Cursor.
Expo's own docs list what Expo Go, its preview app, can't test. “The FaceID authentication for iOS is not supported in Expo Go.” For in-app purchases: “Native code is not configurable when using Expo Go.” Expo's docs also say Expo Go can't test remote push notifications, website links that open your installed app, or sign-in that leaves the app and comes back. For those, Expo recommends a test build made for your own app, which you configure and compile. Expo Go does run the camera, QR scanning and its own test links. BDK Preview runs push, Face ID, deep links and sample purchases around your live site, free, on your own phone, before you pay. It uses BDK's keys, BDK-branded links and BDK's sample products, so your own setup still gets tested in your build.
Building iOS on your own computer needs a Mac and Xcode; Expo's cloud builds avoid that and can manage signing for you. With BDK there is no native project to keep at all: BDK builds and signs, and you submit from your own accounts.
Neither route needs a paid Cursor plan. As of October 30, 2026, Cursor's Free plan is $0 and Plus is $8 a month, for more AI use. Expo's Free plan includes store builds and submission in a lower-priority queue; its Starter plan is $19 a month plus usage. So the difference is the work, rather than a Cursor or Expo subscription: neither route needs a paid Cursor plan, and Expo's Free plan includes store builds and submission in a lower-priority queue. Hosting is a cost either way. Vercel's Hobby plan is $0 for personal, non-commercial use, and Pro starts at $20 a month plus usage. BDK is a separate one-time payment for packaging the site you already deployed.
If you change hosts later, the app keeps working: deploy the site to its new home, then point the app at the new address from your BDK dashboard, with no new store submission.
Test, launch and improve with real users on BDK first. Once the app has traction, a fully native version you sign and submit for this same app can ship as an update to the same store listing: same name, same reviews, and your users simply get an update. The Android signing key comes with your BDK build.
Your code, your repository and your hosting stay yours. If you move hosts later, from Vercel to Railway or your own server, point the app at the new address from your BDK dashboard.
What you need.
- Your web app, deployed to a public HTTPS address: a vercel.app, netlify.app, up.railway.app or onrender.com address works, and so does your own domain.
- An Apple Developer account for iOS and a Google Play developer account for Android, in your own name.
- For iOS: create your App Store Connect entry and push key. BDK builds, signs and uploads to TestFlight. You test and submit for review; Apple and Google decide.
- No access to your code, your repository or your hosting account. BDK needs just the address.
- No Mac, no Xcode and no native project to keep. BDK builds and signs the apps.
- A hosting plan that fits your use. Vercel's docs keep its free Hobby plan to personal, non-commercial use, with or without BDK.
- For push notifications, which are on unless you switch them off: your own OneSignal account (the free tier works) and Firebase project. Switching push off or back on is a new build you submit again.
- For other phone features, the free @thebdk/native package, added with npm like any other dependency.
$69 for iOS, $69 for Android, or $99 for both, paid once. Introductory pricing, valid until Thanksgiving. Each purchase includes one build and four banked rebuilds; the rebuilds expire 12 months from payment. Extra rebuilds are $19 and also expire 12 months from payment. Changes to your site never need one. Apple ($99 a year) and Google ($25 once) charge for their own developer accounts.
Prices as of .See pricing
Questions
What does BDK Native do with a Cursor app?
BDK Native turns your web app, built with Cursor and deployed, into real iOS and Android apps for your own App Store and Google Play accounts. The apps load your live site, so you keep building in Cursor and every change you deploy shows up in the app, with no store update. Try it free on your phone first in the BDK Preview app, before you pay anything.
How do I turn my Cursor app into an iOS and Android app?
Deploy it to a public HTTPS address, on Vercel, Netlify, Railway, Render or your own server, and give BDK the production address, not localhost or a protected preview. Try it free in the BDK Preview app on your phone. Ask Cursor's agent to add the free @thebdk/native package for phone features. When it works the way you want, order a build: BDK makes signed iOS and Android apps, and you submit them from your own Apple and Google developer accounts.
Should I build a React Native app with Expo instead?
It's a real option. Cursor can write a React Native app with Expo, Expo's tools build it for both stores, and it fits an app you want designed for phones from scratch. If your web app already works, rebuilding its interface as native screens means separate web and mobile screens to keep; Expo can also reuse some web components, so how much stays separate depends on how you build it. BDK puts the web app you already have in the stores, so you keep one codebase and no native project, and BDK does the build and signing. Expo Go, Expo's preview app, runs the camera, but Expo's docs say it can't test Face ID on iPhone, real in-app purchases, remote push, or sign-in that leaves the app and comes back; a test build made for your own app can, once you set it up and compile it. BDK Preview runs push, Face ID, deep links and sample purchases around your live site, free, on your own phone. Then you pay once.
Will my changes show up in the app?
Yes. The app loads your live site, so every change you deploy to your production address shows up in the installed apps right away, with no store update. The app itself needs a rebuild when you change what is built into it: its icon or name, the three screens, orientation, permission text, push or deep-link settings, or background audio. You also need one for a newer BDK engine, or when Apple or Google require a new build.
Will my Supabase, Clerk, Auth.js or Firebase sign-in work in the app?
Test it in BDK Preview before you buy: sign in, close the app, open it again, then sign out and reset a password. The app opens your live site, so it uses the same backend and the same accounts as your website; BDK doesn't move or copy your users. Check that your sign-in provider's allowed redirects name your production address. Google doesn't allow its sign-in page inside an app's embedded browser, so Google sign-in has to open in the phone's browser and return to the app. BDK's external sign-in does that hand-off, for Apple sign-in too; your app calls it through the free @thebdk/native package, and your session has to come back with it. BDK Preview can show the hand-off, but it doesn't prove your store app's Google or Apple sign-in setup.
Can I keep charging with Stripe in the App Store app?
For physical goods and real-world services, including real-world subscriptions like a gym or a meal kit, yes: your Stripe checkout is the right path, and it's the same page inside the app. Digital things used in the app, like credits or a digital subscription, generally must use Apple's and Google's in-app purchases. That's the stores' rule, not BDK's. BDK's in-app purchase helpers start those flows; you create the products in App Store Connect and Google Play Console, and your backend decides who has paid. In BDK Preview, purchases run against BDK's own sample products; your own products work in your own build.
How is BDK different from other app wrappers?
BDK is a one-time payment: $99 for both platforms, with no subscription. As of October 29, 2026, Natively's Unlimited plan is $384 a year or $49 a month ($699 once for Lifetime), Despia's Hybrid Pack is $498 one-time, and MobiLoud's Growth plan is $679 a month billed annually. Natively Preview excludes in-app purchases, deep links, the camera and audio; Median and Despia have no shared preview app. Despia offers free watermarked builds; on iPhone those need your own Apple developer account and signing. Prices change, so check each company's pricing page.
Will Apple accept my Cursor app?
Nobody can promise that: Apple and Google decide. Apple's guidelines push back on apps that add nothing beyond a website, so give people a reason to install, like push notifications, Face ID or a scanner wired into what your app does. BDK's native features exist for that, and Cursor's agent can wire them into your code.
Last updated
See your own app on your phone, free, before you pay anything.