Toutes les fonctions natives. Un SDK.

71 fonctions, dont 61 sur un vrai téléphone dans l’app de démo.

  • Notifications pushNouveau
  • Achats intégrés
  • Transitions natives
  • Panneaux modauxNouveau
  • Connexion Face ID
  • Scanner QRNouveau
  • Menu de partageNouveau
  • Connexion avec AppleNouveau
  • Position en directNouveau
  • Choix de photosNouveau
  • Liens profondsNouveau
  • Pastille d’appNouveau
  • Partages reçusNouveau
  • Accès mémoriséNouveau
  • ContactsNouveau
  • Données santéNouveau
  • Lecteur audioNouveau
  • Enregistreur vocalNouveau
  • Choix de la date et de l’heureNouveau
  • Demande de noteNouveau
  • Demande de suiviNouveau
  • Scan NFCNouveau

Des docs et une démo live pour chaque fonction.

Typées, documentées, identiques sur iOS et Android. Appelez-les depuis votre JavaScript habituel.

Caméra et médias

Prenez des photos, choisissez dans la galerie, enregistrez un audio.

Lecture audio et vidéo

Lisez les médias avec les commandes natives et l’audio en arrière-plan.

Connexion biométrique

Connexion Face ID et empreinte avec votre authentification actuelle.

Accès mémorisé

Reconnaissez les utilisateurs d’une session à l’autre grâce aux identifiants stockés sur l’appareil.

Achats intégrés

Vendez des biens numériques sur les deux stores. Vérifiez les reçus côté serveur.

Notifications push

Notifications push ciblées depuis votre backend via OneSignal.

Géolocalisation

Lisez la position de l’appareil avec la précision native.

Autorisations à l’usage

Demandez et vérifiez les autorisations natives sans gêner l’utilisateur.

Liens profonds

Des liens qui ouvrent l’app, ou le store puis l’app.

Partage natif

Le menu de partage du système : texte, liens, images, fichiers.

Interface native et retour tactile

Bannières, écrans de chargement et éléments natifs depuis JavaScript.

Appareil, cycle de vie

Plateforme, version de l’app, événements de passage au premier plan et en arrière-plan.

Chaque déploiement met à jour chaque installation.

Web, iOS, Android : tous les utilisateurs profitent de votre dernier déploiement, même ceux qui ne mettent jamais l’app à jour.

Avant : publier chaque changement trois fois et attendre l’examen. Avec BDK, déployez une fois.

Une nouvelle icône ou fonction native exige toujours un build pour le store.

Ce qu’App Review examine

Voyez votre IA faire l’intégration.

Choisissez l’outil avec lequel vous créez. Voici toute l’intégration : la référence lue, les fichiers écrits, le téléphone qui répond.

acme-storefront
PreviewCode
Publish

Envoyez une notification push côté serveur qui ouvre le post lié, avec les identifiants issus des variables d’environnement

Lire server/onesignal-push
server/notifications/sendReply.ts+12

Envoyer le lien profond depuis le serveur avec les identifiants issus des variables d’environnement

La notification push, envoyée uniquement côté serveur, utilise les identifiants issus des variables d’environnement et ouvre le 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});
La demande complète
Intégrez @thebdk/native dans cette app pour que la caméra et Face ID fonctionnent quand le site déployé tourne dans l’enveloppe native BDK, tout en gardant l’app web fonctionnelle dans un navigateur.

Lisez d’abord https://docs.thebdk.com/llms-full.txt et la page de chaque fonction que vous ajoutez. Utilisez uniquement les noms de helpers, d’événements et de clés d’options documentés ici. N’inventez pas d’API.

Ensuite :
1. Ajoutez le package @thebdk/native.
2. Créez un seul client partagé dans src/lib/bdk.ts avec un import compatible navigateur :
   import { createBdkNative } from "@thebdk/native/browser";
   export const bdk = createBdkNative();
3. Créez les fonctions uniquement avec les helpers typés, par espace de noms : bdk.media.*, bdk.ui.*,
   bdk.navigation.*, bdk.iap.*, bdk.auth.*, bdk.location.*, bdk.device.*, bdk.share.*,
   bdk.permissions.*.
4. Abonnez-vous avec bdk.on(event, cb) AVANT tout appel interactif : le résultat
   arrive par événement, pas par la promesse renvoyée.
