Issue 67

iKeyEx 0.1-6 crashes some machines. This is a known problem, a very critical problem, but I did not know how to reproduce it. Fortunately, a proper bug report finally appear as issue 67 and I got to know what has happened. Turns out it's a firmware issue. In ≥2.2 there is a message named

-[UIKeyboardSublayout setIsShiftKeyPlaneChooser:]

which does not present on ≤2.1. In Objective-C, any unrecognized messages will cause an exception to be raised. Since I did not setup any exception handlers, the result is obvious -- crash.

There is another piece of message that is new in 2.2:

+[UIHardware _playSystemSound:]

These 2 should make hClipboard and iKeyEx-derived keyboards unusable in ≤2.1.

I should have caught these when I claimed issue 7 is solved. But why not? This is pretty much an issue of how Objective-C work.

Issue 7 was filed because I found that the linker for 2.0 and 2.1 emitted errors. All external C and C++ functions must be processed by the linker, and if something is missing (even if the header file said it was there), we can immediately know. But Objective-C is different. Objective-C dispatches message implementation dynamically. That's why Category and method swizzling works. But this flexibility means no compile-time check can be done. And the runtime check causes crashes.

What I've done immediately after recognizing the root cause of issue 67 is to build the API diff table. This allows developers to easily see what's new and what's missing during firmware transition, and determine whether a respondsToSelector: call is worth it.

Meanwhile, iKeyEx v0.1-8 fixing the 2 calls has been uploaded to Google code as well.