Such was the situation that I encountered recently with the release of iOS 4 for the iPhone. I received a bug report from a customer that I just could not reproduce. (And as all developers know, if you can’t reproduce a bug, it’s awful hard to fix the bug.) As it turns out, the reason I couldn’t reproduce the bug is because I was in the wrong timezone. How did I figure that out? Because the community of iPhone developers is awesome and generous with their time.

A Google search turned up one lonely description of a problem in another developer’s app which sounded similar to the bug that had been reported in mine. I’d never met this developer before (either in real life, or online), but I took a chance and emailed him anyway. This developer, Greg, took the time to respond to my out-of-the-blue email with a detailed description of the root cause of the problem and the steps needed in order to reproduce it. He saved me hours of time in debugging — hours that I would much rather spend creating new features than debugging old ones.

So what’s the point of this post? It’s really just an excuse to give a shout out to Greg at More Mobile Software who took the time to help out a fellow developer. Thanks Greg! And thanks also to all the other iPhone developers out there that are helpful, supportive, and generally make iPhone development an enjoyable pursuit.

I would again like to apologize for the problems that many of you encountered with Action Lists over the last several days, and for the inconvenience that it caused you. Hopefully, most of you were blissfully unaware of the problems since I removed Action Lists from the App Store, but for those of you who were affected this latest update should fix your issues and I’m sorry for the trouble that you were caused.

With the release of iOS 4 for the iPhone, a serious bug was discovered that didn’t exist under previous versions of the operating system. In order to save my customers from experiencing problems, I have temporarily removed Action Lists from sale in the App Store. I am currently working on a fix and I will hopefully submit a new version to Apple later today or tomorrow. The decision to temporarily remove Action Lists from the App Store will undoubtedly cost me sales, but I believe it’s in the best interests I’d my customers.

I will make another blog post when Action Lists is again available in the App Store, and I’ll also be making periodic posts in the forums to keep people up to date. I’m very sorry for the inconvenience that this has caused all of you.

• Toodledo sync now detects when you have changed your account. This will prevent disappearing contexts and projects when syncing to a new account for the first time.
• Fixed Toodledo so that Active tasks that have their project set to ‘None’ on Toodledo will have their status reset to ‘Next Action’. This will prevent the task from disappearing in Action Lists.
• Fixed Toodledo sync so that any changes that are made to a task during sync (like its status) are immediately pushed back to the remote side. This will keep Action Lists and Toodledo better in sync.

• An “Active” status has been added that will allow users to better plan out their projects. (Active tasks don’t appear in action lists.)
• Automatic task queuing  that promotes Active tasks to Next Actions whenever a task is completed. (This is sometimes referred to as “sequential projects”.)
• A new “Due Soon” feature that highlights tasks as their due date is approaching.
• Localizations. Action Lists is now available in English, German, French, Spanish, and Japanese.

A full list of changes in this version is below. For instructions on how to use these new features, please see the Action Lists documentation.

Version 2.3.0 is a major update that adds some features and fixes some bugs. These changes are included in version 2.3.0:

• Now requires iPhone OS version 3.1 or later
• Internationalized/Localized: Now available in: English, Spanish, French, German, and Japanese
• Added “Active” status to for tasks that are not yet a “Next Action”
• Added “Queue Next Action” option to each project. When this is turned on, a project tries to keep a task in the Next Action status. How it works: When the option is on and a task is completed, the next Active task is made a Next Action. Future tasks are avoided unless they’re all that’s left.
• Added feature to warn users when a task is going to be “Due Soon.” Users can define what “due soon” means through the Settings app. When a task is due soon, its due date is displayed in orange text. When a context or project contains a task that is due soon, its badge turns orange.
• Added optional feature that automatically changes the status of an Inbox item when its project or context is set.
• More robust Toodledo synchronization
• Added option to only count Next Actions for Project badges. When turned on, this option allows the user to scan the project list quickly to look for projects that have “stalled” due to a lack of Next Actions.
• “Show Future Tasks” option can now be set (or unset) for each list individually
• Changed behavior of project badges. Badges now count recursively through the entire project hierarchy, counting only tasks.
• Made note view automatically go into editing mode if the note is empty.
• Added new clipboard button to the background of Quick Task screen to better expose the feature that creates tasks from the contents of the iPhone clipboard.
• Added feature to solicit an App Store review from users
• Several interface improvements
• Fixed several interface bugs
• Fixed several memory leaks

