Jede Änderung dreimal
Neues Herbstbanner
Web
→Deploy< 60s
iOS
→Neubuild→Einreichen
Wartet auf App Review
Android
→Neubuild→Einreichen
Wartet auf App Review
× jede Änderung
Jede native Funktion. Ein SDK.
71 davon. 61 laufen auf einem echten Handy in der Demo-App.
- Push-MitteilungenNeu
- In-App-Käufe
- Native Übergänge
- Modale DialogeNeu
- Anmeldung mit Face ID
- QR-ScannerNeu
- Teilen-MenüNeu
- Mit Apple anmeldenNeu
- Live-StandortNeu
- FotoauswahlNeu
- Deep LinksNeu
- App-BadgeNeu
- Geteilte InhalteNeu
- Anmeldung speichernNeu
- KontakteNeu
- GesundheitsdatenNeu
- Audio-PlayerNeu
- AudioaufnahmeNeu
- Datum und UhrzeitNeu
- Bewertung abfragenNeu
- Tracking-AbfrageNeu
- NFC-ScanNeu
Doku und Live-Demo für jede Funktion.
Typisiert, dokumentiert, identisch auf iOS und Android. Rufe sie aus dem JavaScript auf, das du schon schreibst.
Audio- & Videowiedergabe
Medien mit nativer Steuerung und Audio im Hintergrund abspielen.
Anmeldung speichern
Nutzer mit auf dem Gerät gespeicherten Zugangsdaten über Sitzungen hinweg wiedererkennen.
In-App-Käufe
Digitale Waren in beiden Stores verkaufen. Belege auf dem Server prüfen.
Jeder Deploy aktualisiert jede Installation.
Web, iOS, Android: Alle nutzen deinen letzten Deploy. Auch Nutzer, die die App nie aktualisieren.
Der alte Weg: Jede Änderung dreimal veröffentlichen und auf die Prüfung warten. Mit BDK einmal veröffentlichen.
Ein neues Symbol oder eine native Funktion braucht weiter einen Store-Build.
So sieht App Review dasSieh deiner KI beim Einbinden zu.
Wähle das Tool, mit dem du baust. Das ist die ganze Einbindung: die gelesene Referenz, die geschriebenen Dateien und die Antwort vom Handy.
PreviewCode
SharePublishSende vom Server mit Zugangsdaten aus Umgebungsvariablen eine Push-Mitteilung, die den verlinkten Beitrag öffnet
server/onesignal-push lesen
server/notifications/sendReply.ts+12
Deep Link vom Server mit Zugangsdaten aus der Umgebung senden
Push nur vom Server: nutzt Zugangsdaten aus Umgebungsvariablen und öffnet Beitrag 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});Der ganze Prompt
Binde @thebdk/native in diese App ein, damit Kamera und Face ID funktionieren, wenn die veröffentlichte Seite in BDKs nativer Hülle läuft. Die normale Web-App soll weiter im Browser funktionieren.
Lies zuerst https://docs.thebdk.com/llms-full.txt und die Seite jeder Funktion, die du ergänzt. Nutze nur die dort dokumentierten Helfer, Ereignisnamen und Optionsschlüssel. Erfinde keine API.
Dann:
1. Ergänze das Paket @thebdk/native.
2. Erstelle einen gemeinsamen Client in src/lib/bdk.ts mit einem im Browser sicheren Import:
import { createBdkNative } from "@thebdk/native/browser";
export const bdk = createBdkNative();
3. Nutze für die Funktionen nur typisierte Helfer mit Namensraum: bdk.media.*, bdk.ui.*,
bdk.navigation.*, bdk.iap.*, bdk.auth.*, bdk.location.*, bdk.device.*, bdk.share.*,
bdk.permissions.*.
4. Abonniere mit bdk.on(event, cb) VOR jedem interaktiven Aufruf. Das Ergebnis
kommt als Ereignis, nicht über das zurückgegebene Promise.
5. Im Browser läuft der Aufruf nicht. Er liefert triggered: false. Prüfe
!result.triggered und behalte eine echte Web-Alternative, damit Lovable-Vorschau
und Web-Build weiter funktionieren. Beschreibe den Fall nicht als übersprungen oder not_native.
Warte in der Web-UI nicht auf ein natives Ereignis.
6. Alles aus @thebdk/native/server/* gehört nur ins Backend. Lies Zugangsdaten aus Umgebungsvariablen.
Packe nie Schlüssel oder Server-Imports in den Client-Code.
Behaupte nicht, iOS- oder Android-Apps erstellt, die Seite verpackt, Builds signiert, bei einem Store eingereicht oder natives Verhalten in der Vorschau geprüft zu haben.
Ende mit den geänderten Dateien, der ergänzten Web-Alternative und dieser Übergabe: Veröffentliche diese App unter ihrer URL. Verbinde die URL auf thebdk.com, damit BDK die iOS- und Android-Builds packt und signiert. Teste dann native Funktionen in der von BDK gepackten App.
Läuft in der von BDK gepackten App
Ergänzt Kamera und Face ID. Die Web-Vorschau läuft mit der Web-Alternative weiter.
- Ein gemeinsamer Client —
npm install @thebdk/native, ein Import, alles andere bleibt gleich. - Ergebnisse kommen als Ereignisse. Der Prompt weist den Agenten an, vor dem Aufruf mit
bdk.on(…)zu abonnieren. - Geht auch im Browser. Außerhalb der App werden Aufrufe nicht ausgeführt. Deine Website läuft weiter.
Keine Codebasis? Nichts zu installieren. Verbinde die URL deiner App in der Übersicht. Die Builds sind dieselben.
Maschinenlesbare Referenz: llms.txt. Diese Datei ruft dein Agent ab. So nutzen Agenten es →
Drei Schritte. Kein neuer Stack.
- 1
SDK installieren — oder nicht
Hast du eine Codebasis?
npm install @thebdk/native— eine Abhängigkeit, komplett typisiert. Keine Codebasis? Nichts zu installieren. Dann reicht Schritt 3. - 2
Native Funktionen dort aufrufen, wo du sie willst
Kamera, Biometrie, Käufe, Push aus deinem bestehenden JavaScript. Ein Build, der im Browser-Tab oder als App aus dem App Store läuft.
- 3
Verbinde deine URL. Erhalte Builds für die Stores.
Füge deine URL in der Übersicht ein. BDK erstellt und signiert beide Apps. Danach aktualisiert jeder Deploy jedes Handy.
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."
});Das ist die ganze Einbindung. Vollständige Referenz in der Doku, jede Funktion läuft in der Live-Demo.
Die langen Antworten.
Lehnt Apple sie nicht als umverpackte Website ab?
Apple lehnt Apps ab, die nur eine Website sind. Push, Face ID, Käufe und Teilen machen daraus eine App. Niemand kann eine Freigabe versprechen. Die Live-Demo ist eine von BDK gepackte App, die du selbst beurteilen kannst.
Verstoßen sofortige Updates nicht gegen Store-Regeln?
Nein. Deine App zeigt deine Live-Seite. Deine Website zu veröffentlichen ist der normale Weg für webbasierte Apps, kein Trick zum Einschleusen von Code. Die Store-Prüfung gilt, wenn sich die native Seite ändert: Symbol, Berechtigungen oder ein Upgrade der Laufzeitumgebung. Dafür liefert BDK einen frisch signierten Build zum Einreichen.
Was genau ist BDK?
Eine native Laufzeitumgebung für iOS und Android, die deine Live-Web-App im Vollbild in einer echten App aus dem Store zeigt. Dazu kommt das typisierte JavaScript-SDK @thebdk/native. Es verbindet deinen Code mit dem Gerät: Kamera, Biometrie, Käufe, Push. BDK packt und signiert die fertige App für den Store. Du reichst sie mit Anleitung Schritt für Schritt über deine eigenen Entwicklerkonten ein. Deine Web-App bleibt eine normale Web-App, die du selbst hostest.
Muss ich meine Web-App ändern?
Nein. Sie läuft wie bisher. Ergänze @thebdk/native nur dort, wo du native Funktionen möchtest. Alles andere bleibt gleich, und derselbe Build liefert weiter deine normale Website.
Was ist anders als bei einer PWA oder Capacitor?
Eine PWA kann nicht im App Store stehen oder über In-App-Käufe verkaufen. Capacitor gibt dir native Projekte, für die du verantwortlich bist. Erstellen, Signieren und Neubuilds bleiben dauerhaft deine Aufgabe. BDK betreut die Laufzeitumgebung: Packen, Signieren und Plattformänderungen übernimmt BDK.