swift - Showing the system Emoji keyboard by default on iOS 13

Question

Solution

Here is a full solution/work around for this issue, please up vote Blld's answer as well because this was the vital bit of info needed!

Alternative titles to aid search

• Showing the Emoji keyboard as default for a UIKeyInput object (in iOS 13)
• Force iOS 13 to show the Emoji keyboard
• Setting the UITextInputMode.primaryLanguage to emoji
• Programatically set the keyboard to emoji

Prior to ios13 returning the UITextInputMode with primaryLanguage that equaled "emoji" would default to showing the Emoji Keyboard (see image below).

Example code for returning the "emoji" UITextInputMode.

//
//  ViewController.swift
//  Keyboard Info
//
//  Created by Richard Stelling on 30/09/2019.
//  Copyright ? 2019 Richard Stelling. All rights reserved.
//

import UIKit

class TestButton: UIButton, UIKeyInput {

    var hasText: Bool = true

    func insertText(_ text: String) { print("(text)") }

    func deleteBackward() {}


    override var canBecomeFirstResponder: Bool { return true }

    override var canResignFirstResponder: Bool { return true }

    override var textInputMode: UITextInputMode? {
        for mode in UITextInputMode.activeInputModes {
            if mode.primaryLanguage == "emoji" {
                return mode
            }
        }
        return nil
    }
}

Running this code on iOS 12 will set the keyboard to the system Emoji Keyboard, but on iOS 13 it has no affect.

Is this a known bug? Is there a workaround?

Updates

• Requested by @Navillus, the full list of "active input modes" is; "en-GB", "emoji"
• Tested and confirmed on; 13.0, 13.1, 13.1.1, 13.1.2 and 13.2 (seed 1)

Answer 1

I filed a radar on this for iOS 13 because I have a bilingual Japanese/English app. Some fields are Japanese and some English so obviously it makes sense to present the right keyboard type to the user instead of making them flip back and forth 20 times.

There was a workaround for this, and that was that after the UIKit calls 'textInputMode', in the main thread you could do this:

// has to be done after the textInputMode method is called
if #available(iOS 13, *) {
    textField.keyboardType = textField.keyboardType
} 

This forces the keyboard to reload after answering with the textInputMode that you wanted. I informed them of the bug, and the workaround to get correct behavior.

So in iOS 13.1 the bug was not fixed, however they blocked my workaround.

Nice. I won't report any bugs to them again. Rather if I find a workaround I will just use it.

So it seems like they now are silently disabling this feature. And it is a feature, this is literally the purpose of this method call, to find out what input mode should be presented to the user.

It still works ok though if you have another language and want to select English.

So if my user sets Japanese as the keyboard selection then I can force an English keyboard up. Just not the other way around. Any attempts to get a Japanese input mode end up in an English keyboard.

EDIT:

There is another path that you can work around this, but it involves discovery and use of internal API which is not straightforward. You'd have to essentially find the functions used to manage the results of hitting the globe button. If you do that you're essentially simulating the user's taps and it has wide ranging effects, that is, the keyboard will be changed for other apps too. So it's not recommended, 100% it will fail App Store submission. I don't want to post it because of the results of my last workaround.

I think it's not possible to understand Apple very easily. All I know is that:

1. the API is not functioning as published
2. it was reported and they did not fix the bug
3. since the time of reporting they broke (intentionally or not) the workaround

So future workarounds should be hoarded until their intentions are clear and/or they fix this bug (which is what they should do). Simply revoking part of the API without publishing the change is a major bug.