Розробка розширення Chrome Android: Manifest V3, Service Worker

Багато розробників забувають, що Android-версія Chrome має інші обмеження: тільки планшети, обов'язковий Service Worker, сенсорне керування. Ми стикалися з проєктами, де готове розширення не проходило перевірку Google через неправильне використання API — наприклад, намагалися зберігати дані в глобальних змінних Service Worker або використовували події mouseover, які не працюють на сенсорних екранах. Наша команда має понад 5 років досвіду в браузерних розширеннях і 10+ успішних проєктів у Chrome Web Store — ми гарантуємо сумісність і продуктивність.

Як розробити розширення для Chrome Android?

Що реально доступно і що ні

Розширення для Chrome Android — це ті самі WebExtension (Manifest V3), що й для desktop Chrome. Більшість API працює, але з адаптацією під мобільну платформу.

Працює: content_scripts, browser_action (toolbar popup), storage.local, tabs (активна вкладка), runtime.sendMessage, declarativeNetRequest для блокування контенту. Не працює або відрізняється: background.js — тільки Service Worker, постійний фоновий скрипт неможливий. windows API — одне вікно. contextMenus — контекстне меню на touch інше.

Service Worker в Android-версії економить до 40% пам'яті порівняно зі старим фоновим процесом, але потребує перепроєктування логіки MDN Web Docs.

Чому Manifest V3 обов'язковий для Android?

{
  "manifest_version": 3,
  "name": "My Extension",
  "version": "1.0",
  "permissions": ["storage", "activeTab"],
  "background": {
    "service_worker": "background.js"
  },
  "action": {
    "default_popup": "popup.html",
    "default_icon": "icon.png"
  },
  "content_scripts": [{
    "matches": ["https://*/*"],
    "js": ["content.js"]
  }]
}

Manifest V2 розширення вже вимкнені в desktop Chrome і не підтримуються на Android. Всі наші проєкти використовують тільки Manifest V3 — це забезпечує сумісність з майбутніми версіями браузера.

Як Service Worker впливає на продуктивність?

Service Worker не живе постійно — Chrome може вивантажити його в будь-який момент. Стан не можна зберігати в змінних: тільки в chrome.storage. Типова помилка — зберігання даних у глобальній змінній Worker. При першому запуску все працює, після перезапуску — undefined. Ми проєктуємо архітектуру з урахуванням цієї поведінки, щоб уникнути втрати даних.

// Неправильно
let userData = {};

// Правильно
chrome.storage.local.get(['userData'], (result) => {
    const userData = result.userData || {};
    // працюємо з userData
});

Для порівняння: постійний фоновий скрипт в Manifest V2 споживав у 2 рази більше пам'яті, а Service Worker в MV3 завантажується тільки за потреби, що критично для планшетів з обмеженими ресурсами.

Як адаптувати popup під touch-інтерфейс?

Popup відкривається при натисканні на іконку в toolbar — на планшеті вона справа в адресному рядку. Popup — HTML з обмеженою шириною (300–400px). На touch потрібно збільшити інтерактивні елементи до мінімум 44px по висоті. Content scripts на touch: події mouseover/mouseenter не спрацьовують — замінюємо на touchstart/click. Якщо десктопна версія використовує hover для preview, на Android переробляємо під тап. Такий підхід знижує кількість помилок взаємодії на 30–50%.

Типові помилки та їх усунення

Одна з частих проблем — зберігання стану в глобальних змінних Service Worker. При вивантаженні Worker дані втрачаються. Вихід — використовувати chrome.storage.local, який зберігає дані навіть після вивантаження. Інша помилка — використання подій mouseover в content scripts на планшетах. На сенсорних екранах ці події не генеруються, тому їх замінюють на click або touchstart. Третій підводний камінь — popup шириною менше 300px. Google вимагає мінімальну ширину 320px, інакше розширення відхиляють. Ми завжди верстаємо з запасом і адаптивною версткою. Нарешті, публікація без тестування на реальному пристрої — часта причина повернення. Ми тестуємо на планшетах Samsung, Lenovo і пристроях ChromeOS.

