|
|
|
|
|
|
by MehdiEG
4901 days ago
|
|
|
A surprisingly good list. Beyond the xib issue, which other have talked about, I would add a couple of points: - If developing a trivial utility app you're expecting to release quickly, target iOS version N-1. Any user who is more that one major iOS version behind won't be the type of user who will download your app (or any app really). If developing anything more ambitious, target the latest iOS version only and take full advantage its new APIs. By the time you're ready to go mainstream (a few iterations of the app under your belt, nailed your marketing strategy, etc), there will have been at least one new major iOS version released and any time and effort you spent writing code for older iOS versions will have been wasted. (talking from experience here :) - Before writing a single line of code, sort out your logging. At the very least, use a handful of macros like [0] to print the class, message name and line number when logging and to exclude debug log statements from release builds. Or check out something like CocoaLumberjack (haven't tried myself yet but writing this made me realize I need to sort out my own logging system so will give it a shot). [0] http://stackoverflow.com/questions/969130/how-to-print-out-t... |
|
|
Once you've published your app as universal, there is no way back. You can't decide in a subsequent update to revert to an iPhone-only or iPad-only app - Apple won't let you.
So if you start with an iPhone app, and then put together an iPad version of the UI just to try out and publish it as a universal app, you'll be stuck with having to provide an iPad version of your app for the rest of times. Even if you realize that the iPad version isn't worth it for your app and that nobody uses it, you won't be able to discontinue it.
So think very carefully before flicking that switch.