Кінець BubbleGo і npm у plugin editor (beta): що змінити в mobile roadmap
22 вересня 2026 року Bubble відкрив публічну бету редактора мобільних плагінів із підтримкою довільних npm-пакетів та остаточно закрив BubbleGo. Розбираємо, як нетехнічним фаундерам і вайбкодерам переписати roadmap мобільного MVP, щоб не зірвати запуск і не витратити бюджет на порожні обіцянки.
22 вересня 2026 року в екосистемі мобільної розробки Bubble відбувся тектонічний зсув. Команда платформи офіційно оголосила про дві пов'язані новини: Mobile Plugin Editor перейшов у статус Public Beta з підтримкою сторонніх npm-пакетів, а тестовий застосунок BubbleGo було остаточно знято з підтримки (deprecated) через політику Apple App Store щодо preview-додатків. Схожий розбір: Workflow engine alpha: «кінець вересня».
Для нетехнічних фаундерів, стартаперів та вайбкодерів, які збирають мобільний MVP, це змінює правила гри. Раніше типовий шлях складався зі швидкого прототипування та миттєвого показу першим клієнтам чи інвесторам через сканування QR-коду в BubbleGo. Тепер цей пайплайн зламано. Водночас відкриття npm дає змогу реалізувати будь-яку нативну інтеграцію, але накладає нові вимоги до тестування, бюджетів і термінів.
Якщо ви плануєте запуск мобільного продукту до кінця місяця, ось як потрібно переглянути свій mobile roadmap. Поруч із цим: ~700 мобільних плагінів Bubble і. Поруч із цим: Bubble випустив редактор мобільних плагінів.
1. Що викинути з обіцянок клієнтам та інвесторам уже зараз
- «Покажемо прототип на вашому телефоні за 5 хвилин через BubbleGo»
BubbleGo більше не оновлюється і не отримуватиме багфіксів чи підтримки нових можливостей мобільного рушія Bubble. Будь-які демонстрації на BubbleGo створюють оманливе враження і призведуть до багів, яких немає в реальному коді (або навпаки — приховають критичні збої). - «Тестування сторонніх плагінів у звичайному браузері (Web Preview)»
Web preview залишається найшвидшим інструментом для перевірки базової логіки та верстки, але воно технічно не здатне завантажувати сторонні нативні бібліотеки з npm. - «Повне нативне тестування без витрат на акаунти розробника»
Повноцінний тест камери, push-повідомлень, апаратних сенсорів чи deep links тепер можливий виключно через Dev Builds (TestFlight в Apple та Google Play Internal Testing). Для цього необхідні платні плани Bubble та платні акаунти в Apple App Store Connect ($99/рік) і Google Play Console ($25 одноразово). Схожий розбір: Bubble Ambassadors: як нетехнічному засновнику.
2. Нова матриця перевірки: як тестувати мобільний MVP
Щоб не витрачати тижні на очікування збірок, розбийте процес верифікації на три рівні відповідно до офіційної матриці прев'ю Bubble:
- Web Preview (Швидка ітерація):
Найвища швидкість. Підходить для перевірки переходів між екранами, роботи бази даних, відображення тексту та стандартних елементів. Не підтримує npm-плагіни з нативним кодом. - Simulated Device (Хмарна симуляція в браузері):
Запускає реальну збірку всередині браузера. Дозволяє перевірити плагіни з npm, але має обмеження: не працюють камера, push-повідомлення та реальні сенсори. До того ж зміна плагінів чи оновлення бібліотек вимагають запуску процедури Rebuild. - Dev Builds (Повне тестування на реальному залізі):
Єдиний достовірний спосіб перевірити push-сповіщення, сканування камерою чи біометрію перед подачею в App Store. Будь-яке додавання або зміна npm-бібліотеки переводить білд у статус «Outdated» і вимагає повної перегенерації білда.
3. Сегментація Roadmap: план запуску без зриву дедлайнів
Перебудуйте свій беклог і графік релізів за трьома чіткими категоріями:
Рівень A. Швидкий MVP на стандартному стеку (Готово до релізу)
- Що входить: Інтерфейс, внутрішня логіка Bubble, офіційні або перевірені плагіни з маркетплейсу без додаткових нативних залежностей.
- Як показувати: Web Preview або Simulated Device.
- Терміни: Дні, а не тижні. Ідеально для вайбкодингу та швидкої перевірки продуктової гіпотези з першими користувачами.
Рівень B. Інтеграції через npm у Plugin Editor (Public Beta)
- Що входить: Кастомні npm-бібліотеки, додані через поле «Additional libraries» на вкладці Shared у редакторі плагінів.
- Умови та ризики: Функція перебуває в бета-версії. Офіційна документація місцями відстає, нативні жести (drag/gesture) проходять внутрішнє доопрацювання розробниками Bubble, а якщо версія вашого npm-пакета конфліктує з версією, яку використовує сам Bubble, пріоритет матиме версія платформи.
- Робочий процес: Не додавайте npm-пакети по одному щодня. Формуйте список потрібних бібліотек пакетом, щоб мінімізувати цикли перезбірок.
Рівень C. Нативна валідація та фінальний реліз (Dev Build Only)
- Що входить: Push-повідомлення, камера, GPS, біометрична автентифікація, робота з реальними bundle ID.
- Умови: Закладіть у бюджет і графік налаштування Apple Developer та Google Play ще до завершення розробки інтерфейсу. Перший Dev Build повинен збиратися не в ніч перед релізом, а мінімум за 7–10 днів до запланованого показу інвесторам.
Чекліст для фаундера перед стартом
- Оновіть клієнтські домовленості: приберіть згадки BubbleGo і закладіть час на генерацію TestFlight-збірок.
- Підготуйте акаунти заздалегідь: реєстрація в Apple Developer може зайняти кілька днів через перевірку документів.
- Враховуйте вартість підтримки: зміна нативних дозволів, оновлення плагіна чи реліз нової версії мобільного рушія Bubble вимагають нової генерації білда та повторної відправки застосунку на модерацію в магазини.
| Пункт | Що зробити | На що звернути увагу |
|---|---|---|
| Оновіть клієнтські домовленості | Прибрати згадки BubbleGo; закласти час на генерацію TestFlight-збірок | — |
| Підготуйте акаунти заздалегідь | Реєстрація в Apple Developer | Може зайняти кілька днів через перевірку документів |
| Враховуйте вартість підтримки | Зміни нативних дозволів, оновлення плагіна, реліз нової версії мобільного рушія Bubble | Потрібні нова генерація білда та повторна відправка застосунку на модерацію в магазини |
