Keyboards listed on iPad when there is no iPad definition available

[snomos]

On the iPad, when a keyboard layout only has an iPhone layout definition, it is still listed and available, but returns a US keyboard (Livonian in this case):

In General > keyboards:

In the keyboard selection menu:

trim.362470C2-33D4-49DB-A2CE-C7D2B51B716A.MOV

It would be better to hide the keyboard completely when no suitable definition for the device is available. As it is now it is very confusing for users.

I will nevertheless release this version, as it fixes the core issue on the iPhone, the iPad fixes can be released separately.

[dylanhand]

I've been looking into this one today. The expected solution, one might think, would be to disable iPad as a supported destination, here:

In testing however, this has no effect, possibly because iPhone apps are able to run on iPad. To test sanity I even made a separate project with keyboard extension and disabled everything except iPhone as a Supported Destination on each target including the hosting app. The only difference was that the hosting app appeared as an iPhone app in iPad mode (with an option to zoom in or rotate in bottom right corner), but the keyboard was still listed on iPad and could be enabled.

Given this limitation, an alternative solution would be to show a message on iPad where the keyboard should appear, something like:

"The <insert language> keyboard is currently only available on iPhone".

That way the user gets some indication of why it isn't working instead of doing nothing and defaulting to the US keyboard.

What do you think @snomos?

[snomos]

Yes. And a note to contact the developer to request iPad support, with an email address or something. That way we would get an indication about which layouts to prioritise, if needed.

[dylanhand]

@snomos for the feature that allows a user to notify us if they'd like to see a particular keyboard supported on iPad, I'm imagining a button that pre-fills an email with the keyboard language/locale, device type, and an email address to which these requests should be sent. Something like:

To: keyboard-requests@divvun.org
Subject: Request for keyboard-liv on iPad 9inch
Body: <User adds any additional notes here>

It appears it's not possible to pre-fill an email in Mail.app from an app extension, but it should be possible by first launching the HostingApp and doing it from there.

Checking with you before I go further in case you had something else in mind:)

[snomos]

Sounds good. To make the extra step via the app more useful, the email text should be presented to the user, and possibly in an editable form (or is the editing done in the Mail app?). The recipient email address should be configurable in the keyboard app repo, by default it should be feedback@divvun.no.

You could also have another button or link that instead take the user to the relevant GitHub repository/issues, with some pre-filled text. That should also be possible, along these lines:

https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/creating-an-issue#creating-an-issue-from-a-url-query

https://github.com/giellalt/keyboard-liv/issues/new?labels=enhancement&title=Request+for+keyboard-liv+on+iPad+9inch

This is obviously only useful for users with GitHub accounts, but for such users it might be handier.

[dylanhand]

I can make it possible to submit a request both via email and GitHub. And for email, it should be possible for us to bring up a Mail.app compose window (without leaving HostingApp) that is pre-filled and editable by the user.

I'll also look into how to make the email address configurable. It appears that .kbdgen bundles already contain an email address, but I'll need to dig into kbdgen a bit to see how/if it's being used.

[snomos]

Sounds good, all of the above.

[dylanhand]

New version available now in TestFlight that has most everything done, full list here: divvun/giellakbd-ios#237