Use Interface Builder or not?

[beeh]

I've been using Interface Builder for my apps so far and have found it not so bad, although took some time to get used to how to connect graphical objects to the code. But, many of the examples ( well all of them really ) show code that does not use IB, but defines all the graphical objects in the code.

In all of the code I have done, I have always leaned towards not using tools like IB, but, as I mentioned before, I have been trying to use it, because it seems helpful.

Now, that being said, from all the experienced Xcode developers out there, is it better to use IB or not? Any feedback is appreciated.

[liptonlover]

I hate IB. Don't get me wrong, it's great. It is sooooo helpful. But I hate hate hate hate hate anything that makes coding easier. Because the more of that you do, the less writing you have to do, the easier it is for any old kid to pick up some tools and "generate" the same thing I spent days coding by hand. I think programming should be purely code writing. But, since people insist on creating tools to make it easier, I'll use them. No sense in being left behind... So yeah. Use it. It's very useful.

[hayesk]

I hate IB. Don't get me wrong, it's great. It is sooooo helpful. But I hate hate hate hate hate anything that makes coding easier. Because the more of that you do, the less writing you have to do, the easier it is for any old kid to pick up some tools and "generate" the same thing I spent days coding by hand.

That's an elitist attitude, don't you think? This same line of reasoning was used against desktop publishing, digital photography, and countless other industries.

Not to mention there are many "good" programmers that can code very well, but can't design a user interface to save their lives. IB lets good UI designers and good programmers work together to make better software.

In my opinion, anything that puts tools in the hands of more people is a good thing. If you truly are a good programmer, your apps will shine through as the crap gets weeded out fairly quickly.

[robbieduncan]

I find IB really useful when programming for Mac OSX, but for some reason I just can't get with it for the iPhone. I'm just doing it all in code. Only takes a few minutes to get the interface I want...

[kainjow]

I started out writing all the UI in code but that was when IB was really weak for iPhone development. It's gotten a lot better though but still I find it a bit confusing even though I've been doing Cocoa for a while. It gets tiring writing UI code all the time by hand, so IB helps out a lot.

[richard.puckett]

I've been wanting to ask this question, myself. Good to see some opinions.