With this in mind, I’m translating the next version of Action Lists into a handful of languages. For those of you unfamiliar with the process, getting your iPhone app translated actually involves two separate processes. “Internationalization” is the process of tagging the strings in your program that you want to have translated. “Localization” is the process of presenting translated versions of those strings to the user. I’m not going to go into great depth about the process of internationalizing and localizing your app (Apple has pretty good documentation on the subject), but I will share some of the tips I discovered while localizing Action Lists; things that I wish I had known when I started.

First of all, if you haven’t already, read Wil Shipley’s excellent blog post on his localization strategy. The main idea is to minimize the number of files that you have to maintain. In a typical app, that might be a .strings file for the app, another .strings file for the settings bundle (if you set application preferences through the Settings app), and then localized versions of each NIB file that was created in Interface Builder. As Wil points out, maintaining multiple versions of NIB files is no fun at all. Any change has to be replicated in each localized version of the NIB. His solution was to create scripts that pull out all the strings for localization. His scripts work well enough for him (as he points out, he’s localized some high profile software using them), but it still seemed like a pretty fragile set up to me. My solution to localizing NIB files was to avoid the problem altogether. I simply didn’t rely on strings set in my NIB files. Instead, I explicitly initialized each string in the NIBs using an IBOutlet in the source code. That way the strings in my interface were internationalized in exactly the same way as other parts of my code.

While we’re on the topic of NIB files, keep in mind that when a string is translated to another language, it’s length is going to change. When you use Interface Builder to layout your labels, buttons, and other interface elements that contain text, make sure that you leave more room than you think is necessary. It’s not unusual for an English string to grow up to 150% of its original length when translated to a European language. By making your buttons and labels bigger than is needed for English, you’ll make your interface a little more flexible and spend less time fixing your interface layout later.

Now that we have the problem of NIBs out of the way, we can turn our attention to internationalizing the source code. Internationalizing strings in your source code is a pretty straightforward process. You need to identify every string that the user might encounter, and wrap it in the NSLocalizedString macro. NSLocalizedString takes two arguments. The first is the string that you want to internationalize. The second is a comment string that the translator can read in the .strings file. Although you can provide nil as the second argument, don’t do it! Making sure that each string has a comment is going to be a bit of pain right now, but it will be a huge help later. When you turn your strings over to the translator, he’s not going to have all of the context that you have. When he sees the word “Contact,” should he translate it as a new telephone number, or the state of two things touching? It might be obvious to you, but it won’t be to your translator. So comment the heck out of your strings. Give context for the string, note any length restrictions that exist, and give synonyms for any terms that might be ambiguous. Also, if some part of the string shouldn’t be translated (like the app name), note that too. Really, you might as well do all this up front, because if you don’t you’re going to spend even more time sorting it all out later.

There’s one last step to internationalizing your app, and that’s extracting the strings in your settings bundle if you set application preferences in the Settings app. Unfortunately, there’s no really good way to automatically extract all the strings from your settings bundle that the user might see. And you definitely don’t want to translate the text keys that are used to identify each setting in the source code. To make this process easier, and to reduce the chance of error, I ended up writing a perl script that extracts all the user-facing strings, avoids keys that shouldn’t be translated, and creates a properly formatted .strings file. It also handles multiple plists in case you have submenus in your preferences. Just run the script from the command line and specify the paths to the plists in the settings bundle as arguments. You’re welcome to use the script any way you want, but I will warn you that it can be fairly described as “quick and dirty.” It doesn’t even use the use strict pragma. (Heresy, I know!) All that being said, it worked great for me.

