Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 4 down vote favorite
8

For example I just learned today about NARC. Never release something unless you made it "New, Alloced, Initialized or Copied". That just fixed a couple different bugs in my app that I couldn't find.

What other things are very important for iPhone development?

EDIT
I have no idea how to make this Community Wiki.

share|improve this question
Are you the only person on the project? Personal project or for your company? – JBRWilkinson Jan 20 '11 at 22:55
There basically is no more Community Wiki. Moderators control that now. – Walter Jan 20 '11 at 23:10
@JBRWilkinson: I am working alone, but you might as well give advice for working on a team too! – James P. Wright Jan 21 '11 at 1:36

migrated from stackoverflow.com Jan 20 '11 at 22:15

9 Answers

up vote 9 down vote

If you're looking to capitalize on iPhone development, choose to develop projects that are small, which will take you no longer than a few weeks to a month to complete. Realize that most iPhone applications are monetary failures, and those who succeed at making actual money, are those who saturate the market with their throw-away applications.

I'm fairly certain that if we, as developers, had the opportunity to look at the source behind many of the top selling applications, we'd cringe...and then die a little inside each time.

share|improve this answer
2  
iFart made good money and said something about the average intelligence niveau of the iPhone users. – user8685 Jan 20 '11 at 22:32
1  
iFart was also only $1 and trivially easy to buy. – kubi Jan 21 '11 at 0:03
1  
-1 I'm personal friends with several developers who have created and continue to create high-quality well-written apps that provide very healthy livings for themselves and their families, and I know of many dozens more. If you charge a decent price for your app, you don't actually have to saturate the market to do well. – Matthew Frederick Jan 21 '11 at 8:10
up vote 5 down vote

Realize you are coding for a constrained device with a small battery. Test memory footprint and performance on actual devices. Watch the WWDC videos where they suggest how to not drain battery life.

Read the HIG.

User test your UI. Observe. Include users with less than excellent eyesight.

Examine all the llvm static analysis and Xcode build warnings.

share|improve this answer
What is the HIG? – James P. Wright Jan 20 '11 at 22:21
HIG = Apple's iOS Human Interface Guidelines. – hotpaw2 Jan 20 '11 at 22:25
HIG = Human Interface Guidelines – Anthony Jan 20 '11 at 22:26
+1 for low-vis users. Also low-dexterity users! Basically, get some test users who are over 45. ;) – Alex Feinman Jan 21 '11 at 17:48
up vote 4 down vote
  • Don't ever use retainCount.
  • Don't fight the frameworks (probably great advice for any platform).
  • Use Interface Builder unless you have a good reason not to.
  • Use Core Data unless you have a good reason not to.
  • Don't ever use retainCount.
share|improve this answer
retainCount does not exist. – Alan Zeino Jan 20 '11 at 22:11
Want to give you +1 for each of your first and last lines. – Graham Lee Jan 20 '11 at 23:13
1  
Please, for those who do not know, can you provide reference info about RetainCount, and why you shouldn't use it. – Slomojo Jan 21 '11 at 6:38
@Slomojo: retainCount tells you how many times an object is being retained by some other object. Two reasons it is the soul of evil: first, you should understand reference counting well enough to release objects at exactly the right time and place, never wondering if they need releasing; a while ([object retainCount] > 0) [object release]; loop just shows that you're clueless and likely wrong about whether releasing is appropriate. The second problem is that the number it returns is unreliable: just because something's being retained doesn't mean you have the responsibility to release it. – Matthew Frederick Jan 21 '11 at 8:06
Ahh, I see, so instead of properly disposing of an object, people are using retainCount to, mass delete instances... seems more stupid than evil, but those features are often interchangeable. (stupid/evil that is) – Slomojo Jan 21 '11 at 9:41
show 1 more comment
up vote 3 down vote

The first thing to know about iPhone development is that you should talk about iPhone development. The second thing is to find out what the tools are capable of doing for you:

  • don't write UIs in code, when IB can do it for you
  • don't write sqlite-backed data models in code, when Core Data can do it for you
  • there is good i18n/l10n support in the frameworks, and tools to aid in translation
  • you should run Build & Analyse every day. It will tell you about bugs that you can't believe exist, but do.
  • Instruments can find many of the other bugs.

Other than that, you may think square brackets are odd today, but you'll be used to them in two days. Concentrate on learning the APIs, because there isn't much of Objective-C to learn and most of it was created to support the APIs.

share|improve this answer
up vote 2 down vote

Memory Management, the HIG and what EXC_BAD_ACCESS/Objc-class-ref-to-ClassName in ObjectFile.o mean.

share|improve this answer
So what do they mean? – James P. Wright Jan 20 '11 at 22:06
It's a secret. Well, the second one means "you forgot to add a framework" and the first one is usually something memory related (accessing an object since deallocated, etc). – Alan Zeino Jan 20 '11 at 22:10
up vote 2 down vote

Everything is pre-emptively multithreaded. Everything.

You can and will be interrupted in the middle of everyone of your damn functions, usually by the user tilting the screen or tapping somewhere, or from an incoming phone call. Plan for this, test for this, expect to get any message in any state. Handle programmatic interruption gracefully.

Write re-entrant, well-defended code. Don't assume you know what the state of the screen is at any minute. Stay away from interaction designs that include tasks that can't be interrupted.

share|improve this answer
up vote 1 down vote

Usability

In my opinion Usability is most important!

share|improve this answer
up vote 1 down vote

Memory management and the rules of object ownership:

Mine go something like this:

  • An object which creates another has the responsibility to release it (i.e. autorelease or release depending on circumstances).
  • Any object which uses/holds on to another should retain it.
  • Be aware of cyclic dependencies (which is usually due to poor OO design).

The more you use the design patterns of Delegation, KVO and MVC in your code, the better your code will integrate with Cocoa Touch API.

Understanding bindings are also very important to implement KVO properly.

share|improve this answer
up vote 0 down vote

Get ready to rework stuff with every iOS update. Our experience has been that even after following all the rules and passing the submission, Apple will do something to every new release that tweaks the rules just enough to break something in some really weird way...

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.