Реализация App Indexing для Android-приложения: от App Links до Firebase

Мы часто сталкиваемся с ситуацией: клиент вложился в разработку Android-приложения, но Google не показывает его контент в поиске. Пользователи ищут товары или статьи — находят только веб-версию. Приложение остаётся незамеченным. App Indexing решает эту проблему: Google индексирует экраны приложения, а deep link ведёт сразу на нужный контент. Увеличение органического трафика достигает 20–30%, а показатель отказов снижается на 15% — за счёт того, что пользователь сразу попадает на целевой экран. Мы реализуем это под ключ, от настройки App Links до Firebase App Indexing.

App Indexing — механизм, позволяющий Google индексировать контент внутри Android-приложения и показывать его в результатах поиска. Пользователь ищет в Google — видит результат с deep link в ваше приложение, тапает — попадает сразу на нужный экран. Если приложение не установлено — переход на веб-версию.

Технически это связка двух вещей: App Links (верификация домена для надёжных deep link) и Firebase App Indexing SDK (индикация активности для персональных результатов поиска).

Как работают App Links и верификация домена?

Без App Links Android показывает disambiguation dialog («Открыть через...»). С App Links система сразу открывает ваше приложение, минуя диалог.

Манифест:

<intent-filter android:autoVerify="true">
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />
    <data android:scheme="https" android:host="yourdomain.com" android:pathPrefix="/products/" />
</intent-filter>

android:autoVerify="true" запускает верификацию при установке: система обращается к https://yourdomain.com/.well-known/assetlinks.json. Если файл недоступен или некорректен — верификация провалится, диалог вернётся.

assetlinks.json должен содержать SHA-256 fingerprint сертификата подписи APK. Для debug и release — разные сертификаты. При использовании Play App Signing нужен fingerprint из Google Play Console, а не локального keystore.

Частая ошибка: файл assetlinks.json отдаётся с Content-Type: text/plain вместо application/json, или закрыт авторизацией, или редиректит с www. Android верификация не следует редиректам.

Firebase App Indexing SDK

FirebaseAppIndex.getInstance(context).update(
    Indexable.Builder("Article")
        .setName(article.title)
        .setUrl("https://yourdomain.com/articles/${article.id}")
        .setDescription(article.summary)
        .put("keywords", article.tags.joinToString(","))
        .build()
)

setUrl() — это же URL что в App Links. Именно его Google индексирует и показывает в поиске.

Индексируем при каждом просмотре контента пользователем. Для пакетной индексации — в WorkManager задаче при первом запуске или обновлении контента. Не индексируем весь каталог сразу в onCreate() — это замедляет запуск.

App Indexing History. FirebaseUserActions.getInstance(context).start(action) / end(action) — логирует действия пользователя для персональных предложений Google Assistant. Action.Builder(Action.Builder.VIEW_ACTION).setObject(title, url). Start — при открытии контента, End — при закрытии.

Обработка deep link

class ArticleActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        handleIntent(intent)
    }

    override fun onNewIntent(intent: Intent) {
        super.onNewIntent(intent)
        handleIntent(intent)
    }

    private fun handleIntent(intent: Intent) {
        val action = intent.action
        val data = intent.data
        if (Intent.ACTION_VIEW == action && data != null) {
            val articleId = data.lastPathSegment
            viewModel.loadArticle(articleId)
        }
    }
}

onNewIntent нужен если Activity запущена с launchMode="singleTop" или singleTask — иначе повторный deep link не обработается.

Web vs App: связка контента

Для корректной индексации Google нужно, чтобы контент по URL в App Links совпадал с контентом на веб-странице. Страница должна содержать meta-тег:

<link rel="alternate" href="android-app://com.yourapp/https/yourdomain.com/articles/42">

Без этой связки Google может проиндексировать веб-версию, но не знать о приложении.

Почему App Links, а не URI-схемы?

App Links на порядок надёжнее: они проходят верификацию, не пугают пользователя диалогом и получают приоритет при индексации.

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

1. Аудит текущей схемы deep link и манифеста
2. Настройка и размещение assetlinks.json
3. Интеграция Firebase App Indexing SDK
4. Реализация пакетной индексации через WorkManager
5. Добавление Schema.org разметки на веб-страницы
6. Тестирование на реальных устройствах (5+ моделей)
7. Документация и обучение разработчиков

Как тестировать App Indexing

adb shell am start -a android.intent.action.VIEW \
    -d "https://yourdomain.com/products/123" com.yourapp

Проверка верификации: adb shell pm get-app-links --user cur com.yourapp — должно показать verified.

Google Search Console → Mobile Usability → App Indexing показывает статус индексации.

Сроки и как заказать

App Links + базовое App Indexing: от 2 до 3 недель. Полная интеграция с Firebase App Indexing, пакетной индексацией, Google Assistant actions: от 4 до 7 недель. Мы работаем с проектами любой сложности — более 5 лет на рынке мобильной разработки, реализовали App Indexing для 30+ приложений. Свяжитесь с нами для оценки вашего проекта — получите консультацию бесплатно.

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