In my own experience (which isn't much yet relative to many on here) is that I've been using IB less and less. I still use it when I need to lay out some UI components in a certain way - but even then, the simulation cycle is so fast that it could be manually tweaked in code at roughly the same rate.

The iPhone also makes use of more high-level components (like the nav bar) and generally has a simpler UI so it's often easier to describe the interface in code than it is for other mobile platforms.

The IB seems like a really nice solution to a problem that doesn't so-much exist in the first place.

[jeremy.king]

If you don't use IB, do you still create XIBs (I would assume by hand)?

I noticed after download the Wordpress source that the UI components in the xib didn't even seem to be laid out. :confused:

[liptonlover]

@ kingjr3 - No... you would just create objects in various classes you've created. Have you ever created an NSString instance in code? It'd be just like that, only you'd also have to use methods to set the title, size, location, and all sorts of stuff like that that IB makes easy.

I think anything good should be hard to make by default. I "wrote" an app, not very good but a working app that's useful for some people, and I did it all in IB and with a core data model. Not one bit of coding. And it only took about 10 minutes. How is that right? I didn't even work! Anyone could have done it. I don't know... I may just have a problem but it still doesn't seem right.

[PhoneyDeveloper]

liptonlover, if that's your real name. :confused: I think you're just giddy because the NDA has been lifted. :D Stop showing off. I think it's clear that all the IB-haters have no sense of humor. :eek:

I have ten minutes free. I think I'll go write monkeyball II using IB. :p

[t0mat0]

liptonlover, if that's your real name. :confused: I think you're just giddy because the NDA has been lifted. :D Stop showing off. I think it's clear that all the IB-haters have no sense of humor. :eek:

I have ten minutes free. I think I'll go write monkeyball II using IB. :p

Any chance of updating Kroll whilst you're at it? :D It needs a bit of non-linear play to it

[admanimal]

I think anything good should be hard to make by default. I "wrote" an app, not very good but a working app that's useful for some people, and I did it all in IB and with a core data model. Not one bit of coding. And it only took about 10 minutes. How is that right? I didn't even work! Anyone could have done it. I don't know... I may just have a problem but it still doesn't seem right.

Why not use IB anyway and use your super skills and the time you saved to add other awesome features that the average joe can't think of and/or implement in 10 minutes?

[cemorris]

I have an application in the works and have been using IB. After creating about 20 screens, I now have a dilema. What if I want to change the look and feel across my entire application. With IB, I need to go into every screen and make the same changes. Where as in code, I can simply use a global variable to make one change everywhere. Anyone have a good solution for this problem? Thinks makes me think I should have done everything in code.

[admanimal]

I have an application in the works and have been using IB. After creating about 20 screens, I now have a dilema. What if I want to change the look and feel across my entire application. With IB, I need to go into every screen and make the same changes. Where as in code, I can simply use a global variable to make one change everywhere. Anyone have a good solution for this problem? Thinks makes me think I should have done everything in code.

Keep in mind that you are still free to use code to change the properties of objects you create in IB, and you can add other objects to views you create in IB. So if you are just talking about changing a color or adding a button or something, you can still do that in code and have everything else done with IB.

[firewood]

Note that from code, you can still hide, redisplay, or change any IB objects at runtime.

[liptonlover]

:rolleyes: you guys are making something serious a joke... I know you get what I'm saying lol. Sure you're not going to write monkey ball 2 easily because of IB, but you get the point. And you could do it with one of those game engines. IB really isn't the biggest problem I have at all, it's mostly the other stuff. But why be exclusive? :D But whatever... it doesn't matter anyways. And I'm not giddy about the nda, actually. It hasn't affected me yet and now it never will, fortunately :) But I am happy that they are lifting it.

[firewood]

In practice, I've found that any complex or rich iPhone application will have so much in code that the little bit saved by using IB is almost unnoticeable. (e.g. I don't do tip calcs).

So I might still mock-up a dummy of a UI in IB before sending the screenshots off to a graphics artist for final production polish. But now I mostly just use IB to generate the bare window and view xibs, and do everything else in code, especially so that I can control and modify the UI elements at runtime, if needed, with everything about these elements in searchable text files.

.

[wizard]

Really! Now I'm new to Mac and iPhone programming but to be perfectly honest I don't have a grasp on IB at all. Nor do I want to know why Apple came up with such a confused app as that.

Of course being that my first exposure to IB was with respect to iPhone programming that didn't help. Maybe a good tutorial and a bug free app would have changed my mind but it looks to me like Apple went out of it's way to make IB difficult to use.

Honestly if Apple wants to have a graphical interface builder it needs to be tied in better with the IDE. Right now IB really seems to be a negative with respect to rapid development on iPhone. It can be much faster to simply code everything up in one place, with IB code is all over the place.

All in all I don't really like IB right now. I just find it to be a very foriegn and abstract way to accomplish anything. It might grow on me in the future but right now I simply rely on sample Apple code and building what I need out of code.


Thanks dave

[Taum]

Hi,

Honestly if Apple wants to have a graphical interface builder it needs to be tied in better with the IDE.
No, seriously, it doesn't. I agree that IB for iPhone is confusing, but it's not about being tied up with XCode. IB for the Desktop is much more straightforward to use IMHO, but isn't any more tied up into XCode.