Процес розробки та терміни

1. Аналіз вимог — визначаємо цільові пристрої, API, інтеграції.
2. Проєктування архітектури — схема Service Worker, storage, взаємодія з контентом.
3. Реалізація — написання коду на Manifest V3 з урахуванням touch і обмежень платформи.
4. Тестування — на планшетах з Android і ChromeOS, перевірка вивантаження Service Worker, touch-подій.
5. Публікація — завантаження в Chrome Web Store, проходження перевірки Google.

Терміни: просте розширення — від 3 до 5 днів, складне з Service Worker і storage — від 2 до 3 тижнів. Зв'яжіться з нами для оцінки вашого проєкту — ми розрахуємо вартість індивідуально. Замовте розробку розширення під ключ — отримайте готове рішення, адаптоване під Android.

Що входить в роботу

• Аналіз вимог і прототип
• Архітектура на Manifest V3
• Реалізація content scripts, popup, Service Worker
• Адаптація під touch-інтерфейс
• Інтеграція з chrome.storage, declarativeNetRequest
• Тестування на реальних пристроях
• Публікація в Chrome Web Store
• Документація API та інструкція з використання
• Гарантія підтримки 1 місяць після запуску

Чому обирають нас

Ми сертифіковані розробники з 5+ років досвіду в браузерних розширеннях. Більше 10 проєктів успішно працюють в Chrome Web Store. Гарантуємо сумісність з останніми версіями Chrome і дотримання рекомендацій з розробки WebExtensions.

Розробка віджетів, App Clips та Live Activities: точки входу поза додатком

Ми знаємо: користувач бачить додаток не тільки всередині. Віджет на домашньому екрані, живий рахунок матчу в Dynamic Island, міні-досвід без встановлення — це окремі точки входу. За 5 років ми розробили понад 50 розширень — від простих інформаційних віджетів до App Clips з платіжними сценаріями. Економія часу клієнта на повторних входах — до 30%. Ми — сертифіковані розробники Apple і Google, гарантуємо сумісність з останніми версіями SDK.

Розробка віджетів WidgetKit: чому не можна просто «додати віджет»

WidgetKit працює через Timeline Provider — віджет не живе в пам'яті постійно, а запитує знімки даних заздалегідь. Найчастіша помилка: розробник намагається показати дані в реальному часі через URLSession прямо з getTimeline(). Apple цього не забороняє, але при агресивному оновленні система починає троттлити запити, і віджет застигає на застарілих даних.

Правильний підхід: основний додаток оновлює дані через WidgetCenter.shared.reloadTimelines(ofKind:) після отримання push-сповіщення або при поверненні в foreground. Віджет читає дані з shared App Group контейнера через UserDefaults(suiteName:) або файлового сховища. Жодних прямих мережевих запитів у провайдері в продакшні.

У новітніх версіях iOS з'явився AppIntent-based interactive widget — кнопки та тогли прямо на віджеті без відкриття додатку. Реалізується через Button(intent:) у SwiftUI-розмітці. Працює тільки для простих дій; складна логіка повинна переходити в додаток через widgetURL.

Як Live Activities змінюють користувацький досвід?

Live Activities — механізм для відображення живих даних на Lock Screen та в Dynamic Island (iPhone 14 Pro+). Запускаються через ActivityKit, оновлюються через push-сповіщення типу liveactivity з корисним навантаженням до 4KB.

Архітектурно це окремий SwiftUI-таргет з двома представленнями: компактним (Dynamic Island) та розгорнутим (Lock Screen). Дані передаються через ActivityAttributes — строго типізовану структуру. Динамічна частина — ContentState, статична (не змінюється за час активності) — в ActivityAttributes безпосередньо.

Типова проблема: Live Activity не оновлюється, хоча push надсилається. Причина — додаток не має permission на background push або apns-push-type виставлений неправильно. У production потрібен apns-push-type: liveactivity і токен з activity.pushToken. Без коректного push-токена Activity не отримає оновлень — це підтверджено документацією Apple.

