Розробка кастомної клавіатури (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.