Разработка расширения 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% времени на повторных входах.

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

WidgetKit работает через Timeline Provider — виджет не живёт в памяти постоянно, а запрашивает снимки данных заранее. Самая частая ошибка: разработчик пытается показать данные в реальном времени через URLSession прямо из getTimeline(). Apple этого не запрещает, но при агрессивном обновлении система начинает троттлить запросы, и виджет зависает на устаревших данных.

Правильный подход: основное приложение обновляет данные через WidgetCenter.shared.reloadTimelines(ofKind:) — после получения пуш-уведомления или при возврате пользователя в foreground. Виджет читает данные из shared App Group container через 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. Согласно документации Apple, без корректного push-токена Activity не получит обновлений.

Когда использовать 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. Получите консультацию инженера по архитектуре уже сегодня.