So at this point the app is internationalized and is ready to be localized. That is, it’s ready to be translated. But translated into which languages? And translated by whom? Well, as for the first question, that’s going to vary. I decided on Spanish and French (which covers most of the Americas), as well as German and Japanese because I thought that those countries were pretty big untapped markets for my app. Ultimately though, you’re going to have to make your own decision based on your own circumstances. The second question is a lot easier to answer though. Who should translate your app? Not you.

We’ve all seen examples of poorly translated instructions that come with cheap products. (If you haven’t, search on the term “Engrish”. You’ll see plenty of examples.) When a translation isn’t fluent, it reflects poorly on the product. It can even be laughable. And you don’t want your app to be the butt of your potential customers’ jokes. Don’t be the next example of “Engrish” in a foreign land. Don’t do the translation yourself. And don’t use Google to do the translation. You want a native speaker of the language to perform the localization; someone who understands not just the grammar, but also the patterns of speech that will make your translation sound fluent to the ears of other native speakers.

So where do you find native speakers to do the translation? Well, you might be able to find native speaking volunteers that already use your app. Although it might be tempting to use volunteer labor to localize your app, I recommend against it. You’re going to be making a lot of demands of your translators. You’ll be going back to them again and again asking for translations with slight changes in meaning, and repeatedly asking them to make translations shorter to fit the available space in your interface elements. You really should consider paying someone for their trouble, because it will be a bother.

If you search the web, you can find several services that advertise their translation services. I ended up going with icanlocalize.com, and I’ve been very happy with them so far. Turn around has been fast, their prices are affordable, and they have good customer service. Whoever you go with, expect translation to be a back-and-forth process. You’ll submit your strings, and receive translated strings in return. Once you receive your translations, you’ll need to test them in your interface to make sure that they fit in the available space. After testing, you’ll undoubtedly find strings that need to be shortened or changed, and you’ll re-submit them for re-translation. And you’ll keep doing this until everything is just right.

There are things that you can do make this process go more smoothly, though. First of all, as I said before, make sure that every string has a comment that describes its context. That will get you off to a good start. Then be incredibly clear when you re-submit strings for re-translation. Explain the problem, suggest alternate translations (if appropriate), and in general make it as clear as possible what it is that you want fixed. And don’t forget that a picture is worth a thousand words. Give your translator screenshots of your app with the problem translation on screen. This lets him estimate how much a translation needs to be shortened, and lets him see the context of the translation so that he can choose translations that are appropriate.

After the translation is complete, you’re not done though. If possible, you should beta test your translations with real users that speak the languages that you have chosen for localization. Even if you don’t usually beta test your releases, you should really do it this time. Real users have domain specific knowledge that translators just don’t have. Your beta testers will be able to spot a translation that might make literal sense, but is just a little off in the context of your app. When users of your app have a common jargon or slang, beta testing your localizations becomes even more important to ensure that your translations sound fluent.

Finally, don’t forget to localize your App Store materials. Have your App Store description translated and then use those translations in your localized App Store page. If your app uses user supplied data, you might also want to get some dummy strings translated for use in your App Store images. And don’t forget to run these materials past your localization beta testers. Presenting yourself in the App Store using your customers’ native tongue will make the best first impression and hopefully make it more likely that your foreign speaking customers will purchase your app.

I hope that these "lessons learned" prove helpful to other iPhone app developers out there, and that it makes the process go a little quicker and easier for you than it was for me. I’m not sure that all my suggestions represent best practices, but they worked well for me. I hope they work for you too.

Some users of my apps might read this and have some concerns that I might know a little too much about their usage habits. Let me allay those fears. The statistics that I have access to through Toodledo are only gross totals. I can see, by app, the number of synchronizations and the number of unique users, and only for the past six months. So although I can see aggregate data, there’s no way for me to tell who’s syncing or how often they’re doing it.

