Chaque changement, trois fois
× chaque changement
71 fonctions, dont 61 sur un vrai téléphone dans l’app de démo.
Typées, documentées, identiques sur iOS et Android. Appelez-les depuis votre JavaScript habituel.
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.
Autorisations à l’usage
Demandez et vérifiez les autorisations natives sans gêner l’utilisateur.
Interface native et retour tactile
Bannières, écrans de chargement et éléments natifs depuis JavaScript.
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.
× chaque changement
Une nouvelle icône ou fonction native exige toujours un build pour le store.
Ce qu’App Review examineChoisissez 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.
Envoyez une notification push côté serveur qui ouvre le post lié, avec les identifiants issus des variables d’environnement
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.
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});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.Là où votre client s’attendait à arriver.
DisponibleDans l’app créée par BDK
Ajoute la caméra et Face ID. L’aperçu web fonctionne toujours avec la solution de repli.
npm install @thebdk/native, un import, le reste ne change pas. bdk.on(…) avant l’appel. Pas de code source ? Rien à installer. Reliez l’URL de votre app dans BDK Native : les builds sont les mêmes.
Référence lisible par machine : llms.txt, le fichier récupéré par votre agent. Usage par les agents →
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.
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.
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.
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.
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.
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.
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.
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.
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.