I think the main problem with IB for the iPhone is that the ViewController paradigm doesn't work so well in IB. I hope this will mature with the next release : keep in mind that IB for the desktop has been there since the NeXT days, if I'm not mistaken (for that matter, I wasn't even *born* then :D).

There is also a clear lack of tutorials on how things are supposed to work with IB, which might just start to get better since the NDA is getting lifted. It wasn't obvious at all for me how IB was supposed to work for Cocoa apps until I saw a few video tutorials... and then I felt like I could never go back to hand-coding a UI. I guess it will be the same for the iPhone.

[liptonlover]

hmmmm is it really confusing for you? It may just be because I was already a programmer and had used IB for the mac before checking out the iphone sdk, but I thought it was easier than the mac ib stuff. Then again, I don't use it except to lay out the interface, or at least the way it'll start, and to do some connections. I usually have an AppController class, so I just make an instance of that in IB. That's the extent of my use.

[CPlusPlusMan]

I hate interface builder because in order to make the interface relatively easily.... you HAVE to use IB... apple will not give you a choice. I think it's great that I can make my apps in a graphical environment.... but It feels really childish to do so... I learned how to program because I wanted to be a programmer.. someone who types in code and makes applications out of code... not crayons. I wanna be a programmer.... not a two year old. sometimes it's worth it to save the time and build the interface in IB, but most of the time I wanna see a list of those connections in a file, see the layout objects and see the widget objects. I want a text file listing those things which I edit to change how my application looks and behaves... I wanna hand code it. because that's what I am comfortable with... that's what I signed up for... not IB crayons.... it's BS and apple needs to make an easy way to hand code interfaces... and it's not like they can't, because Qt proves you can.. using C++ no less... and that's only one of the things that the whole dev environment has that really pisses me off.... among a lot of other things.
I just think it's stupid!!!!!!!! Give me some real coding damnit! oh well.
Apple hates it's devs and especiallly devs who use something other than Obj-C (like C++ devs, apple's favorite.

[CommanderData]

I hate interface builder because in order to make the interface relatively easily.... you HAVE to use IB... apple will not give you a choice. I think it's great that I can make my apps in a graphical environment.... but It feels really childish to do so... I learned how to program because I wanted to be a programmer.. someone who types in code and makes applications out of code... not crayons. I wanna be a programmer.... not a two year old. sometimes it's worth it to save the time and build the interface in IB, but most of the time I wanna see a list of those connections in a file, see the layout objects and see the widget objects. I want a text file listing those things which I edit to change how my application looks and behaves... I wanna hand code it. because that's what I am comfortable with... that's what I signed up for... not IB crayons.... it's BS and apple needs to make an easy way to hand code interfaces... and it's not like they can't, because Qt proves you can.. using C++ no less... and that's only one of the things that the whole dev environment has that really pisses me off.... among a lot of other things.
I just think it's stupid!!!!!!!! Give me some real coding damnit! oh well.
Apple hates it's devs and especiallly devs who use something other than Obj-C (like C++ devs, apple's favorite.

What are you talking about? You don't HAVE to use IB at all to make even the most complex applications and view layouts. It is very easy to code by hand... easier than screwing around with interface builder for me :D

Just start in applicationDidFinishLaunching and create your viewController (and NavigationController if necessary), create your window, create your views. In your views initWithFrame method you can code the layout of that view (buttons, text, subviews, etc). Of course people who use IB regularly will scoff at this and exclaim how difficult that would be, but it really isn't at all, and the control you have over everything is great!

[Taum]

No offense, but creating the objects in code does not give you any more control over things. It doesn't give you any less tho, so I agree with you: pick whichever you're more comfortable with.

For me IB is nice because I can create an interface as complex as needed, and only worry about what actually needs worrying in code. My controller classes are not polluted with components that relate only to the view.
Eventually I find IB really helps embracing the MVC pattern, which is kinda wicked :)


I learned how to program because I wanted to be a programmer.. someone who types in code and makes applications out of code... not crayons. I wanna be a programmer....
Great, then go write lines and lines of code.

No one said you had to use the hammer if you'd rather nail it with your bare hands....
Apple hates it's devs and especiallly devs who use something other than Obj-C (like C++ devs)
... but then, don't complain that it hurts :D