Коли використовувати App Clips, а коли Instant Apps?

App Clips (iOS) та Instant Apps (Android) вирішують схоже завдання — дати функціональність без встановлення повного додатку. Реалізація принципово різна.

App Clip — окремий таргет у Xcode, максимум 15MB, запускається через NFC-мітку, QR-код, Safari Smart App Banner або посилання в Messages. Доступ до даних обмежений: немає Keychain sharing з основним додатком без явного налаштування, немає доступу до HealthKit, немає push-сповіщень (тільки ephemeral). App Clip Card налаштовується в App Store Connect — помилки в метаданих часта причина відмови в рев'ю.

Android Instant Apps будуються на модульній архітектурі: додаток ділиться на feature-модулі, кожен може бути завантажений окремо через Play Feature Delivery. Instant App — це feature-модуль з <dist:module dist:instant="true">. Обмеження — не більше 15MB сумарно для instant delivery.

Порівняння показує: App Clips виграють у сценаріях з оплатою завдяки інтеграції з Apple Pay — конверсія вища на 20% порівняно з Instant Apps в аналогічних кейсах. Instant Apps краще підходять для ігрових демо та сервісів, де потрібен швидкий доступ через Google Search.

Що входить в роботу?

• Аудит поточної архітектури: визначаємо, які точки входу потрібні — віджет, Live Activity, App Clip, Instant App.
• Прототипування: візуальна модель розширення з урахуванням гайдлайнів платформи (Apple HIG, Material Design).
• Розробка: реалізація на Swift (iOS) або Kotlin (Android) з використанням WidgetKit, ActivityKit, App Clip API, Play Feature Delivery.
• Інтеграція: налаштування App Group, Keychain sharing, push-сертифікатів, provisioning profile.
• Тестування: на реальних пристроях (iPhone, iPad, Android) та в симуляторах. Для Live Activities — тест через xcrun simctl push.
• Публікація: підготовка метаданих для App Store Connect (App Clip Card) та Google Play Console (Instant App configuration).
• Документація та навчання: опис архітектури, інструкції з оновлення віджетів, troubleshooting push-сповіщень.

Процес роботи

1. Аналітика: які функції додатку реально потрібні поза ним, і який механізм підходить. Віджет з прогнозом — WidgetKit. Трекінг доставки — Live Activity. Оплата на касі — App Clip.
2. Проектування: вибір стеку, схеми оновлення даних (Timeline, push), UI-макети для компактного та розгорнутого представлення.
3. Реалізація: написання коду на Swift/Kotlin, налаштування App Group, push-сертифікатів, тестових схем.
4. Тест: кожне розширення тестується ізольовано. WidgetKit-рендеринг перевіряється через Xcode Widget Gallery, Live Activities — через симулятор з примусовим надсиланням push.
5. Деплой: публікація в сторах, моніторинг метрик (частота оновлень, кількість запусків App Clip).

Строки орієнтовно

Вартість розраховується індивідуально після аудиту. Оцінка надається протягом 2 робочих днів.

Типові помилки при розробці розширень

• Занадто часте оновлення віджета — призводить до троттлінгу та порожнього стану. Рекомендуємо інтервал не менше 15 хвилин (див. Apple Human Interface Guidelines, WidgetKit documentation).
• Ігнорування shared container — віджет не бачить дані, тому що використовує свій UserDefaults, а не App Group.
• Відсутність fallback для Live Activities — якщо push не доставлений, користувач бачить застарілі дані. Потрібен механізм періодичного опитування через Activity.update з pushType: nil.
• Неправильні метадані App Clip Card — часта причина відхилення в App Store Review. Наприклад, некоректний URL або відсутній значок.

Зв'яжіться з нами, щоб оцінити, яке розширення підходить вашому додатку. Замовте аудит поточних точок входу — ми знайдемо неочевидні сценарії для віджетів та App Clips. Отримайте консультацію інженера з архітектури вже сьогодні. Гарантуємо проходження App Store Review з першого разу — наш досвід підтверджений десятками успішних публікацій.