7 ms·

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

62 points by Cacti 16y ago

js2 16y 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 16y ago
Huh. "Page not found Sorry, the page you were looking for in the blog Dev-P does not exist."
- kmfrk 16y ago
  Works here (now). Chrome, Windows 7.
- albertogh 16y ago
  http://printful.com/mirrorizer/ http://printful.com/mirrorizer/ It will check the referrer and redirect you to the mirrored copy of the linked article.
albertogh 16y 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 16y ago
  Hrm. Thanks, I'll look into it and correct it. I could have sworn it was necessary at one point...
octopus 16y 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 16y 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.
Xuzz 16y 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 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 16y 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 16y 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.
    - nomurrcy 16y ago
      I find that I used to do most of my work without nibs and do it in loadView. In recent releases I've been using xibs for a lot of the base layout and doing the rest in viewDidLoad. 99% of the time you can create most of your interface in IB and save yourself a bunch of time and make it more maintainable.
    - wallflower 16y ago
      > 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).
kentosi 16y 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 16y 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.
  - AGorilla 16y ago
    You can be curious about something without expecting a specific outcome.
- marksands07 16y 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.

62 points by Cacti 16y ago

js2 16y 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 16y ago

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

kmfrk 16y ago
Works here (now). Chrome, Windows 7.
albertogh 16y ago
http://printful.com/mirrorizer/ http://printful.com/mirrorizer/ It will check the referrer and redirect you to the mirrored copy of the linked article.

albertogh 16y 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 16y ago
Hrm. Thanks, I'll look into it and correct it. I could have sworn it was necessary at one point...

octopus 16y 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 16y 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.

Xuzz 16y 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 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 16y 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 16y 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.
  - nomurrcy 16y ago
    I find that I used to do most of my work without nibs and do it in loadView. In recent releases I've been using xibs for a lot of the base layout and doing the rest in viewDidLoad. 99% of the time you can create most of your interface in IB and save yourself a bunch of time and make it more maintainable.
  - wallflower 16y ago
    > 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).

kentosi 16y 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 16y 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.
- AGorilla 16y ago
  You can be curious about something without expecting a specific outcome.
marksands07 16y 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.