Besides, you're argument is plain stupid. Ever tried to do .Net with Java? Qt with Objective-C? It just wouldn't make sense, so why do you want to write Cocoa code in C++? (which, incidentally, is probably the easiest of these three examples).

[adamk77]

I don't understand this argument at all.

IB is great. You don't have to waste time aligning controls, pixel by pixel, recompiling and running it ad infinitum to see if you've got it right. It's a great tool.

There are instances where IB can't be used, or is impractical to use. Then I switch to doing it in code.

I sometimes even switch back and forth or mix the two depending on my mood.

I really hope CPlusPlusMan was making a joke.

[CPlusPlusMan]

What are you talking about? You don't HAVE to use IB at all to make even the most complex applications and view layouts. It is very easy to code by hand... easier than screwing around with interface builder for me :D

Just start in applicationDidFinishLaunching and create your viewController (and NavigationController if necessary), create your window, create your views. In your views initWithFrame method you can code the layout of that view (buttons, text, subviews, etc). Of course people who use IB regularly will scoff at this and exclaim how difficult that would be, but it really isn't at all, and the control you have over everything is great!

.... wait.... you can do that?... How'd you learn how to do that? can you show me?

[CPlusPlusMan]

I don't understand this argument at all.

IB is great. You don't have to waste time aligning controls, pixel by pixel, recompiling and running it ad infinitum to see if you've got it right. It's a great tool.

There are instances where IB can't be used, or is impractical to use. Then I switch to doing it in code.

I sometimes even switch back and forth or mix the two depending on my mood.

I really hope CPlusPlusMan was making a joke.

Learn Qt sometime if you know C++... in Qt, I can hand code the interface quite easily... literally you create objects of the controls, add them to layouts using methods and then nest the layouts and controls together to create a final interface which you then layout on the window... Qt handles all the pixels and everything like that for you and makes things look dead shmexy... I can do the same thing in an IB like tool but it preserves the programming tasks because while you can use the IB to manage signals and slots (just like IB with the connections) you can also do everything quite easily in code without a single ui file.... and it's actually fun... so much so that most Qt programmers just hand code the interface in Qt because it's not hard, and it's fun and easy. Admittedly, sometimes it's good to be able to lay out things in IB... but telling programmers not to program and instead use a magical tool where they do everything but define the controller class which has next to no real programming.... it's a joke! it's like saying "here... go to school and learn how to become the next Da'Vinci" and then after they graduate, when they go to practice their art in the real world, you say "here, use these crayons. you get nothing else unless you wanna do things the hard way" now granted, in IB your apps look as professional as hand coded if not better, but still... you learned how to program, I assume, because you like to write code... so why are you now so thrilled with a tool that makes it so you don't have to do what you love and studied sooo hard to learn how to do because you were that passionate about it.... It's madness! It's your passion all for naught.... yes I can go to visit any number of places around the country by flying there.... but that's boring, everyone goes places by plane.... I wanna go on a road trip... they're a lot more fun and I'll get a lot more out of the experience then if I just fly there... in the same way, I studied hard how to program in C++ and BASIC and Java and C# and C and Obj-C because I Love programming... I love sitting at my computer writing code... I hate how apple seems to think it's a good idea to take that away by magic so that the lazy programmers here who hate coding and would rather just be code monkeys for money who just wanna do the least work and claim to be a programmer can do just that... It's not fair and it's insulting to us who love our jobs as programmers... who love debugging our code because it's a neat puzzle for us... who love inventing, innovating, and doing new things that no one ever thought of before... Programming is Computer Science.... but it's also computer art... and I love practicing my art....and anything that tries to take that art away from my with some magical tool the prevents me from writing code I stand against as a programmer. so vehemently so that if I were to attend the cocoa bootcamp and I knew how to handcode my interfaces, I'd handcode my interfaces rather than use the damn Interface Builder.. because it's a chance to practice my art and show off my art... it's doing what I love and what I was created to do. Even if the teacher (in this case Aaron Hillegass) threatened to fail me for it, I'd still hand-code the interface. I was not joking and I'm not joking... I don't want apple taking that from me because it's more convenient for lazy pseudo-programmers who hate coding and want to do as least of it as possible. If that's really how you approach programming and the art you're supposedly so passionate about, then you need to get out of computer science and learn something else that you will feel passionate about, something you will want to do as much as possible. because if it's not coding, then you're not a programmer!