5. Dans un navigateur, l’appel ne s’exécute pas et se résout avec triggered: false. Faites un branchement sur
   !result.triggered et gardez une vraie solution web de repli pour que l’aperçu Lovable et le build
   web continuent de fonctionner. Ne décrivez pas ce cas comme « skipped » ou not_native.
   N’attendez pas d’événement natif dans l’interface web.
6. Tout ce qui vient de @thebdk/native/server/* est réservé au backend. Lisez les identifiants dans les variables
   d’environnement. Ne mettez jamais de clés ni d’imports serveur dans le code client.

Ne prétendez pas avoir créé des apps iOS ou Android, enveloppé le site, signé des builds, soumis à un store ou vérifié le comportement natif dans l’aperçu.

Terminez par les fichiers modifiés, la solution web de repli ajoutée et ces étapes restantes : publier cette app à son URL, relier cette URL sur thebdk.com pour que BDK empaquette et signe les builds iOS et Android, puis tester les fonctions natives dans l’app créée par BDK.

Dans l’app créée par BDK

Ajoute la caméra et Face ID. L’aperçu web fonctionne toujours avec la solution de repli.

  • Un seul client partagé : npm install @thebdk/native, un import, le reste ne change pas.
  • Les résultats arrivent par événement. La demande indique à l’agent de s’abonner avec bdk.on(…) avant l’appel.
  • Fonctionne aussi dans un navigateur. Hors de l’app, les appels ne s’exécutent pas, votre site reste donc fonctionnel.

Pas de code source ? Rien à installer. Reliez l’URL de votre app dans BDK Native : les builds sont les mêmes.

Créer votre app

Référence lisible par machine : llms.txt, le fichier récupéré par votre agent. Usage par les agents →

Trois étapes. Pas de nouvel outil.

  1. 1

    Installez le SDK, ou pas

    Du code source ? npm install @thebdk/native : une dépendance entièrement typée. Pas de code source ? Rien à installer. L’étape 3 suffit.

  2. 2

    Appelez les fonctions natives où vous voulez

    Caméra, biométrie, achats, notifications push : depuis votre JavaScript existant. Un build qui fonctionne dans un onglet ou installé via l’App Store.

  3. 3

    Reliez votre URL. Obtenez des builds prêts pour les stores.

    Collez votre URL dans BDK Native. BDK crée et signe les deux apps. Ensuite, chaque déploiement met à jour chaque télé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."
});

Voilà toute l’intégration. Référence complète dans les docs, chaque fonction testable dans la démo live.

Réponses détaillées.

Apple ne va-t-il pas la refuser comme simple site encapsulé ?

Apple refuse les apps qui ne sont qu’un site web. Notifications push, Face ID, achats et partage en font une app. Personne ne peut promettre l’approbation. La démo live est une app créée par BDK : jugez par vous-même.

Les mises à jour instantanées ne sont-elles pas contraires aux règles des stores ?

Non. Votre app affiche votre site en ligne. Déployer le site est le fonctionnement normal d’une app web, pas une astuce d’injection de code. L’examen du store s’applique aux changements natifs (icône, droits ou mise à jour du moteur). BDK vous livre alors un nouveau build signé à soumettre.

Qu’est-ce que BDK au juste ?

Un moteur natif iOS et Android qui affiche votre app web en ligne en plein écran dans un vrai binaire distribué sur les stores. Avec un SDK JavaScript typé, @thebdk/native, il relie votre code à l’appareil : caméra, biométrie, achats, notifications push. BDK crée et signe le binaire prêt pour les stores. Vous le soumettez depuis vos comptes développeur, avec un guide pas à pas. Votre app web reste une app web standard, hébergée par vous.

Faut-il modifier mon app web ?

Non. Elle fonctionne telle quelle. Ajoutez @thebdk/native seulement pour les fonctions natives voulues. Le reste ne change pas et le même build sert toujours votre site habituel.

Quelle différence avec une PWA ou Capacitor ?

Une PWA ne peut pas être sur l’App Store ni vendre par achat intégré. Capacitor vous confie des projets natifs : les builds, la signature et les rebuilds restent toujours à votre charge. Le moteur BDK est géré : BDK s’occupe de créer les apps, de les signer et de suivre les évolutions des plateformes.

Tout cela, dans votre app.

Créer votre app Lire les docs