

Creating an iPhone App From Scratch (sans Xcode/IB) - Cacti
http://lambdadevp.blogspot.com/2010/11/creating-iphone-app-from-scratch.html 

======
Xuzz
Does anyone actually use Interface Builder for serious iPhone development? I
find the lack of control it gives you infuriating, especially when the fix
would be only a line or two of code. I've seen some larger projects that use
it when looking through the filesystem, but I've always wondered how they
manage with all of its quirks.

Anyway, for an easier solution for Xcode-less iPhone development, I'd check
out Theos by Dustin Howett (<https://github.com/DHowett/theos>). It's a set of
makefiles (mostly used for jailbroken app development), but it uses the same
tools and methods as Xcode and the binaries it builds are perfectly fine for
the App Store.

~~~
runjake
I'm confused by your comments.

Interface Builder is pretty much a must-have for serious iOS developers. Of
course, you may have your neckbeards that like coding XIB files by hand in
vim, but they are the exception.

I can see XCode being optional, though.

Edit: I didn't downvote you. I'm curious about your stance.

~~~
milkshakes
Interface Builder is definitely not a must have. In many cases, it just gets
in the way. You can easily override loadView and create your views by hand. In
fact, for most of the good stuff, you _have_ to do this.

~~~
wallflower
> In fact, for most of the good stuff, you have to do this.

IB's biggest benefit is we can have our artists skin apps and check in the XIB
- no programmer needed. This is very important once you start creating
platform type apps. Skinning can be a very time consuming process; IB makes it
more manageable.

To clarify what milkshakes is saying, IB stops being useful when you are doing
custom animations (e.g. moving subviews around - something that is very common
if you have a custom animation). Usually, IB will beat a developer coding
CGRect type code from scratch (unless they are using Opacity - a great tool
that generates code and is very programmer friendly). A custom UIView will
probably win the performance race but lose in the productivity/maintenance
marathon.

Once you start getting into custom rounded table cells, custom table headers
that act as row 0 of the table cell, empty placeholder cells, CoreData, and
table/cell animations - you are entering the dark side...

Using IB for UITableViewCells doesn't have a significant performance penalty
now because if you are doing custom cells - the client is probably willing to
sacrifice 60fps scrolling - to get their custom table gradients/cell
backgrounds (otherwise the cells would be opaque).

------
octopus
Nice approach, I've always believed a coder should be able to code an
application from scratch.

I wonder if on a long term your workflow is not too time consuming. We use
Xcode to avoid writing each time the necessary boilerplate code that is
repeated from application to application. I don't think this can be the way to
go for a team of coders for example, for a single coder it could work.

Again, nice example of going to the source.

~~~
aerique
If you have boilerplate code that's repeated from app to app you only have to
rwite it once, right?

At least that's what I do when developing on a jailbroken iPhone. I don't
start from scratch every time.

------
kentosi
I commend your efforts.. but no screenshots? I'm curious to see whether it
turned out to look the same as it would have using IB.

~~~
Groxx
Why in the _world_ would you expect it to look differently? They're not
writing a new UI framework, they're just using it outside of IB. The same
controls will look the same whether you wire them up in IB or in Obj-C.

------
ScottWhigham
Huh. "Page not found Sorry, the page you were looking for in the blog Dev-P
does not exist."

~~~
kmfrk
Works here (now). Chrome, Windows 7.

------
js2
plutil can be used to convert a plist between XML and binary formats (tried to
comment on the blog directly, but the commenting didn't seem to work)

------
albertogh
There are some errors in there:

    
    
         // The UIApplicationDelegate protocol requires you implement this function. 
         // It will return our main UIWindow so the application (UIApplicationMain from main.m) 
         // knows where to start.
         - (UIWindow *) getMainWindow;
    
    

That's simply not true. There's no reference to getMainWindow in the Apple
docs nor in UIKit, I've just examined the binaries. In fact, Apple's
conventions state that getter methods don't have the "get" prefix, so if it
existed it would be called just "mainWindow".

~~~
Cacti
Hrm. Thanks, I'll look into it and correct it. I could have sworn it was
necessary at one point...

