Разработка кастомной клавиатуры (Custom Keyboard) для iOS
Custom Keyboard Extension — один из немногих типов расширений iOS, которые получают доступ к вводу во всех приложениях сразу. Это же делает его самым сложным в прохождении ревью App Store: Apple тщательно проверяет соответствие RequestsOpenAccess и реальное поведение приложения.
Где всё ломается ещё до релиза
Архитектурно Custom Keyboard работает через UIInputViewController. Это не просто вью-контроллер — он живёт в отдельном процессе, изолированном от host-приложения. Нет доступа к UserDefaults с suite, нет общего keychain без App Groups, нет сети без флага RequestsOpenAccess: YES в Info.plist.
Первая типичная ошибка: разработчик настраивает App Group для передачи настроек из основного приложения в расширение, но забывает добавить group в Capabilities самого Extension target — не только основного приложения. Xcode не предупреждает. Краш приходит уже на устройстве в виде nil при чтении UserDefaults(suiteName:).
Вторая проблема серьёзнее. Apple требует, что если флаг RequestsOpenAccess выставлен в YES, клавиатура обязана явно описать в Privacy Policy, как используются данные ввода. Если описание расплывчатое или его нет — отклонение по 5.1.1 (Data Collection and Storage). При этом если флаг NO, сетевые запросы из расширения молча упадут без каких-либо ошибок в логах.
Ключи, которые нужно отслеживать в Info.plist расширения
<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 — объект UITextDocumentProxy, через который клавиатура взаимодействует с текстовым полем 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:).
Тестирование и ревью
Тестировать Custom Keyboard в симуляторе неудобно: смена клавиатуры работает иначе, чем на реальном устройстве. На симуляторе переключение через advanceToNextInputMode() часто не срабатывает. Используем реальное устройство с TestFlight с самого начала.
Перед отправкой в ревью: проверяем поведение в полях UISearchBar, UITextView с isEditable = false, в Safari Address Bar (расширение там не активируется — это нормально, но клавиатура не должна крэшиться при попытке).
Ревью App Store отдельно проверяет: нет ли скрытого кейлоггинга, корректно ли описана Privacy Policy, соответствует ли фактическая функциональность заявленной.
Срок разработки: от 1 до 3 недель — зависит от наличия собственного лексикона, автокоррекции, многоязычности. Стоимость рассчитывается индивидуально после анализа требований.