Avoid Premature Localization
Localization is one of the signs of a mature software product. I did a bit of research into whether localizing an app translates into increased sales, and in my non-scientific review of blog posts and forum posts from developers discussing the issue, the conclusion I came to is that localization doesn't make that much sense for games, but does increase sales of non-game apps by about 25%.
25% isn't incredible but it's nothing to sneeze at either. It's not a lot of work to localize an iOS app. Xcode and Cocoa makes it easy to do from the development side, and there are translation houses that will provide localization services on the order of $0.05 per word. The apps I've been working on seem to average about 2000 words, so that's $100 to translate, per language. French, German and Italian currently provide the best localized app sales (reference), so that's $300 to translate.
There's another cost to localization that's important to take into account, and that's the incremental cost of developing your application.
Localization means having multiple copies of any resource that includes text. This includes your nib files, storyboard files, localized string files, graphics, and any other assets (sample documents, for example).
Once you've localized, any change to your application will need to be translated. If you need to fix a bug, and the bug fix requires a new error message, then that means a trip through the localization service for that new error message. This increases your turnaround time for fixing that bug.
Same with any new features. If you add new user interface to your main storyboard, you'll need to send it for translation, and then when it comes back, you'll need to go into the UI for each language and make sure it looks good, that the strings fit, and so on.
And you'll need to test your app in every language, on every device. I expect many developers take shortcuts here and just check the interface in Interface Builder, but I have been going to the trouble to reboot the device in every language I support and run the app to make sure things work.
The message I'm trying to convey here is, localization is worthwhile, but put it off until your app has reached a point where you're not actively developing it. Take a look at your product's roadmap (or make one, if you haven't considered it) and look for a spot where it makes sense to localize.
In my case, with MealPlan, I have a roadmap that includes adding iPhone support and adding iCloud support. Once these two major features are done, I will localize it. Otherwise I know I'd be making multiple localization passes, and those features would take longer to develop if the app were already localized.
(Note that I'm talking about localization here - localization is really part two of making an app world-ready. Part one is globalization, which means making sure that your app is referencing strings in a localizable way, not hard-coding things like date formats and number formats and so on. Globalization should be done from day one).
One last comment on localization. Support. If you ship your app with a German translation and a German user sends you a question in German, what are you going to do? I don't have an answer for that one yet.