Як працює розробка iMessage Extension?

Уявіть: користувач переписується в iMessage, а ваш сервіс працює прямо всередині чату. Не потрібно виходити з додатка «Повідомлення», щоб надіслати стікер, проголосувати або зробити хід у грі. iMessage-розширення — це окремий Extension target всередині iOS-додатка, який вбудовується в iMessage. Воно відкривається при натисканні на іконку додатка під полем введення. Від моменту появи технології ми розробили понад 20 проектів для App Store, допомагаючи клієнтам пройти рев'ю та уникнути відмов за розділами 4.2 та 5.1 App Store Review Guidelines.

Проблеми, які ми вирішуємо

Ліміт пам'яті ~100 МБ

Apple виділяє близько 100 МБ оперативної пам'яті на розширення. Перевищення призводить до крашу

EXC_RESOURCE

. Ми використовуємо NSCache з countLimit та totalCostLimit, уникаємо важких зображень у кеші, завантажуємо дані асинхронно.

Передача даних між користувачами

Дані кодуються в URL об'єкта MSMessage. Отримувач парсить URL у willBecomeActive(with:). Не можна використовувати UserDefaults напряму — у кожного учасника свій пристрій. Для спільного доступу між основним додатком і розширенням налаштовуємо App Group з однаковим ідентифікатором group.com.yourapp.shared.

Помилки Code Signing

Часто App ID не містить iMessage капабіліті. Ми перевіряємо provisioning profile та додаємо необхідні entitlements.

Як ми це робимо (доказ експертності)

Наш стек: Swift/SwiftUI, UIKit, SpriteKit (для ігор), StoreKit 2, NSCache, FileManager для App Group. Для інтерактивних карток використовуємо MSMessagesAppViewController з перемиканням між Compact (≈225 pt) та Expanded (повний екран) режимами. Наприклад, на проекті фінансового сервісу ми інтегрували iMessage Extension для швидкого обміну даними між користувачами. Налаштували App Group, кодували стан у URL через base64, застосували NSCache для оптимізації завантаження. Час обробки склав менше 1 секунди, а розмір переданих даних не перевищував 2 КБ.

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

1. Аналітика сценаріїв — визначаємо, як користувач взаємодіє в компактному та expanded режимах.
2. Проектування — архітектура з урахуванням лімітів пам'яті та передачі даних.
3. Реалізація — написання коду на Swift/SwiftUI з використанням MSMessagesAppViewController.
4. Інтеграція — налаштування App Group, StoreKit 2, push-сповіщень.
5. Тестування — на реальних пристроях (мінімум 2 iPhone з різними версіями iOS).
6. Підготовка до публікації — App Store Connect, TestFlight, метадані.
7. Підтримка — 30 днів безкоштовної технічної підтримки після релізу.

Орієнтири по строках

• Sticker Pack без коду: 1–3 дні (дизайн + збірка).
• iMessage Extension з інтерактивними картками: від 3 до 5 тижнів.
• Мультиплеєрна гра або складний data exchange: від 6 до 10 тижнів.

Вартість розраховується після аналізу сценаріїв — ми забезпечуємо прозору структуру бюджету. Зверніться до нас для попередньої оцінки строків та вартості. Отримайте консультацію — оцінимо складність вашого завдання та запропонуємо оптимальне рішення. Замовте розробку вже сьогодні.

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

Sticker Pack vs MSMessagesAppViewController

Sticker Pack

Найпростіший варіант без коду: додаємо Extension target типу «Sticker Pack Application», завантажуємо PNG/APNG/GIF у Stickers.xcassets. Apple генерує UI сам. Розміри: Small (100×100 pt), Regular (136×136 pt), Large (206×206 pt). APNG — до 500 КБ, GIF — до 25 МБ (не рекомендується через якість).

MSMessagesAppExtension

Повноцінний Extension з UIKit або SwiftUI. Точка входу — MSMessagesAppViewController. Два режими: Compact (≈225 pt) та Expanded (майже весь екран). Перемикання через requestPresentationStyle(.expanded). Повідомлення представлені об'єктом MSMessage з URL та MSMessageTemplateLayout (зображення, заголовок, підзаголовок). При натисканні у отримувача відкривається розширення, якщо воно встановлено.

Чому варто обрати MSMessagesAppViewController?

MSMessagesAppExtension у 10 разів гнучкіший за Sticker Pack: він дозволяє реалізувати інтерактивні картки, мультиплеєрні ігри, опитування, інтеграцію з покупками через StoreKit 2. Sticker Pack підходить тільки для статичних або анімованих стікерів. Якщо ваш проект вимагає будь-якого сценарію взаємодії — вибирайте MSMessagesAppViewController.

Порівняння режимів Compact і Expanded

Порівняння Sticker Pack і MSMessagesAppExtension

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

По підсумку ви отримуєте: вихідний код проекту з коментарями, налаштовані App Group та StoreKit, підготовлені метадані для App Store Connect, інструкцію по публікації, а також 30 днів технічної підтримки після релізу. При необхідності навчаємо вашу команду роботі з Extension.

Джерело: Apple Developer Documentation on Messages

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