Мы разрабатываем кастомные расширения клавиатур для iOS — от простых смайликовых до полноценных с автокоррекцией и поддержкой нескольких языков. Custom Keyboard Extension — единственный тип расширения, который работает во всех приложениях сразу, но именно из-за этого его сложнее всего зарелизить: Apple требует чёткого соблюдения правил безопасности, иначе — отклонение. Наш опыт включает более 10 успешных проектов, и мы гарантируем прохождение ревью App Store с первого раза.
Почему Custom Keyboard Extension — самый требовательный тип расширения?
Архитектурно клавиатура живёт в изолированном процессе через UIInputViewController. У неё нет прямого доступа к UserDefaults основного приложения без App Groups, сеть работает только при включённом флаге RequestsOpenAccess, а системные поля (например, с паролями) блокируют контекст ввода.
Что происходит, если не настроить App Group?
Первая типичная ошибка: разработчик настраивает App Group для передачи настроек из основного приложения в расширение, но забывает добавить group в Capabilities самого Extension target — не только основного приложения. Xcode не предупреждает. Краш приходит уже на устройстве в виде nil при чтении UserDefaults(suiteName:). Мы настраиваем App Group на обоих target'ах сразу и проверяем доступность suite в коде.
Как правильно указать RequestsOpenAccess?
Apple требует, что если флаг RequestsOpenAccess выставлен в YES, клавиатура обязана явно описать в Privacy Policy, как используются данные ввода. Если описание расплывчатое или его нет — отклонение по 5.1.1 (Data Collection and Storage). При этом если флаг NO, сетевые запросы из расширения молча упадут без каких-либо ошибок в логах. Мы всегда документируем политику и проверяем консистентность между флагом и функционалом.
Ключи, которые нужно отслеживать в Info.plist расширения
| Атрибут | Значение | Описание |
|---|---|---|
IsASCIICapable |
false | Поддержка только ASCII; false для полного набора символов |
PrefersRightToLeft |
false | Направленность текста; false для LTR |
PrimaryLanguage |
en-US | Основной язык для автокоррекции |
RequestsOpenAccess |
true/false | Доступ к сети и полный контекст ввода; true требует Privacy Policy |
<key>NSExtension</key>
<dict>
<key>NSExtensionAttributes</key>
<dict>
<key>IsASCIICapable</key>
<false/>
<key>PrefersRightToLeft</key>
<false/>
<key>PrimaryLanguage</key>
<string>en-US</string>
<key>RequestsOpenAccess</key>
<true/>
</dict>
<key>NSExtensionPointIdentifier</key>
<string>com.apple.keyboard-service</string>
<key>NSExtensionPrincipalClass</key>
<string>$(PRODUCT_MODULE_NAME).KeyboardViewController</string>
</dict>
Как устроен нормальный Custom Keyboard
UIInputViewController предоставляет textDocumentProxy — объект, через который клавиатура взаимодействует с текстовым полем host-приложения. Вставка текста: textDocumentProxy.insertText("a"). Удаление символа: textDocumentProxy.deleteBackward(). Переключение языка: advanceToNextInputMode(). Закрытие клавиатуры: dismissKeyboard().
Важный момент: textDocumentProxy.documentContextBeforeInput и documentContextAfterInput возвращают текст вокруг курсора — но не всегда. В некоторых полях (protected text fields, поля с атрибутами isSecureTextEntry) proxy возвращает nil. Это нужно обрабатывать явно, иначе любая логика автокоррекции или предсказания слов сломается на полях с паролями.
Проблема высоты клавиатуры
Системная клавиатура адаптируется под Safe Area автоматически. Кастомная — нет. Высоту нужно задавать через heightConstraint на inputView, и пересчитывать при изменении ориентации устройства:
override func viewWillLayoutSubviews() {
super.viewWillLayoutSubviews()
let newHeight: CGFloat = view.bounds.width > view.bounds.height ? 180 : 256
if heightConstraint?.constant != newHeight {
heightConstraint?.constant = newHeight
view.layoutIfNeeded()
}
}
Без явного пересчёта на iPhone в landscape-режиме клавиатура либо обрезается, либо перекрывает контент неправильной высотой.
Сохранение состояния между сессиями
Расширение не имеет постоянного состояния в памяти — процесс завершается вместе с вводом. Настройки (раскладка, тема, автокоррекция) нужно хранить в UserDefaults через App Group. Данные побольше (обученный словарь, emoji-история) — в shared CoreData container или файле в shared container через FileManager.containerURL(forSecurityApplicationGroupIdentifier:).
Сравнение подходов к хранению словаря:
| Критерий | UserDefaults (App Group) | CoreData (shared container) |
|---|---|---|
| Скорость чтения/записи | Высокая (синхронно) | Средняя (асинхронно, с контекстом) |
| Размер хранимых данных | Ограничен (~512 КБ) | Практически без ограничений |
| Поиск и фильтрация | Нет (ключ-значение) | Да (запросы и предикаты) |
| Пример | Тема, раскладка | Обученный словарь, история ввода |
Что входит в разработку кастомной клавиатуры?
- Полный аудит требований и составление Privacy Policy в соответствии с правилами Apple.
- Реализация расширения с нуля или доработка существующего (Swift, SwiftUI/UIKit).
- Настройка App Group, shared container, CoreData (если нужен словарь).
- Адаптация под iPad и разные ориентации.
- Тестирование на реальных устройствах через TestFlight, включая проверку в полях UISearchBar, UITextView с
isEditable = false, Safari Address Bar. - Помощь в прохождении ревью App Store (проверка по пунктам 4.2 и 5.1).
- Документация и рекомендации по дальнейшей поддержке.
Сроки и стоимость
Срок разработки — от 2 до 4 недель в зависимости от функционала (автокоррекция, многоязычность, обучение словарю). Стоимость рассчитывается индивидуально после предварительного анализа требований. Свяжитесь с нами для консультации — оценим ваш проект бесплатно.
Почему важно правильно настроить RequestsOpenAccess?
Если флаг установлен в YES, вы получаете полный доступ к контексту ввода и возможность выполнять сетевые запросы. Без этого нельзя реализовать проверку орфографии через внешние сервисы или загружать смайлики с сервера. Но Apple требует явного документа с политикой обработки данных, иначе — отказ. Если флаг NO, клавиатура безопаснее (нет сети), но функционал ограничен. Мы помогаем выбрать оптимальную конфигурацию под задачи продукта.
Как избежать отклонения на ревью App Store?
Мы проходим ревью с первого раза в 95% случаев. Для этого:
- Проверяем консистентность между заявленным функционалом и реализацией.
- Подготавливаем подробную Privacy Policy, если флаг
RequestsOpenAccessактивен. - Тестируем поведение в защищённых полях и после переключения раскладок.
- Убеждаемся, что клавиатура не собирает данные без явного согласия. Свяжитесь с нами — и мы проведём бесплатный аудит вашего проекта на готовность к публикации.
Дополнительная информация: UIInputViewController — официальная документация Apple.