As someone who spends a significant amount of time reverse engineering how iOS works, that is incorrect. Currently, the iOS keyboard is managed by the app itsel

As someone who spends a significant amount of time reverse engineering how iOS works, that is incorrect. Currently, the iOS keyboard is managed by the app itself (and I agree: this was likely chosen originally for performance). However, iOS does not expose any APIs that would break by moving this out of process, and in fact, many parts of the UI while inside an app are rendered and displayed out of process, by a separate application (in this case, the window manager, "SpringBoard"): the "Notification Center" is one, but also the "multitasking tray" and the little overlays you get when you change the volume. The reason that the keyboard is required to be implemented "from the system up" is that Apple idea of an "App Store" is fundamentally opposed to the idea, not because of any technological restriction. Apple only sells "apps" with "icons" (by choice), but this gives them one fundamental advantage: all apps are identical, and completely self-contained. I don't agree with that — I use a jailbroken iPhone, for one. But I definitely do see the value for users who don't know what the idea of "an alternate keyboard" would even mean. (On a jailbroken iPhone, I could likely move the keyboard out of process with a week of work; Apple could surely do it even faster. They just don't have any need to: there is no possible situation where, to them, the "flexibility" of alternate input methods is superior to the mental simplicity of just selling an "app" with an "icon".)