Trying to compile a list of "Should Know's" when it comes to programming iOS

Cocoa Core Competencies:
https://developer.apple.com/library...ceptual/DevPedia-CocoaCore/Accessibility.html

I don't think I could select a "top 10" from what's there, because restricting it to only 10 would leave out some essentials.

 

I would probably ditch ARC / auto release - knowing the right property modifiers is good enough 99% of the time (and not even knowing those is good enough ~75% of the time.)

Something important for your checklist is auto layout, storyboard, and collection / table views.

Are we talking about for hiring a developer? I'd want to focus less on Obj-C and more on programming. Can/do they unit test? Can/do they use source control? Can/do they use debuggers? Can/do they comment?

I ask can/do because just knowing how doesn't actually mean they understand the value and do it.

 

It's true that you can write code to accomplish anything Storyboards and XIBs can do. By the same token, you could use CoreFoundation instead of Foundation. You wouldn't do that, though, because it's often more productive to use Foundation (although once in a while you might want to use a CoreFoundation data structure which lacks a Foundation equivalent.) Similarly, people should know how to use Storyboards. If a task can be done with either a Storyboard or through code, it'll be simpler and quicker to do it with the storyboard. And if you're intimately familiar with them, you'll know the extents of what they can do and know when you need to switch over to coding because the behavior you want is too unique (which should raise some flags about your UX. Is it unique for a good reason, or should you be doing something that's more standard?)

 

Re: storyboards

What a developer should know is that there are multiple ways of doing some things. So instead of banging their head against that one way, they can try an alternative.

If a storyboard or auto-layout set-up is too convoluted for their app's UX, they can plop down some custom jumping object in code. Or vice-versa.

----------

Nonsense. Humans can't consistently keep more than 9 things in mind, so unless you prioritize, you are probably making a mistake in the most important thing.

 

Even more reason number 1 in the top ten should, learn how to use the documentation.

Understanding @protocol would be pretty high on my list as well. Not just to for Delegates but as a class extension method an alternative to subclassing.

 

I'd love to see this be incorporated into an interview. And seeing as I sometimes am on the other end of the interview table, I'll be sure to start mixing it in.

 

Understanding the concept of a runloop helps immensely when it comes to how / when one should dispatch task in threads.

Asynchronous programming in an event driven App model is what provided the biggest leap in understanding how iOS should be programmed.

(Wow, that sentence sounds cheesy, anyways ... I mean it)

Forums are full of questions about why performance sucks, or how they "draw" incremental content on screen, because it's hard to understand the event driven nature of an App.

Once I got my head around this, my code improved a lot.

Dispatching results back on the main thread, queuing up image operations in bitmap context or similar is so important.

Read about GCD, Blocks and all the other good stuff that really can improve your App a lot.