[CPlusPlusMan]

No offense, but creating the objects in code does not give you any more control over things. It doesn't give you any less tho, so I agree with you: pick whichever you're more comfortable with.

For me IB is nice because I can create an interface as complex as needed, and only worry about what actually needs worrying in code. My controller classes are not polluted with components that relate only to the view.
Eventually I find IB really helps embracing the MVC pattern, which is kinda wicked :)

that's great for you... I love MVC too... I'll make a view class with all my control widget objects and instantiate them in main, then I'll implement the right methods to pass the interaction on to the controller who can access the view class... I'll set it up in main and then we'll be off with a neat little gui application... You don't need interface builder to implement an OO methodology. all you need is a text editor, a dev system and the truth. I'm sorry for you that you aren't a skilled enough programmer to use MVC in pure code... really I wonder why you find it to be so great to avoid what you love... because IB makes it that much easier for you.


Great, then go write lines and lines of code.

No one said you had to use the hammer if you'd rather nail it with your bare hands....

not really an accurate analogy... I could go and get a hammer and nails and all sorts of carpenter tools and start building and doing what I love and what I'm passionate about, or I can hire a bunch of guys and get a bunch of postmodern tools to do all of it for me and sit on my ass... the second is easier yes... but it's not doing what I love at all.... It's just lazy and shows that I really don't love carpentry and am not as passionate about it as I claimed to be.


... but then, don't complain that it hurts :D

Besides, you're argument is plain stupid. Ever tried to do .Net with Java? Qt with Objective-C? It just wouldn't make sense, so why do you want to write Cocoa code in C++? (which, incidentally, is probably the easiest of these three examples).

I don't care if I can do Cocoa in C++... that would be painful. that's not my point... my point was that a Library written in a language which is not dynamic like Obj-C and Cocoa/Carbon was able to give programs an easy way to hand code interfaces in a non-dynamic language no less, for the mac.... Apple is not inhibited by a lack of capability or an impossiblity of concept... Apple is simply choosing not to provide programmers a way to be programmers and do what they're supposed to be crazy passionate about... Apple could do this with little effort given they're using a language that cocoa was built to run on. they just don't want to because they want everyone to use their lazy ass system invented in the 90's (IB). for more insight into my reasoning, see the above posts....

[CommanderData]

CPlusPlusMan, you're very passionate about your opinions. I think in my case I hate IB because I got started programming GUI applications using only text editors and the command line over 25 years ago.

I remember the novelty of getting a mouse for the PC in about 1985... no windows, no hard drive, nothing. I had to program an interrupt handler to listen for mouse movements. Then I got started writing a paint program, complete with pull-down menus that I saw from a certain gleaming new Apple product when I went to the museum of science a couple of years before. All of that was hand coded, because nobody was doing anything like it at the time on the PC.

Over a quarter century of this type of stuff gets in your blood. I can visualize the layout coordinates precisely, spacing between objects, offsets from the screen bounds, etc. Doing the math (whether base 10, binary, or hex) in my head all this time helps. Actually the iPhone kind of brings me back to the old days of coding where one guy could make something quite impressive, fun and/or useful working at home. And the optimization puzzles! How do I fit everything I want to do in this limited ram? How do I optimize this bit of drawing code to squeeze out the performance I want? Of course I started with systems with 1.5Mhz processors and 64KB of RAM, so it's not quite that bad... Good times :D

