{"id":10242,"date":"2014-12-06T10:20:35","date_gmt":"2014-12-06T15:20:35","guid":{"rendered":"http:\/\/mjtsai.com\/blog\/?p=10242"},"modified":"2015-06-24T18:08:15","modified_gmt":"2015-06-24T22:08:15","slug":"developing-keyboards-for-ios","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2014\/12\/06\/developing-keyboards-for-ios\/","title":{"rendered":"Developing Keyboards for iOS"},"content":{"rendered":"

Norbert Lindenberg<\/a> on what he learned developing his English IPA Keyboard<\/a> (App Store<\/a>):<\/p>\r\n

\r\n

Yes, some of these suggestions sound a little desperate, and for many keyboards you will at some point have to request full access. Things would be a lot easier if Apple allowed containing apps to write into their keyboards’s containers, similar to how the Mail app delivers attachments into an app’s Inbox directory, without the need for full access. This would let containing apps send dictionaries and configuration settings to the keyboard while protecting user input from being leaked out of the keyboard.<\/p>\r\n

[…]<\/p>\r\n

A number of keyboards have been rejected based on section 25.6, so it seems something<\/em> is required. For the first version of the English IPA keyboard, I argued that the keyboard was designed as a supplementary keyboard, not as a user’s primary keyboard, and therefore shouldn’t have to support all the keyboard types, similar to Apple’s emoji keyboard. My keyboard was approved, but at least one other developer using similar arguments saw his app rejected.<\/p>\r\n

[…]<\/p>\r\n

It’s much better to design custom images for the function keys that your keyboard needs. There doesn’t seem to be any way for third-party keyboards to access the images that Apple’s built-in keyboards use.<\/p>\r\n

[…]<\/p>\r\n

Reading the documentation<\/a> might lead you to expect that your input view controller’s textDidChange<\/code> method will be called when “text has changed in the document”, or selectionDidChange<\/code> when “the selection has changed in the document”. Reality as of iOS 8.1 is that textDidChange<\/code> and its buddy textWillChange<\/code> are called when the keyboard’s client view becomes or resigns as first responder and when the selection changes, and selectionDidChange<\/code> and its peer selectionWillChange<\/code> are never called. Of course, this might get fixed eventually, so don’t rely on this either.<\/p>\r\n

[…]<\/p>\r\n

The documentation for UIKeyInput.deleteBackward<\/code> states that it deletes “a character”. Those familiar with Unicode, NSString<\/code>, and Swift’s String<\/code> type know that the word “character” is quite overloaded – it could mean a Unicode code point, a UTF-16 code unit, or an extended grapheme cluster<\/a>. But that’s only where the trouble starts.<\/p>\r\n

[…]<\/p>\r\n

Implementing forward deletion as described in the API Quick Start for Custom Keyboards<\/a> section of the Guide also does not work. It depends on the assumption that the increment used by adjustTextPositionByCharacterOffset<\/code> matches what deleteBackward<\/code> deletes, but in reality that’s not always the case.<\/p>\r\n

[…]<\/p>\r\n

It seems unlikely that you could invade the user’s privacy by playing click sounds when she taps a key, but the method in charge of these sounds, UIDevice.playInputClick<\/code>, hangs for several seconds rather than doing its job when called without full access.<\/p>\r\n<\/blockquote>","protected":false},"excerpt":{"rendered":"

Norbert Lindenberg on what he learned developing his English IPA Keyboard (App Store): Yes, some of these suggestions sound a little desperate, and for many keyboards you will at some point have to request full access. Things would be a lot easier if Apple allowed containing apps to write into their keyboards’s containers, similar to […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"apple_news_api_created_at":"","apple_news_api_id":"","apple_news_api_modified_at":"","apple_news_api_revision":"","apple_news_api_share_url":"","apple_news_coverimage":0,"apple_news_coverimage_caption":"","apple_news_is_hidden":false,"apple_news_is_paid":false,"apple_news_is_preview":false,"apple_news_is_sponsored":false,"apple_news_maturity_rating":"","apple_news_metadata":"\"\"","apple_news_pullquote":"","apple_news_pullquote_position":"","apple_news_slug":"","apple_news_sections":"\"\"","apple_news_suppress_video_url":false,"apple_news_use_image_component":false,"footnotes":""},"categories":[4],"tags":[130,200,1079,948,905,31,904,423,71,901,258],"class_list":["post-10242","post","type-post","status-publish","format-standard","hentry","category-programming-category","tag-rejection","tag-autolayout","tag-english-ipa-keyboard","tag-english-language","tag-extensions","tag-ios","tag-ios-8","tag-keyboard","tag-programming","tag-swift-programming-language","tag-unicode"],"apple_news_notices":[],"_links":{"self":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/10242","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/comments?post=10242"}],"version-history":[{"count":2,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/10242\/revisions"}],"predecessor-version":[{"id":11570,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/10242\/revisions\/11570"}],"wp:attachment":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/media?parent=10242"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/categories?post=10242"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/tags?post=10242"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}