Krypton is a toolkit developers use to build a real mobile app — a store app, a customer app, a brand app — on top of Prebit, the same way Boron is the toolkit for building a custom website. Nobody has to rebuild login, cart, checkout, or product browsing from scratch.
A merchant evaluating Prebit's mobile story can see the real plan today — most importantly, that a Krypton app shows the exact same products, prices, and stock as the web storefront, not a separate mobile-only system that could drift out of sync.
The plan already lays out what's ready to build today and what's coming next, in real detail. That's what lets a team start building against Krypton with confidence instead of guessing at a roadmap slide.
A store app's product, cart, and checkout screens are a customer-facing surface, exactly like a website — so Krypton connects to the exact same store data Boron already uses, rather than a completely different, admin-facing system built for something else entirely.
Rather than guess at shared code between web and mobile before either is fully proven, Krypton is being built the same deliberate way Boron was: directly against the platform's real data, tested on its own, before anything gets shared between the two.
Every part of Krypton's plan was checked against what the platform can actually support today. That's what makes the rollout sequence below a real sequence, not a wishlist.
Krypton reads from the exact same store data as the website, but the code underneath is built the way a real mobile app should be built, not a copy-paste of the web version.
Merchant impact: A Krypton mobile app shows the same products, prices, and stock as the web storefront, because both read from the same backend.
Developer impact: Krypton wraps the identical public Storefront API Boron uses. Boron's Server Components become TanStack Query hooks (`useProducts`, `useProduct`) since React Native has no server runtime to lean on; Server Actions become hooks calling the client directly. A developer who already understands Boron's data model has a real head start here.
Example: The same `getProduct(slug)` endpoint Boron's Server Component calls directly is the endpoint the Krypton `useProduct(id)` hook calls through TanStack Query.
Connecting a Krypton app to a specific store is handled the way mobile apps are actually built, not a web pattern awkwardly forced onto a phone.
Merchant impact: Store configuration stays simple and correct per store, regardless of platform.
Developer impact: Next.js inlines `NEXT_PUBLIC_*` env vars at build time, which is how Boron reads config with no Context Provider needed. React Native has no build-time env inlining, so Krypton uses a root `<PrebitProvider storeId apiBase ... />` instead — a deliberate, documented pattern purpose-built for React Native.
Example: Switching a Krypton app between a staging store and a production store means changing `<PrebitProvider storeId="..." />` props, matching how a mobile app is expected to configure itself at runtime.
Paying on a Krypton app opens a proper in-app browser for the payment step and brings the shopper right back into the app afterward — built the way a phone actually expects checkout to work, not a web popup squeezed onto a small screen.
Merchant impact: A Krypton checkout goes through the same checkout system web orders do, not a parallel mobile-only payment path.
Developer impact: Boron's web checkout uses an iframe overlay with `postMessage` and an escape-to-top-level step before a payment provider runs. A mobile OS has no iframe concept, so Krypton uses `expo-web-browser`'s in-app browser plus a deep-link return instead — same cart-token contract, same underlying checkout system, mechanics purpose-built for mobile.
Example: A shopper taps checkout in the app, an in-app browser opens for payment, and a deep link returns them to the app on success, failure, or cancellation.
Product browsing, search, and cart can be built on Krypton today. Customer login, order history, and wishlists follow shortly after, on a clear, known timeline — not an open-ended promise.
Merchant impact: A team can start on a Krypton-based product catalog and cart experience now, with a clear, known path to full account and order history soon after.
Developer impact: The full hook surface is `useAuth`, `useProducts`, `useProduct`, `useCart`, `useCheckout`, `useWishlist`, `useSearch`, `useOrders`, `useCustomer`, `useAnalytics`. `useProducts`, `useCart`, and `useSearch` build against the real Storefront API today; `useAuth`, `useCustomer`, `useOrders`, and `useWishlist` follow as mobile customer accounts roll out.
Example: A team builds a browse-and-add-to-cart mobile experience first, with full account and order history following on the same rollout timeline as mobile accounts.
A Krypton launch won't start from an empty project. Ready-made starter apps for common store types (fashion, electronics, grocery, cosmetics, single-brand) are part of the plan, the same way Boron already has one for the web.
Merchant impact: A Krypton launch won't start from a blank project — a real starter app matching the merchant's category is planned, the same way a web starter store exists for Boron today.
Developer impact: Krypton follows the same "framework first, templates demonstrate" shape Boron already uses for `prebit-template-store`: Home → Collections → Search → Product → Cart → Checkout → Profile → Orders → Wishlist, with starter apps demonstrating the framework as it rolls out.
Example: A fashion brand's mobile team clones a Fashion Store starter instead of assembling a product-browsing flow from a blank Expo Router project.
Every layer feeds the next: Krypton sits inside this chain rather than bypassing Commerce Engine's data contracts.
Krypton's own small Storefront API client is conceptually parallel to Boron's, purpose-built for the mobile runtime.
TanStack Query plays the role client-side that Next.js's `fetch` cache-tags play for Boron's server-side reads — the hook layer's actual caching and revalidation engine.
Where Boron mirrors the cart token into `localStorage` plus a same-domain cookie, Krypton uses `expo-secure-store` — the mobile-native equivalent, purpose-built for a runtime with no browser storage model.
`expo-web-browser` plus a deep-link return is Krypton's native equivalent of Boron's iframe-overlay-plus-postMessage pattern.
A merchant can see today exactly which mobile commerce capabilities (browsing, cart) are ready first and which (full account/order history) follow next, with specifics instead of a generic "mobile is coming."
Because Krypton wraps the same Storefront API as Boron and the web storefront, a Krypton mobile app never shows different stock, pricing, or catalog data than the web experience.
The category-specific starter apps mean a Krypton launch gets a real head start, the same way Boron's `prebit-template-store` gives web launches one today.
Krypton checkout routes through the same `prebit-checkout` system as web, not a separate mobile-only payment integration to trust independently.
Ten named hooks with individually documented rollout status make Krypton's real scope legible, rather than a vague "mobile SDK" promise.
Package name `@prebit/krypton` (scoped, matching `@prebit/boron`/`@prebit/sdk`), scaffolder `create-krypton-app` (unscoped, matching every scaffolder's own muscle-memory convention), and no shared picker with `create-prebit-app`/`create-boron-app` — all decided in advance, for the same reasons Boron's own scaffolding stayed fully separate.
Config via provider instead of env vars, TanStack Query instead of Next.js fetch cache tags, `expo-secure-store` instead of localStorage+cookie, in-app browser instead of iframe — each difference from Boron is a deliberate runtime decision, purpose-built for mobile.
A developer picking this up doesn't have to guess which hooks are ready first — the architecture doc states it endpoint by endpoint, and this page mirrors that same clarity.
A brand wants to know whether to build with Krypton or invest in a native app independently.
Outcome: A concrete answer: Krypton's architecture shares Boron's backend, so building on it now avoids a second integration effort later.
An agency is asked whether Prebit supports native mobile apps.
Outcome: A clear answer grounded in this page: here's the real rollout plan and what ships first.
An engineer wants to judge whether Krypton's implementation actually reuses Boron's validated backend contracts or reinvents them.
Outcome: Confidence that it's the former — Krypton wraps the same Storefront API, the same architectural decision Boron already proved out.
A CTO is comparing Prebit's mobile story against a competitor's native SDK.
Outcome: A clear, specific rollout sequence for realistic timeline planning, not a vague promise.
Krypton wraps endpoint contracts already validated in production by Boron's own Storefront API client, rather than a fresh, unproven integration.
Krypton leans on TanStack Query's own caching and background-refetch behavior client-side, the mobile equivalent of what cache tags do for Boron server-side.
The stack uses Expo's managed workflow with EAS Build/Update for over-the-air updates — shipping fixes without a full app-store review cycle.
Native mobile apps aren't indexed the way web pages are, so traditional SEO advantages don't apply here the way they do for Boron or the Bit Theme Engine.
Krypton's deep-link checkout return mechanism is relevant to app-store deep-linking and universal-link setup, which affects discoverability and re-engagement, if not classic SEO.
Because a Krypton app reads the same catalog as the web storefront, product information a customer sees in-app matches what search engines index for the web version.
A direct, factual read on where each platform is strong, and where Prebit takes a different approach.
Directional and factual. Validate against your own catalog complexity, channel strategy, and budget before deciding.
Plain answers to what merchants, agencies, and developers actually ask.
Start free. No credit card required. Explore the rest of the Prebit platform once you're in.