Разработка кастомной клавиатуры (Custom Keyboard) для iOS

Мы разрабатываем кастомные расширения клавиатур для 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 расширения

<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:).

Сравнение подходов к хранению словаря:

Что входит в разработку кастомной клавиатуры?

• Полный аудит требований и составление 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.