I learned how to work without IB after seeing how horrid and un-intuitive it was. I picked up bits and pieces as I went, because I was learning Objective-C at the same time. Now I am glad I did. How would I use IB to layout my current game? I couldn't. Everything is custom drawn images residing in various CALayers of the gameplay view. I suppose it might have worked for laying out my custom table cells or custom picker wheel items on some other views, but why bother linking any of my code into some black-box xib/nib whatever the heck they are when I can lay it *all* out in code and see it, understand it...

Try this starter tutorial for interface-hand-coders:
http://blog.mcilvena.com/2009/01/xcode-starting-point-for-iphone-hand-coders/

I would have liked to found this tutorial when I was learning to hand code views and things.

Oh yeah- no offense to anyone who actually likes IB or needs to use it , but I'm more than satisfied without it ;)

[Taum]

my point was that a Library written in a language which is not dynamic like Obj-C and Cocoa/Carbon was able to give programs an easy way to hand code interfaces in a non-dynamic language no less, for the mac...

Sorry but:
a) Would you care to explain exactly how Obj-C is not a dynamic language? (because apparently you think Qt's hacks to make C++ look like Java make it *so* much better).
b) Here you seem to be the one not clever enough to understand how to build your interface in code, as other have stated before it is completely possible.


I studied hard how to program in C++ and BASIC and Java and C# and C and Obj-C because I Love programming... I love sitting at my computer writing code... I hate how apple seems to think it's a good idea to take that away by magic so that the lazy programmers here who hate coding and would rather just be code monkeys for money who just wanna do the least work and claim to be a programmer can do just that... It's not fair and it's insulting to us who love our jobs as programmers... who love debugging our code because it's a neat puzzle for us... who love inventing, innovating, and doing new things that no one ever thought of before...
No, sorry but you love writing stupid MVC classes and glue-code. If you think it's the "hard work" and you're passionate about it that's fine, but you can't say it's something no-one ever thought of before.

The point taken by Apple is to design a full MVC architecture for you and let you write only the code which is relevant to your application. What you call "lazy" I call "clever". This way I can then call you the stupid code monkey who writes thousands of stupid lines of code for money :cool:

[adamk77]

I find IB to be very intuitive.

How much more intuitive can you get --

drag and drop controls and link it to a method?

[Aea]

Divulging from the question like everybody else.

I think the moral crusade against making programming easier is misplaced sentiment. Frameworks and Tools like IB haven't made programming any easier for the non initiated or those who want to get into the field with little effort in the long run at all. But they have made the lives of software engineers easier and eliminated a lot of the grunt work that now goes into creating more feature rich and useful applications.

[adamk77]

Divulging from the question like everybody else.

I think the moral crusade against making programming easier is misplaced sentiment. Frameworks and Tools like IB haven't made programming any easier for the non initiated or those who want to get into the field with little effort in the long run at all. But they have made the lives of software engineers easier and eliminated a lot of the grunt work that now goes into creating more feature rich and useful applications.

Very well put!

I agree wholeheartedly.

I understand the fixation people have -- a bit OCD, if you ask me -- for wanting to do something always in code because doing it in IB somehow makes them feel like they are an inferior programmer or make them feel like they aren't really programming. But IB is just a tool and a means to an end. You still must know how everything works under the hood. And I really have no sympathy for those who want to get into the field with little or no effort, so I don't really care about them.

[Jokode]

Well this forum got real busy! Im just replying to the original question...

Firstly Im still pretty new to xcode (~6months) so Im far from an expert, but personally I found IB to just confuse the issue. You mentioned in your question you dont normally use tools like IB - I was the same when I started so I gave IB a try (which many of the examples force you to do of course), but after struggling for the first couple of days with it I decided to give the pure code approach the same time and see how far I got.

I just found that coding the views and their relationship with controllers in code was more natural to me and I made much more progress.

I also found that doing it all in code gave me a good understanding of how everything works under the hood and as I was new to objective-c, this was a good thing!

So I guess I'm old skool and just prefer doing it all in code :) Thats my 2 cents anyways.

