Індексація 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 система одразу відкриває ваш додаток, минаючи діалог. За нашими даними, App Links підвищують конверсію на 40% порівняно з URI-схемами.

Маніфест: <intent-filter android:autoVerify="true"><data android:scheme="https" android:host="ваш-домен" android:pathPrefix="/products/" />

android:autoVerify="true" запускає верифікацію при встановленні: система звертається до файлу 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

Документація Firebase App Indexing SDK: https://firebase.google.com/docs/app-indexing

FirebaseAppIndex.getInstance(context).update(
    Indexable.Builder("Article")
        .setName(article.title)
        .setUrl(article.url) // замініть на реальний URL
        .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/ваш-домен/шлях">

Без цієї зв'язки 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://ваш-домен/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+ додатків. Сертифіковані розробники Firebase гарантують якість інтеграції. Зв'яжіться з нами для оцінки вашого проекту — отримайте консультацію безкоштовно.

Розробка віджетів, 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 з першого разу — наш досвід підтверджений десятками успішних публікацій.