I started developing for ios in a new company.
Here they taught me to never use iterface-builder, saying it’s hard to maintenance the code and it have a few limitations.
Using interface build for java application in netbeans i see a lot of “bad code” but i don’t see it using IB, besides i see a lot of IB codes on the internet and only a few codes without it.
So for a large where no one is a beginner on ios development is a bad pratice use IB?
(Let me mention in advance that I have strong objection against using Interface Builder, for a number of reasons I will explain)
This is only partially true. The principal reason I don’t like Interface Builder and Xcode in general is that a lot of beginner programmers think that it is the only way for developing iOS/OS X apps. They have never heard of
gccandclang, they don’t know what the compiler and linker error messages mean, they can’t usemake, and they have no idea about what the difference between the Objective-C language, the Cocoa (Touch) APIs, the IDE and the compiler is.After all, they start using Interface Builder and Xcode with all of its quirky and sometimes strange/illogical features (and bugs as well), but when they’re in the need of developing something non-obvious, they don’t even realize there is a method for, for example, creating views and view controllers programmatically (yes, I’ve seen this very question on StackOverflow).
So, when abused (or rather, used too early), Interface Builder and all of the “convenient” features lead to programmers learning bad concepts and missing some important pieces of practice and experience.
However, if you’re a senior developer, who has all the necessary skills, and you feel you could write an entire application from scratch, using just a simple text editor and a Makefile, then you are by all means permitted to use IB, and even encouraged to do so if you feel that’s more comfortable than hammering out code.
So, to sum up:
No. Rather abusing it and not making the effort to learn the programmatic approach to UI stuff is bad practice.
Post scriptum: I have quite a lot of experience with iOS development, but I still find Interface Builder rather inconvenient and inconsistent. I generally use code for everything. But that seems to be my personal preference. One advantage is, however, that if one creates everything by code, then another programmer without access to these Apple-specific tools will be able to contribute to the project as well. This is a point where the “it’s hard to maintain” part comes true…
For example, until I didn’t have enough money for a Mac, I used Linux for developing iOS apps (yes, that is actually possible). I couldn’t use IB and Xcode, yet I have done loads of applications and tweaks (for jailbroken iOS, of course), and that was just fine.
Post scriptum #2: another reason for avoiding the use of IB could be the need for dynamic UIs. If you heavily rely on animations, custom UI elements, etc., it’s hard to do everything in Interface Builder. Last summer, I had to rewrite a login screen of an application, and honestly, I don’t know how I could have realize our designer’s ideas if I had had to use Interface Builder. The UI/UX was so dynamic and it had so many ways to change that it was absolutely necessary to have fine control over each and every pixel. And that’s something that code is better at than IB.