I find it heartening that there are so many people out there that find my tools helpful and integrate them into their daily lives. If you’re one of those people, thanks, and stay tuned. There are more good things planned for the future.

Ok, now that you’re up to speed, here’s the thing: App Store B is dead. It doesn’t exist. At least it doesn’t anymore. The path to success using an App Store B strategy has been closed to new developers for a while. It’s closed, because even an App Store B strategy requires that customers know about your app before they purchase it, and today there’s few ways for an App Store B app to get noticed — even if it’s deserving.

This hasn’t always been the case, though. App Store B did once exist. Apps like PCalc and Things have done well with the strategy, but they got into the App Store early when any good app was cool and sexy and getting press. And because they got noticed, they’ve been able to build the word of mouth following that’s important for a successful App Store B strategy. Today though, the only time that a new App Store B app is likely to be discovered is when a customer sees it while browsing the New Releases list. If your app isn’t flashy, you don’t get reviews and you don’t get noticed. You certainly don’t get in the charts. And since you didn’t get reviewed, and aren’t in the charts, your app never gets found.

So what does this mean for iPhone developers? It means that you go where the attention is. The problem is getting noticed, and there’s two ways to do that as far as I can see. Both go through App Store A.

The first option is to just go with a straight App Store A strategy, as described in Marco Arment’s article. You make a big splash with your flashy app, and once the fuss has died down you move on and try to make another splash with your next app. This approach is particularly well suited to games.

The second option, which I’ll call “App Store B+”, is to start with an App Store A strategy until you build a reputation, then shift to App Store B for future development. By starting with flashier App Store A apps and getting attention, you begin to build a brand. And once people recognize your brand, you’re more likely to have your project mentioned in the press even if it wouldn’t have otherwise been noticed. (e.g. Twitkitteh from James Thomson, and Safety Light from Craig Hockenberry/The Iconfactory) After developing a brand through App Store A, you have the freedom to release apps that are better suited to App Store B. Use the brand recognition that you’ve built though your earlier work to draw some press and attention to your new App Store B apps — press and attention that they wouldn’t have otherwise received. The idea is that after enjoying a little App Store A-style press, a critical mass of customers will become aware of your app which can then begin to enjoy a word of mouth following and settle into App Store B sales figures that are slower, but steadier, then those in App Store A.

Does it matter that App Store B is dead? I think it does. I want an App Store where a developer is rewarded for building a better mousetrap; where a good app gets noticed based on its merits, not just on how flashy it is or the reputation of its author. (Yeah, I live in a land of rainbows and butterflies. Leave me alone, I like it here.) So how could App Store B be revived? One possibility would be the rise of a site that focuses on reviewing high quality non-game apps, sort of a non-game Touch Arcade that could draw attention to good apps. I’m not sure that such a site could generate the traffic needed to be successful, though. Others have suggested things like a premium App Store, which I think could work if Apple exerted a little editorial control over which apps were admitted. (Scary, I know.) Another possibility would be to once again allow updates (not just newly released apps) into the New Releases list so that App Store B apps could at least get periodic exposure as improvements are made. There would have to be some restrictions though, to prevent the abuses of the past. For instance, developers should be restricted to only two approvals per day (a paid and lite version) so that the New Releases list isn’t overrun with 50 versions of the same speed dial app, all from the same developer. Each app should also be limited to appearing in the New Releases list no more than once per month so that developers don’t have an incentive to spam the review process with insignificant changes just to get a bounce in sales. That’s not to say that developers couldn’t submit more frequently if they needed to, they just wouldn’t be rewarded for their frequent submissions.

In truth, I’m probably not qualified to offer business advice to Apple on how to run the App Store, especially since I’m not even sure that Apple’s interests are aligned with mine in this matter. But, as a consumer, I want an App Store that is filled with apps that I want to use over and over, and that get better over time. As a developer, I want the App Store to be perceived as a source of high quality apps that provide value to my customers. Having a path to success for developers using an App Store B strategy seems like the best way to achieve those goals.