If you like my tutorials, you will love my book . It is chockful of advanced programming techniques and the only comprehensive barcode reference for serious iOS developers.
Our DNA is written in Objective-C

Unicode, Schmunicode!

You are listening to user feedback, especially those in Italy. You solve all their problems with a new version, in my case LuckyWheel 1.0.3. You polish it, test it (you think) and submit it to Apple for review. After a week you get this message back:

Your applications, LuckyWheel and LuckWheel Lite, cannot be posted to the App Store at this time because they do not achieve the core functionality described in your marketing materials, or release notes.  Applications must adhere to the iPhone Human Interface Guidelines as outlined in iPhone SDK Agreement section 3.3.5.

The release notes for both applications state, “Italian UI and Instructions added”.  However, in our review, when we put the device into Italian language mode and launched the applications, the application UI was still in English.  Only the instructions were changed to Italian.  See attached screenshots.

In order for your applications to be reconsidered for the App Store, please resolve this issue and upload your new binaries to iTunes Connect.

That’s a very long way to say: “Hey buddy, your Italian is English!”

When I got this message I was stumped. I though I had tested it. Thieves! Who has stolen my Italian UI?! But then I remembered something I had found out some months ago.

There are definite differences between iPhone Simulator and devices. One that I found out through experimentation is that Simulator will happily accept UTF-8 encoded Localizable.strings files while iPhone absolutely insists in UTF-16 as the only accepted encoding for strings files.

When I then used a hex editor to compare a freshly UTF-16-forced Italian strings file with the one I had submitted to Apple it became clear as day.

UTF-8 Text File in Hex Editor

UTF-8 is one byte per character as you can see above. UTF-16 looks different, only every second character is readable because of this two bytes per character.

UTF-16 Text File in Hex Editor

There is no way to spot this problem unless you are specifially looking for it with a hex editor. XCode neither shows you the current encoding of a text file nor does it give the slightest warning.

The only way to make absolutely certain that you have the strings files in UTF-16 format is via the “Get Info” option. There set the “File Encoding” to “Unicode (UTF-16)”. Then choose “Convert” and not “Reinterpret” to force the encoding.

Force a strings file to utf16

I learned that it is better to force all your strings files to UTF-16 as shown above. This way you will never have to curse as the inventers of multi-byte unicode because one of your UI languages went missing.

Categories: Recipes

%d bloggers like this: