Аутідж BubbleGo: статус, помилки reinstall і депрекейт рушія

Ситуація така: на status.bubble.io все зелене, а BubbleGo на телефоні крутиться в лупі оновлення. Для соло-фаундера чи творця без технічного бекграунду швидкість — головна перевага. Ви збираєте мобільний додаток у Bubble, накладаєте логіку, перевіряєте гіпотези вайбкодінгом і хочете якнайшвидше взяти телефон у руки, щоб показати продукт першим користувачам або потенційним ангелам. Схожий розбір: Інцидент workflows 23 вер.: мінімальний.

Тому раптовий збій мобільного прев'ю виглядає як катастрофа. Здається, що впав увесь стартап, база даних або бекенд. Насправді з BubbleGo треба розбиратися тверезо, як з інженерною задачею, без паніки.

Щоб не витрачати час на марні перезавантаження і не ухвалювати рішень у поспіху, я розділяю три речі, які зазвичай злипаються в один клубок:

Офіційне оголошення про депрекейт BubbleGo — кінець життєвого циклу як каналу попереднього перегляду.
Локальний сервісний інцидент BubbleGo, зафіксований на форумі у жовтні 2025 року.
Як влаштований моніторинг на status.bubble.io і чому «зелений» індикатор не означає, що застосунок запуститься на вашому девайсі. Схожий розбір: Workflow engine alpha: «кінець вересня».

1. Що реально зламалося під час інциденту (і що залишилося неушкодженим)

Коли представники Bubble підтвердили на форумі падіння BubbleGo, вони одразу окреслили радіус ураження:

Редактор Bubble (Editor): працював у штатному режимі.
Веб-прев'ю (Web Preview): працювало без змін.
Живі застосунки (Live Production Apps): збій їх не зачепив.

Лягло тільки клієнтське застосування BubbleGo, через яке розробники запускають нативне прев'ю на телефонах.

Для нетехнічного засновника це головне: ваша база даних, бізнес-логіка, запущені веб-додатки та користувачі не постраждали. Проблема сиділа лише в каналі попереднього перегляду.

2. Чому status ≠ reinstall: анатомія когортного розриву

Багато білдерів побачили картину, яка збиває з пантелику. Офіційна сторінка status.bubble.io перевела компонент BubbleGo у стан «Resolved» (зелений). А телефон при спробі відкрити або перевстановити застосунок видавав помилки:

повідомлення «needs an update»;
нескінченний цикл оновлення («this page has been updated»);
неможливість пройти авторизацію або завантажити екран прев'ю.

Причина розбіжності проста. Компонент BubbleGo на status.bubble.io відстежує стан серверної інфраструктури та API платформи. Він не бачить клієнтського стану кожного смартфона і ланцюжка доставки через TestFlight/App Store.

Представники Bubble (зокрема Nick Carroll) згодом пояснили: після відновлення бекенду застосунок запрацював у тих, хто вже мав його встановленим і відкритим. А когорта, яка ставила застосунок з нуля або робила свіжий reinstall під час інциденту чи одразу після нього, далі впиралася в помилки кешу, бутстрапу та авторизації. Моніторинг бачив, що сервери знову відповідають. Перевстановлення на клієнті при цьому залишалося заблокованим.

3. Фактор депрекейту: оновлень клієнта більше не буде

Найбільший ризик для соло-стеку — дата 22 вересня 2026 року. Того дня Bubble офіційно оголосив депрекейт BubbleGo. Причина — політика Apple App Store щодо прев'ю-застосунків. Bubble більше не може відправляти в магазини оновлення та виправлення помилок для BubbleGo.

Що це означає для фаундера:

BubbleGo не видаляють із маркетів примусово, і поточні інсталяції формально відкриваються. Але клієнт заморожений назавжди.
Будь-який наступний баг чи розсинхрон між новими фічами рушія Bubble і старим клієнтом не виправлять оновленням у TestFlight, як це робили раніше.
BubbleGo офіційно не підтримує тестування пуш-повідомлень і плагінів, яким потрібні сторонні нативні бібліотеки. Поруч із цим: Bubble випустив редактор мобільних плагінів.

Я б уже не покладався на BubbleGo як на надійний інструмент перевірки MVP. Це прямий технічний ризик для графіка запуску.

4. Практичний чеклист: що робити, коли статус зелений, а прев'ю лежить

Якщо ви тестуєте мобільну гіпотезу і BubbleGo показує білий екран або циклічно рестартує, я б діяв так:

Крок 1. Перевірте реальний периметр збою

Відкрийте браузер на десктопі. Запустіть редактор і стандартне прев'ю сторінки. Якщо все працює, ваш додаток здоровий, а проблема тільки в клієнті BubbleGo.

Крок 2. Оцініть стан пристрою

Ви щойно видалили й перевстановили застосунок? Тоді ви в когорті клієнтського збою. Швидкі локальні дії: примусове закриття (force-quit), очищення, перевстановлення TestFlight на iOS. Але чекати свіжого білда від Bubble вже немає сенсу.

Крок 3. Перейдіть на офіційні підтримувані альтернативи

Bubble дає два легітимні шляхи для мобільного тестування:

Симулятор пристрою у браузері (Simulated Device):
- Доступний прямо в редакторі, безкоштовно.
- Добре підходить для перевірки адаптивності, UX-флоу та візуальної поведінки більшості елементів і плагінів.
- Найшвидший спосіб отримати фідбек без затримок.
Власні dev builds (Development Builds):
- Потрібні, якщо MVP залежить від нативних апаратних функцій: push notifications, deep links або специфічних мобільних плагінів.
- Вимоги: платний тарифний план Bubble і облікові записи Apple Developer Program / Google Play Console.
- Порада: стежте за вкладкою «Manage builds». Після кожної зміни дозволів чи оновлення плагінів збірка отримує позначку «Outdated», і її треба перезібрати.

Крок 4. Відокремте Responsive Web від Native Mobile

Якщо ваш MVP — мобільний адаптивний веб-сервіс, вам не потрібні ні dev builds, ні BubbleGo. Тестуйте прямо в мобільному Safari/Chrome або додайте іконку на головний екран (PWA/Home Screen).

Крок 5. Враховуйте Dedicated-інфраструктуру

Якщо проєкт живе на виділеному кластері (Dedicated cluster), майте на увазі: Bubble окремо згадував особливості авторизації в симуляторі для таких середовищ, де виправляли окремі баги доступу.

Резюме для творців та вайбкодерів

Заморожений прев'ю-клієнт не повинен гальмувати ваші перші релізи. Гіпотези я перевіряю в симуляторі в браузері: це безкоштовно і без затримок. На повноцінні dev builds я переходжу тоді, коли цінність MVP справді тримається на нативних датчиках і пушах.