Airsource was very pleased to see the contents (login required) of yesterday’s announcements about the new version of the iPhone SDK. Naturally we will be updating our existing applications to take advantage of the new features.
Your app is on the App Store, and you’ve just sorted out the translations for all the metadata. So you go upload them on iTunes Connect, and then obviously you check that they look right in iTunes, changing country to make sure each language looks right. English is unchanged and obviously looks okay. France – tick. Deutschland- tick. Nederland – Whoah! That’s not right. My Dutch isn’t that hot but I know it isn’t identical to English. Check the rest, and it turns out Japanese has the same problem.
Let’s back up a step. Firstly, we’re changing our region using the My Store setting at the bottom of the homepage of iTunes Store.
That’s what we do for all the regions – and French works. Why doesn’t Dutch? Why doesn’t Japanese? I’ve been struggling to figure out what these two languages – or at least regional App Stores – have in common. And I have no ideas. Answers on a postcard to…
However, it is possible to check the localizations for Dutch and Japanese. The answer can be found in an Apple Support article, which I’ve summarised here.
On a Mac
On a PC
The same principle works for Japanese.
The update to Optiscan has been approved by Apple – get it on the App Store now! The update is free for all existing customers, and includes several improvements such as better image processing, internationalisation, and bug fixes. Try it out!
A common belief among programmers is that you should write code that says what you mean, because the compiler will probably do a better job at optimising than you can do off the top of your head.
On the other hand, Writing Efficient Android Code says “It is unwise to rely on a compiler to “save” you and make your code fast enough” and recommends that programmers do things like caching member variables (like array lengths) in local variables. This isn’t just premature optimisation; it’s trivial stuff we expect the most basic compilers to handle!
To understand why, it helps to know how your code ends up running on device:
A lot of developers have complained about the App Store feedback process. For one thing, nothing prevents a rival developer leaving a bad review. For another, Apple only solicit reviews from dissatisfied users. What can be done to get better reviews to counter-balance the bad ones? Maybe we could invite happy users to leave a review…
I’m a little sceptical that this will work. As a developer it’s easy to imagine that a user will be happy to sing the praises of your application. As a user, however, my time is precious, and it’s just too easy to hit the cancel button. Having a “Review this app” button on the Info page might work better — I’d be interested to see what people think though!
A friend of mine over at Taptu Mobile Search pointed me to Valgrind. Valgrind is a debugging and profiling tool, and was ported to OS X by Greg Parker. It works for iPhone development too (simulator only) with a simple mod. We haven’t used it in anger yet at Airsource, but we’ll be sure to report results when we do….
I was interested to discover that at the end of 2007, nearly 90% of sampled Japanese users knew what a QR code was – pretty impressive compared to my informal survey results in Cambridge, UK where just about no one outside of the techie world has heart of them, let alone knows what they are. I knew the figure would be high – but not that high…
The Air Source is the blog for Airsource. We are a team of software engineers based in Cambridge, UK. Airsource are Mobile Software Experts, and BREW Specialists.
You are currently browsing the The Air Source weblog archives for March, 2009.
