Разработка расширения для Safari на iOS под ключ

Мы разрабатываем расширения для Safari на iOS, используя WebExtension API с учётом жёстких ограничений мобильной платформы. В отличие от desktop-браузеров, расширение упаковывается внутри нативного iOS-приложения, распространяется через App Store и активируется пользователем вручную в настройках Safari. Портировать Chrome-расширение напрямую не получится — половина desktop-логики ломается из-за особенностей iOS. Наш опыт: 5 лет в iOS-разработке, более 50 успешных проектов, гарантируем прохождение App Store Review. В среднем 80% JS-кода переносится без изменений, остальное требует ручной адаптации.

Почему iOS Safari Extension сложнее desktop-версии?

Desktop-браузеры позволяют фоновым скриптам работать постоянно, перехватывать сетевые запросы через webRequest и получать доступ ко всем вкладкам. На iOS эти возможности недоступны или работают иначе. Рассмотрим ключевые отличия.

Background scripts не работают

В Chrome background.js живёт постоянно. В iOS Safari Service Worker (MV3) выгружается сразу после выполнения задачи. Любое состояние, которое desktop-расширение хранит в памяти background script, на iOS нужно персистировать через browser.storage.local или передавать через нативный хост.

webRequest API отсутствует

Перехват и модификация сетевых запросов на iOS выполняются через Content Blockers (WKContentRuleList), а не через webRequest. Если ваше расширение блокирует рекламу через webRequest.onBeforeRequest, этот код не перенести напрямую.

Доступ к вкладкам ограничен

browser.tabs.query() возвращает только активную вкладку. Итерация по всем открытым вкладкам, как на desktop, недоступна.

Content scripts инжектируются с задержкой

На iOS страница может полностью загрузиться до того, как content script начнёт выполняться. Код, который рассчитывает на перехват DOMContentLoaded, может не успеть.

Как мы адаптируем расширение под iOS

Мы используем Swift 5.9+ для нативной части и JavaScript (ES2020) для веб-части. Каждое расширение проходит рефакторинг: миграцию с webRequest на WKContentRuleList, замену background.js на Service Worker с персистентностью в browser.storage.local. Вот пример нативного обработчика сообщений от JS:

class SafariWebExtensionHandler: NSObject, NSExtensionRequestHandling {
    func beginRequest(with context: NSExtensionContext) {
        guard let item = context.inputItems.first as? NSExtensionItem,
              let message = item.userInfo?[SFExtensionMessageKey] else {
            context.completeRequest(returningItems: nil, completionHandler: nil)
            return
        }
        // обрабатываем message от JS
        let response = NSExtensionItem()
        response.userInfo = [SFExtensionMessageKey: ["status": "ok"]]
        context.completeRequest(returningItems: [response], completionHandler: nil)
    }
}

Сравнение desktop и iOS Safari Extension

Типичные сложности при портировании

Типичный сценарий: менеджер паролей

Допустим, нужно автозаполнение через content script. JS инжектируется в страницу, находит <input type="password">, сообщает нативному хосту через browser.runtime.sendNativeMessage(). Нативный хост обращается к keychain через Security.framework и возвращает данные. Content script заполняет поле.

Проблема: sendNativeMessage на iOS работает только когда нативное Extension target запущено. Если пользователь не открывал приложение после перезагрузки устройства — Extension Host может не успеть стартовать. Нужен retry-механизм на стороне JS.

Как портировать Chrome-расширение в Safari?

1. Запуск конвертера: выполните xcrun safari-web-extension-converter --bundle-name YourExt path/to/extension. Утилита создаст Xcode-проект с native-обёрткой.
2. Анализ несовместимых API: проверьте использование webRequest, background.js, неограниченный доступ к вкладкам. Эти участки подлежат замене.
3. Адаптация background: замените постоянный background script на Service Worker с персистентностью в storage.local. Перепишите обработчики событий.
4. Миграция блокировки запросов: если используется webRequest, перепишите на WKContentRuleList. Учтите, что Content Blocker поддерживает ограниченный набор правил (до 50 000 правил на блок).
5. Тестирование на реальном устройстве: используйте TestFlight для установки билда на iPhone. Проверьте работу content script на разных сайтах.

Что входит в работу

• Анализ вашего desktop-расширения (если есть) и составление карты несовместимых API
• Разработка нативного Extension target на Swift с обработчиками сообщений
• Адаптация JS-логики под iOS: замена webRequest, фоновых скриптов, персистентность
• Конфигурация манифеста и разрешений (обоснование для App Store)
• Интеграция с App Store Connect, TestFlight, Provisioning Profile
• Документация по сборке и публикации
• Поддержка в течение 30 дней после сдачи

Сроки и стоимость

Срок разработки: от 1 до 3 недель в зависимости от сложности JS-логики и объёма нативного взаимодействия. Стоимость рассчитывается индивидуально. Мы оценим проект после согласования требований.

Какие разрешения требуются для App Store?

App Store требует обоснования каждого разрешения в манифесте. tabs — для чего? storage — что именно хранится? Размытые ответы в форме подачи приводят к 4.0 Design rejection с просьбой уточнить функциональность.

Расширения с <all_urls> в host_permissions проходят усиленную проверку. Apple может запросить видеодемонстрацию работы расширения на реальном устройстве.

Почему мы?

Нативные обработчики на Swift в 10-20 раз быстрее JS для задач криптографии и работы с файлами. Если ваше расширение выполняет тяжёлые вычисления, перенос логики в нативный код даст заметный прирост производительности. Больше 50 портированных проектов подтверждают этот подход.

Свяжитесь с нами для оценки вашего проекта — мы подготовим предложение в течение 2 рабочих дней. Получите консультацию по адаптации вашего расширения уже сегодня.

Подробнее в документации Safari Web Extensions.

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