BDK Native rebuilt: preview + mobile для Bubble і vibe-coded web. Нативний шлях, але не runtime Bubble Mobile і не Agent 2

Ви запустили MVP на Bubble або навайбкодили веб-застосунок у Lovable, Replit чи на Next.js. Перше, чого хочеться, — дати його в руки на телефоні: клієнтам, інвесторам, першим користувачам, щоб зібрати фідбек. І тут починається плутанина між швидким показом робочого прототипу і повноцінною нативною розробкою. Поруч із цим: Bubble Innovation Lab: як Reverse.

У 2026 році BDK Native змінив позиціонування. Раніше це була суто Bubble-обгортка, тепер це білд-сервіс для будь-якого браузерного веб-застосунку. Я розкладу, чим є оновлений інструмент, що він дає для перевірки гіпотез і де його жорсткі архітектурні межі.

Що таке rebuilt BDK Native: модель двох застосунків

Головна зміна в оновленому BDK — ролі розділені між двома безкоштовними мобільними застосунками:

1. BDK Preview — лише для перегляду й демонстрації. Він відкриває опублікований живий URL вашого веб-застосунку всередині нативної оболонки на смартфоні. Безкоштовно тестуєте поведінку оболонки, показуєте прототип на зустрічі або віддаєте першим користувачам.
2. BDK Native mobile app разом із веб-порталом thebdk.com — це панель керування. Тут ви створюєте проєкти, надсилаєте інвайти, налаштовуєте превʼю і замовляєте платні фінальні збірки для магазинів застосунків.

Для MVP це зручно. Щоб побачити, як продукт поводиться на реальному екрані, не треба платити за білд і чекати модерації App Store та Google Play.

Чим BDK Native НЕ є

У 2026 році в екосистемі Bubble зʼявилися три різні речі, і їх легко сплутати:

• Це не Bubble Agent 2. Agent 2 — оновлення AI-агента від самої команди Bubble. Його показали на жовтневому founder AMA 2026 року разом із вкладкою preview в редакторі. BDK — сторонній сервіс мобільної оболонки, а не AI, який генерує застосунок.
• Це не runtime Bubble Mobile. Власний нативний mobile builder від Bubble працює на окремих mobile views і спільному бекенді, без веб-контейнера. BDK лишається web wrapper: він завантажує браузерний веб-шар у нативний контейнер.
• Це не реліз у магазин. Превʼю в BDK Preview — ще не готовий застосунок в App Store. Схожий розбір: Universal Import (бета): вайб-код із.

Архітектура: live URL і миттєві оновлення

Технічно BDK — нативна оболонка (native shell), яка відкриває ваш живий URL. Нативні можливості пристрою веб-шар викликає через плагін Bubble або пакет @thebdk/native.

У цієї схеми дві сторони:

• Плюс для тестування гіпотез: веб-деплой одразу підтягується на пристрої. Без нової збірки бінарника і без нової модерації.
• Операційний ризик (blast radius): будь-який баг чи невдалий реліз у вебі миттєво ламає встановлений мобільний застосунок у всіх користувачів.

Що підготувати перед запуском BDK Preview

Щоб відкрити Bubble або vibe-coded проєкт у BDK Preview, мінімум такий:

• Опублікований живий URL застосунку (app URL) і робочий домен. Неопубліковане посилання preview не відкриє.
• Тестові облікові дані (credentials), якщо застосунок закритий паролем або авторизацією.
• Дизайн екрана завантаження (loading-screen), щоб під час першого рендеру користувач не дивився на порожнє біле вікно.

Чесні обмеження превʼю і чекліст готовності

Перед показом інвесторам памʼятайте, що це тестове середовище:

• Власної кастомної іконки на екрані телефона в BDK Preview не буде.
• Push-сповіщення, диплінки (Branch/ChottuLink) і In-App Purchases у превʼю працюють через тестову інфраструктуру або з брендингом BDK. Вони показують, що логіка викликається, але це не фінальне підтвердження для продакшену.

Можливість	У BDK Preview	Не для
Кастомна іконка на екрані телефона	Не буде власної кастомної іконки	Фінальний вигляд на пристрої користувача
Push-сповіщення	Тестова інфраструктура або брендинг BDK; показує, що логіка викликається	Фінальне підтвердження для продакшену
Диплінки (Branch / ChottuLink)	Тестова інфраструктура або брендинг BDK; показує, що логіка викликається	Фінальне підтвердження для продакшену
In-App Purchases	Тестова інфраструктура або брендинг BDK; показує, що логіка викликається	Фінальне підтвердження для продакшену

Офіційний чекліст готовності до обгортки (agent readiness checklist) вимагає вручну перевірити такі ризики:

1. Авторизація OAuth: чи проходить вхід через соцмережі всередині embedded webview і чи не блокують його провайдери.
2. Видалення акаунту: чи є кнопка і повний сценарій видалення облікового запису. Цього вимагають гайдлайни магазинів.
3. Safe areas і вʼюпорт: чи адаптований інтерфейс під «чубчики», вирізи і системні панелі жестів.
4. Збереження сесій: чи не злітає авторизація після згортання і повторного відкриття оболонки.
5. Оплата цифрових товарів: чи не порушує веб-чекаут цифрових товарів правила платформ.

Більшість цих пунктів кодом у веб-редакторі не перевіриш. Їх треба пройти руками на фізичному смартфоні в BDK Preview.

Що обрати для MVP: BDK чи рідний Bubble Mobile?

Якщо у вас уже є робочий веб-інтерфейс на Bubble або vibe-coded прототип, а задача — за кілька днів перевірити попит, показати екран на телефоні й подивитися на реакцію перших клієнтів, я б брав BDK Preview. Це найкоротший шлях до рук користувача без другого застосунку з нуля. Про це окремо: Expo SDK 57 у Bubble.

Якщо ж ви вже будуєте проєкт у рідному mobile builder від Bubble з окремими mobile views, повертатися на веб-обгортку немає сенсу. Рідний білдер дає повноцінний мобільний runtime, а BDK пакує вже готовий браузерний веб.