iOS

Block Emoji-Keyboard for Text Input

Leave a Comment

I recently stepped over an issue during iOS app development for one of my customers. If the user switches to the Emoji-Keyboard on her iPhone during text input in a UITextField or UITextView and uses some of the icons the backend system for that app could not handle this. Implementing Emoji-Support on the server side would be a high effort.

The far more easier solution is to block the Emoji-Keyboard on the iOS side to prevent the user from using these characters. The UITextInputTraits protocol defines the property keyboardType of type UIKeyboardType. By setting this property you can define the keyboard layout shown to the user, he starts typing into a UITextView or UITextField.

The enumeration UIKeyboardType lists several keyboard layouts for email input, phone number input, or URL input for example. The property keyboardType has the value UIKeyboardTypeDefault as its default value. With this set the user may use Emojis from the Emoji-Keyboard if he has activated this in the settings on his iPhone. Deactivating the Emoji-Keyboard but still enabling the user to switch between different keyboard languages is rather simple: Just set the property keyboardTypeto UIKeyboardTypeASCIICapable. This sounds a little bit confusing as you might think, from now on only characters from the ASCII character set may be shown, but this is not true. The user has the full character set at hand, can switch to other language-related keyboards but the Emoji-Keyboard.

Every time you handle text input you should think about using the appropriate keyboard layout and switching to UIKeyboardTypeASCIICapable.

Four years ago

Leave a Comment

Four years ago it started all: Apple released iPhone SDK 1.2b1 to the developer community on March 6th, 2008 and I did my first steps in iOS programming, too.
Nearly exactly 4 years after releasing the first SDK to its developers the App Store has reached 25 billion downloads on March 5th, 2012. Incredible!
And tomorrow on March 7th, 2012 Apple will release a new iPad together with iOS 5.1 – and maybe one more thing.

Xcode 4.3 crashes on Archive

Leave a Comment

The Situation

I have an Xcode project for an iOS app with 10 targets creating different variants of the app. I was able to archive all except one of the targets. On building an archive of this target Xcode crashed with

(NSInvalidArgumentException): -[DVTFilePath compare:]: unrecognized selector sent to instance 0x406368fe0

The build and linking worked properly and the activity viewer showed ‚Archive success‘ shortly.

In the good case after this step the Organizer opens and shows the generated archive. If there is an error during archive Xcode shows this in the standard issue navigator and in the activity viewer – but you know this. In my case Xcode crashed with the error mentioned above.

I had no problems earlier and was a little bit surprised as this error was 100% reproducible.

The Analysis

The typical first step is to look for someone else having the same problem. It showed out that there were some developers with the same problem. I stepped over Ash Furrows blog entry on this topic: growl notification code signing for sandboxed mac apps

Ash describes the same crash by using the Growl.framework in one of his projects in correlation with code signing. I did not use that framework in my project, but remembered that I included the Facebook iOS SDK. This one was built locally from the sources and the static library is inside my Xcode project. As the app does not use Facebook features currently the static library is not used in any target – it is just in the project. But in contrast to Ash’s problem with the Growl.framewok mine was a little bit different: I did not used a binary version of the static library, but it was already compiled on my own. So, what’s the problem?

The Solution

After removing the library from my project everything worked fine. So the crash must be related to the static library. I added it to the project again, but not to any target and boom – Xcode crashes. After that I found the helpful words in Ash’s blog entry: „You’ll need to rebuild Growl.framework any time your certificate expires, once a year.“

I remembered that I had to renew my certificate a few days ago. And indeed this is the solution! If you have another framework or static library in your Xcode project (even if not used!) you have to recompile that every time your developer certificate changes – usually once a year. If you miss that Xcode 4.3 ends up in a crash if you create an archive.

This is a really bad behavior of a piece of software to react with a crash on some kind of reconfiguration. Apple should fix this annoying and not even easy to handle bug. In the case of Ash and myself we were able to recompile the code as the sources are available to the public.