

How to Write Good iOS Apps - AshFurrow
http://coffeetimerapp.com/index.php/2011/09/how-to-write-ios-apps/

======
wallflower
The article was good in breadth but lacked depth.

For deep-dives into the nitty gritty of Cocoa Touch, we've learned minute
important details from digesting countless hours of WWDC videos that make all
the difference.

<http://developer.apple.com/videos/wwdc/2011/>

Especially the perennial classic, "Designing Apps with Scrollviews"

~~~
adeelk
In case anyone else is looking for “Designing Apps with Scroll Views”, it's
actually from WWDC 2010: <http://developer.apple.com/videos/wwdc/2010/>

------
DrJokepu
"Seriously, it'll be worth it not to learn about manual memory management."

This is not true at all and it is a very dangerous suggestion. Automatic
Reference Counting indeed makes memory management an awful lot simpler (often
you don't have to do any explicit memory management at all with it) but you
still need to learn about it and understand it, otherwise all sorts of bad
things will happen like memory leaks due to circular references (delegates
come to mind) and crashes due to the autorelease pool high-water mark eating
up all the memory on iOS devices.

~~~
SeoxyS
Even if you're going to use a technology to avoid dealing with manual memory
management, it's critical to learn it anyway. It's such a fundamental and
important part of Cocoa development, not only because of how important it is
to making efficient apps, and to not crashing, but also because you need to
understand concepts and conventions of ownership in Cocoa. You need to know
what you're doing when you're casting CoreFoundation and Foundation types. You
need to know what a pointer is, know what a dangling pointer is, know how you
can pass a pointer to a pointer to get a second return value from a method
(`NSError __`[1] is a pretty common Cocoa convention). Know what a singleton
is.

And after you've learned all of this, you can also do some really neat things
with Cocoa's dynamic runtime. Things like invocation building using a category
and code like this (or similarly, store and queue up actions on the Mac's Undo
manager):

    
    
        [[NSInvocation invocationBuilderWithTarget:self] aRandomMethod:arg];
    

Once you understand memory management, you can start using blocks, and even
storing blocks. You need to understand how copying a block retains every
object in the stack, and why raw type variables become immutable in a block.
Then you can start to really have fun with awesome powerful technologies like
Grand Central Dispatch.

Also, in Objective-C you should _never_ user the Garbage Collection feature.
And Automatic Reference Counting, while _awesome_ , is not production-ready
yet. Apple will not approve apps with it yet—I know, I've been rejected for
trying to use it in an app.

[1]: HN's markdown parsing is a little funky, this is meant to say:

    
    
        NSError**

~~~
AshFurrow
"Also, in Objective-C you should never user the Garbage Collection feature."

Why not? On the Mac, the garbage collection process is offloaded to another
CPU. Any performance hit is more than made up for the fact that developers
probably messed up the retain counts.

Memory management is a thing that you have to get perfect or your app will
crash. I personally trust ARC or GC more than I trust myself.

~~~
cpeterso
iOS's Objective-C doesn't support garbage collection. iOS 5 will add support
for Automatic Reference Counting, but no real garbage collection. So if you
are writing cross-platform Objective-C code that must support iOS devices and
Macs, then you can't rely on garbage collection. And if you must support iOS <
5, then you can't rely on Automatic Reference Counting either.

~~~
shadowfiend
Not quite right. There is some support for ARC for iOS 4 (that is bundled with
the compiled app). Some more at
[http://stackoverflow.com/questions/6308425/ios-5-best-
practi...](http://stackoverflow.com/questions/6308425/ios-5-best-practice-
release-retain) .

------
gmac
Disappointingly obvious? In summary: learn, somehow, how the major APIs work,
and then use them.

------
robjohnson
The new big nerd ranch iOS guide 2 is phenomenal. I should have read it before
writing my first 4 apps through trial and error.

~~~
kenjackson
I've heard really good stuff about their in-person training too. I'm actually
a big fan of the intensive in-person training. It's expensive, but I've found
it to actually be worth it (for professional work at least).

------
chromium
I lost it at "If you don't want to make your apps intuitive and easy to use, I
hear OpenOffice is looking for some Java developers."

Hilarious, great article.

~~~
Apocryphon
I also enjoyed "...which is in turn rendered by OpenGL, which we don't care
about because we don't hate ourselves."

~~~
leon_
Though it would be nice to have some understanding of OpenGL. It's gold worth
if your UI runs sluggish and you try to fix that. Understanding how OpenGL
handles things helps a lot.

------
sqrt17
> No, wait. Yes I am. I taught a course at my university on the topic.

Teaching a course seems to be an excellent way to learn the basics. It does
not make you an expert, though - that needs a couple years of practice.

------
dpcan
Whatever. Life is way too short for some of us. Sign up for the Corona SDK and
just have fun.

Creating good apps has nothing to do with the tools you use, it is how you use
them ... And more importantly than that, knowing how to design, polish, shine,
and pay attention to detail is what makes a good app. Maybe adhering to some
standard UI styles and layouts as well.

EDIT: Wow, I'm bummed that this is getting down-voted. Maybe reply with WHY
you are down-voting because developing GOOD apps in Corona is much easier than
the route described by the author of this post.

~~~
tomjen3
Corona is five different flavors of awesome. If you want to write 2d iphone
apps with 2d physics.

If you don't want to, you will have to look elsewhere though.

~~~
dpcan
That's not true.

Now you can develop for Android AND iOS with Corona, plus, you can use their
Native UI API to create actual apps with Corona, not just games:

<http://developer.anscamobile.com/content/native-ui>

Check out their showcase:

<http://developer.anscamobile.com/showcase/>

I'm not affiliated with Corona other than that I'm a subscriber and developer
who uses Corona and loves the heck out of it.

~~~
comex
Not to be too negative, but out of the 15 apps in the showcase, the only three
that are not games and have a native looking UI are:

Canyon County National Parks - looks good, but scrolling is noticeably non-
native in several ways, and the app is oddly slow sometimes

Drum Toy - takes forever to load, ugly sliders

iSleepWell - UI is confusing and difficult to use (tap areas too small)

------
bobbles
Considering the attitude towards testing in this article.. How much would
someone generally pay for say a testing consultant to test their app for them?

~~~
ecito
depending on the size of the app, anywhere from $10 to $50 for a complete
regression test and useful feedback on the app. I've never paid anyone though
as it's easy to get friends to beta test

~~~
stevederico
Where can you get testing like this? Is there a site or service available?

~~~
Apocryphon
Some good automation frameworks are FoneMonkey and KIF

------
coreycollins
The one thing I would recommend people do is not use Interface Designer. It
bloats your code base and adds more complexity to the view hierarchy. It might
be good to quickly mock-up a prototype, but not much else.

~~~
gte910h
I am a full time iOS dev: I cannot imagine professionals who completely avoid
interface builder.

For _some_ screens, it is certainly faster and easier to programmatically
build them up, but for the vast majority of screens, your comment seems to
tell more about a willingness to learn than a desire to make good apps.

Perhaps you stopped trying to use it during the Xcode3 days? Now, almost any
hairs it did have got shaved off in the Xcode3->4 transition.

I'm not saying use it for _all_ adjustments to views, sometimes those go
faster in code, but it is by far the better way to do almost every view.

~~~
coreycollins
I admit I did stop using it during XCode3. I got so use to it I haven't yet
used it in XCode4. I meant it more as a better way to understand the iOS view
hierarchy, not necessarily the faster way to build apps. But building faster
apps doesn't make them better.

~~~
gte910h
If you do the exact same amount of functionality in a shorter period of time,
it frees up that time to then go make another part better. More features. More
testing. Faster Release. More documentation. Accessibility features.

If you prefer to boil each grain of rice separately for a pilaf, and it tastes
the same at the end, you just wasted a lot of time in the kitchen for no good
reason other than you've not stopped and learned how to boil them all at once.

Try the new Xcode4 book: [http://www.amazon.com/Xcode-Developer-Reference-
Richard-Went...](http://www.amazon.com/Xcode-Developer-Reference-Richard-
Wentk/dp/111800759X/ref=sr_1_1?ie=UTF8&qid=1314973883&sr=8-1)

It goes into IB's newest incarnation. IB is also fantastic when adding
assecessability functions to your app. Another reason to add accessability
functions to your app (beyond being a good human being who lets not-fully
sighted people use your app) is that it allows kif to work:
[http://corner.squareup.com/2011/07/ios-integration-
testing.h...](http://corner.squareup.com/2011/07/ios-integration-testing.html)
(play the video).

I'm not a IB Zealot, I make views manually when it makes more sense to or IB
is just not doing it's job with any speed, but "0" is not the amount anyone
should be using it who makes non-game apps.

~~~
coreycollins
Your analogy doesn't really apply since you still have set the properties in
Interface Builder. It's more like i'm just using a different stove. It does
some, but not all. And most of the steps it does do are default for the class
anyway. I like the finer grained control. If you're used to it the time
difference is negligible.

~~~
gte910h
>It's more like i'm just using a different stove.

Sure: <http://www.goodtimestove.com/>

Modern
constraints([http://developer.apple.com/library/mac/#recipes/xcode_help-i...](http://developer.apple.com/library/mac/#recipes/xcode_help-
interface_builder/AutolayoutUnderstanding.html)), for instance, are insane to
edit manually with no visualization on any complicated screen.

Perhaps you're just building tons and tons of tableview cells or something
else automatically laid out for you, so you're not really feeling it (or are
too strident a believer of your position to learn then judge, rather than
judge first). But if you do any manual layout at all, there are huge wins
within days of starting to learn the tool.

It feels like I'm discussing with someone contending that zip files are as
good as source control here.

~~~
coreycollins
Were talking about iOS and the Interface Builder, not MacOS. I do not develop
apps for the Mac, but I agree using Interface Builder would make sense for
"larger" screens with more ui elements. To be clear I used Interface Builder
for over a year until I decided it was better for ME to programmatically add
ui elements.

~~~
gte910h
[http://developer.apple.com/library/ios/#recipes/xcode_help-i...](http://developer.apple.com/library/ios/#recipes/xcode_help-
interface_builder/AutolayoutUnderstanding.html)

Is the iOS link to the same article. I just hit the wrong one in google.

>The one thing I would recommend people do is not use Interface Designer. It
bloats your code base and adds more complexity to the view hierarchy. It might
be good to quickly mock-up a prototype, but not much else.

Is the issue. If you yourself wish to do things a different way, that's fine,
but it should be clear to people that this is a you thing, not a thing that's
really accepted by anyone much who does this. Have fun not using it, it's
fine, I'm not working with you in particular.

------
innes
_Go mess with MonoTouch or whatever if you want. Then go grab a fruit roll-up,
think about what you did, and realize you should have just learned
Objective-C._

OK, but _why_?

 _Seriously, it'll be worth it not to learn about manual memory management._

I'm confused - MonoTouch presumably has garbage collection, but Objective-C
lets you 'not learn about manual memory management'. What's the deal?

~~~
ianbishop
_Seriously, it'll be worth it not to learn about manual memory management._

I believe he's making reference to the inclusion of automatic reference
counting in iOS 5.

~~~
AshFurrow
Exactly. That's why you have to pay the $100 for the dev license - to get
Xcode 4.2 beta.

~~~
innes
Ahah. So the mention of MonoTouch is a red-herring? Weird.

EDIT: @tptacek What confused me is there's no reason given to avoid MonoTouch,
so I latched onto the memory management comment, to try and make sense of the
text.

~~~
tptacek
No, you're conflating two different points he's making. The MonoTouch jab
isn't about memory management.

