Creating an iPhone App From Scratch (sans Xcode/IB)

http://lambdadevp.blogspot.com/2010/11/creating-iphone-app-from-scratch.html

by Cacti • 15 years ago

62 23 15 years ago

lambdadevp.blogspot.com

js2• 15 years ago

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)

ScottWhigham• 15 years ago

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

kmfrk• 15 years ago

Works here (now). Chrome, Windows 7.

albertogh2• 15 years ago

http://printful.com/mirrorizer/

It will check the referrer and redirect you to the mirrored copy of the linked article.

albertogh2• 15 years ago

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• 15 years ago

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

octopus• 15 years ago

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• 15 years ago

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.

Xuzz2• 15 years ago

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.

runjake2• 15 years ago

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• 15 years ago

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.

Xuzz2• 15 years ago

I don't hand-code XIB files: I don't use XIB files. I do use Interface Builder for laying out a basic UI design, it's much better than sketching it by hand.

But when it comes to code, it's much easier to have everything in once place. Override -loadView on your UIViewController subclass, and create the views right there. Sure, grab the frame dimensions from IB, but when you create it in code you have full control of how it works. There's no magical linking of the right nib to the right view controller. There's no "outlets" that work most of the time -- except, and I've had issues with this, in a few methods where they don't. There's no almost-but-not-fully-correct parsing of your source code looking for the "IBOutlet" markers, and there's no custom UIView subclasses that you have to make in code anyway, because IB doesn't support configuring them.

Basically, similar to this line from the Zen of Python: "Explicit is better than implicit."

marksands072• 15 years ago

In all honesty, the only reason why I don't use IB is because I'm too lazy to learn how the advanced functionality and customization actually work. Besides that, I always end up wasting too much time trying to figure out why the app won't build because I forgot to ctrl+drag an outlet to the File Owner or something silly. I'm insanely faster at building the UI when I code by hand so I choose that over IB.

xsmasher• 15 years ago

It's essential when working with artists and UI designers. I'd rather have the coders coding and the UI guys laying out / lining up the UI.

sambeau• 15 years ago

As a UI designer, there are few things more soul-destroying than having to ask a coder every time you wanted to move something by a pixel or replaced with something that (to them) looks identical.

My gripe with IB is that it is beginning to look long-in-the-tooth: it lacks many of the modern layout tools you might expect: zoom, show/hide layers, lock, align-just-these-together. IB could do with taking features from a vector art package (without becoming too-much like Expression Blend).

nika• 15 years ago

The Phases of Interface Builder:

newbie: Whoa! I can build a UI without writing any code? Cool!

novice: Damnit, why isn't this working right? IB Sucks. It must be IB's fault!

junior: Ah, to hell with it, I know enough code, I can just write all my views in code. TOTAL Powah is MINE!!!

journeyman: Locilawhat? Whoization? Whatever, I am tired of having to recompile and constantly change dozens of off-by-a-pixel issues in code. Maybe Interface Builder can be used, but I'll keep it on a short leash.

enlightenment: Interface Builder vs. code? You kids, you gotta, like, embrace the duality of the universe, man... everything in balance... feel it until you don't know where interface builder ends and code begins.... and anyway, its code all the way down, man! Have you got a light?

More seriously, there's a period where you feel like you're fighting interface builder all the time... and once you get past that, you use it where it makes sense and code where code makes sense. The app I'm working on today, the UI is done completely in interface builder, and it has saved a whole lot of time, though animations and stuff like that are done in code, of course.

headhuntermdk• 15 years ago

We use IB for most things and actual code for very specific things. Make things much easier when you are dealing with localization when you have to adjust text elements due to translation. "The best code you can write is the code you don't write" or something like that

kentosi• 15 years ago

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• 15 years ago

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.

marksands072• 15 years ago

I'm with Groxx. You do understand that IB is not necessary for iPhone development, right? I fear a lot of people go into iOS development with that notion in mind and it's simply not true.

Creating an iPhone App From Scratch (sans Xcode/IB)

Related Stories