[CPlusPlusMan]

Sorry but:
a) Would you care to explain exactly how Obj-C is not a dynamic language? (because apparently you think Qt's hacks to make C++ look like Java make it *so* much better).
b) Here you seem to be the one not clever enough to understand how to build your interface in code, as other have stated before it is completely possible.



No, sorry but you love writing stupid MVC classes and glue-code. If you think it's the "hard work" and you're passionate about it that's fine, but you can't say it's something no-one ever thought of before.

The point taken by Apple is to design a full MVC architecture for you and let you write only the code which is relevant to your application. What you call "lazy" I call "clever". This way I can then call you the stupid code monkey who writes thousands of stupid lines of code for money :cool:

wow... way to still completely misunderstand me. Obj-C is dynamic... C++ is not... yet a library and compiler system has been created for all three operating systems in C++ (a non dynamic language) to interface a library that depends on the dynamism of Obj-C (cocoa) to function.

Secondly, I've found one tutorial through someone's gracious reference that illustrates how to make an iPhone app purely in code..... I want to do the same thing for regular Cocoa NS classes but I still have not found a single tutorial to that effect.

Thirdly, the gluecode in this case is one line.... I'm ok with that. at least I can at the beginning of my application after all the controls are set up, write a list of connections quite simply and it's in code.... at the very least... instead of being a magic part of a nib file that you can't see. It's annoying as hell and I'd rather be able to check every connection in a list in my code.

a code monkey just does what he needs to to make his boss happy and make applications and doesn't really care about the programming. they're not computer scientists. they're not engineers and they for the most part write terrible software.... it's stupid, and it takes all the fun out of making applications! and Apple needs to provide documentation on how to make the same apps purely in code. and it needs to open up it's system to other languages instead of being so ethnocentric about Obj-C. because really the syntax pisses me off because it's ugly and inconvenient as sin!

I'm sorry, but that's just the truth. Apple is trying to appeal to programmers who see their art form as a chore instead of their passion by making it easy to substitute paints and brushes with crayons and colored pencils. you can get quite artful with them, but they're just not the same! I want a palette and brushes... not crayons and colored pencils... I'm a computer scientist... a programmer God-damnit! and I wanna code because that's what I do, that's what I'm passionate for, and neither you nor apple are gonna make me feel otherwise!

[dejo]

I'm sorry, but that's just the truth.
No, it's just your opinion.
Seriously, dude, all this ranting is not endearing yourself with others here.

[Aea]

I'm sorry, but that's just the truth. Apple is trying to appeal to programmers who see their art form as a chore instead of their passion by making it easy to substitute paints and brushes with crayons and colored pencils. you can get quite artful with them, but they're just not the same! I want a palette and brushes... not crayons and colored pencils... I'm a computer scientist... a programmer God-damnit! and I wanna code because that's what I do, that's what I'm passionate for, and neither you nor apple are gonna make me feel otherwise!

In the real world, we tend to pull tested & tried APIs off the shelf and build our applications around, or using them. There's a little something called not reinventing the wheel.

[admanimal]

http://www.rentzsch.com/notes/programmersDontLikeToCode

I'm a computer scientist and a programmer. I don't like to write code; I like to solve problems. Yes, I can write 1000 lines of uninteresting UI code if I really want to but doing so is a pretty mechanical process that I would rather leave to Interface Builder. I get no joy from writing interface code because there is nothing special going on with it; it's all just setting a bunch of properties. I get much more satisfaction out of doing something clever with my code, even if it's just a few lines or involves calling a lot of library functions that someone else wrote for me.

Apple is trying to appeal to programmers who want to spend their time writing the difficult portions of their app rather than trivial but time consuming UI code.

[caveman_uk]

Most iPhone UIs aren't that complicated so I tend to do them in code - it keeps the project less cluttered. On the other hand if there's more than a handful of views to place it's much easier to do it in IB. So I do both.