We’re developing an iOS application, and of course, the user would have to input some personal information before he/she can start using the application. What kind of validations should be implement on the device? Which ones on the server?

Most people, especially when starting out on a new project, consider input validation to be a fairly trivial problem statement with fixed states. But, as the application matures, they fairly quickly realize that every input has its own set of error and valid states. The validation problem grows exponentially with the number of user inputs on the device, as every combination needs its own validation, more or less.

I firmly believe that validation should never be done on the client, unless that’s the only place you need to do it. If there’s even a single server side validation component in the project, the team is better off delegating it entirely to the servers. This makes life much more easier for the front end developers and also makes testing easier. If your application depends on a web service (as most iOS apps do), chances are that the web service would in the near future completely rewrite its required inputs specs and then you will find yourself in a situation where instead of adding new features to your iOS app, you are spending valuable time in trying to get all the client side validations in place. This, until the next time this repeats itself.

That said, there is also a need to think about whether that input is really required. Let’s not forget that iOS devices are mostly mobile gadgets where the users are generally in a hurry to complete a particular task. Even if it’s their first time using the application, forcing them to input personal data which is only partially required is detrimental to the entire user experience. It adds unnecessary validation.

Conversely, if you have an input component in your app, then you necessarily HAVE to validate it. If you’re not validating it, it’s not important, and hence, must be disposed off.

Lessons: Abide by the Apple Human Interface Guidelines, always. Don’t force your users to input more information than is logically necessary for the application to do its job. If you have to perform input validations, do them all at one place, and that place is the server where you have the necessary processing cycles.

This Wednesday, I got the chance to debate just this with the CTO of an iPhone startup here in Washington, DC. While I am short on the person’s technical background, he did mention that his previous programming experience was doing website development using Flash and Dreamweaver.

The seed for the debate was laid last week when I met with their co-founder and while going over my experience with the SDK, briefly mentioned how elegant the app development workflow on the iPhone was, thanks due in large part to IB and the way it stores object information. I was then told that the company only believes in handcoding every single UI element for an iPhone app, and that it should be good reasoning out the benefits of each approach (hand coding vs. designing using the IB) with the company’s smartest person.

Having moved to Cocoa from a Java background, I can understand why a developer would not like the elegance and, arguably, added development steps mandated by the Interface Builder. Almost every programmer has been badly burnt by such tools in the past. And, almost all of these developers are only just now making a foray into Mac development because of how hot the market is right now. Every other programming framework has taught developers that it’s not the design that matters, rather the end product. Very few developers adhere to the keep it simple principle, and countless volumes have been written on why too much abstraction is actually a bad programming practice. While reusing code is a novel concept, there is a tradeoff with simplicity.

In the Mac world, such a conundrum does not exist. The tools for development are provided by the company that also happens to be the only company working on the Mac hardware and software ecosystem. They have a vested interest in making sure that development is consistently a wonderful experience for both the programmers as well as the testers. And, with a company that has such an academic backdrop of excellence, as Apple, chances are that they have spent a good amount of time in making sure that the development toolkit adheres to best practices in development.

Below are the points raised by the person and my reactions.

Interface Builder makes the project unwieldy and hard to understand.

This is absolutely not the case if you’re a good developer. One of the best practices I mentioned above is that application design is a separate task from application coding. Interface Builder lets you do the design work without worrying about what the code is going to look like. In almost all instances, it also provides you with a good way to enumerate the object and view interfaces that you would like to expose to other classes in your application. Design comes before coding, and by mixing the two, you’re absolutely laying the groundwork for making your application a terrible failure prone to App store rejection from the get go.

The reason your apps are difficult to understand is that the developer did not follow established norms when it comes to using IB. From Apple’s own documentation: ‘A very simple application might be able to store all of its user interface components in a single nib file, but for most applications, it is better to distribute components across multiple nib files’. The mainwindow.xib should be just that…the main window minus any views. This way, you minimize load times. Also, I follow the convention of having every view complex or custom view in its own nib. The formula I follow says that an nib should only have views that are needed at that particular application lifecycle state. This way, I know which nib to look at if I want to clarify some connections.

Basically, IB would only make the project unwieldy if a bad developer worked on it.

IB cannot do most customizations needed by apps

This argument lacks a backbone in 95% of the cases. You can perform almost all kinds of customizations using IB. Want a bunch of labels inside a UITableViewCell? How about a combination of labels and images? How about controls inside a UIScrollView? All this can be done using just the IB. Well, there are a lot of cases where you might want to handle customizations by code (complex composite cells for example), it doesn’t negate the fact that, even then, in the interest of keeping the design process consistent, you’re better off having an NIB before you customize. In fact, Apple recommends doing so because there is a lot of framework code that stands the chance of being over-ridden if you decide to do everything from container allocation to adding to a view programmatically.

That said, I would argue that over-customizing almost always leads to bad application sales. Almost all the best-selling apps for the iPhone maintain the signature look and feel of the preliminary pre-installed applications. There are no performance or behavioral gains from using non-native UI elements.

IB is for newbies; you learn with it, but give it up

Not unless you want to enforce bad design principles for the lifetime of all your subsequent Mac projects. As mentioned earlier, IB is a design as well as coding tool. It serializes objects in a file that is lazy loaded in a perfect order and with well-tested memory management in place. Also, doing so involves the use of a lot of frameworks that not only make life easier, but also reduce chances of code defects.

We have used design tools in the past, and UI development using code trumped all

This is just the side effect of using bad tools for a long time. Such thinking has to go. Apple developers have been working with IB for a few years now. The toolkit keeps on expanding and getting better. Don’t let your previous bad experiences let you make bad design decisions. Do it the right way. This is not an Adobe framework.

I am very interested in doing a followup to this post on a more technical level, but I really wanted to share with other fellow iPhone developers the importance of working with the IB, not against it. The tool is there for a reason. Learn to use it. Apple recommends IB for every project.

Remember, when it comes to software engineering, it’s not always the end result that matters, but also how much future proof that solution is. Being engineers, we’re also designers – software architects, and it is upto us to engineer something beautifully, or make our product look like a patchwork of sorts.

Now for the exciting part. I am married, drive a hybrid, don’t have roommates, and no longer commute 2.5 hours to and from the client site to work on some of the most technologically backward and ill-designed projects ever. I am now a more serious iPhone and Mac developer, thanks to the commute time saved, and have actually gained enough experience to put out apps (albeit small ones for now) on the App store.

I have gained more understanding of how small business in America works. I have seen the economy take one of the worst nosedives in my lifetime, and seen desperate efforts to bring it back on track. I have seen people responsible for the mess make it big, and I have seen people suffer. I have been humbled. I have come out stronger.

For those wondering what I am up to now, I am still the good old me, although with the wisdom of two. I am still diffident, so much so that I sometimes sell myself short, but it doesn’t matter. The people who are smart enough to realize my strengths are the ones that mean something. I am now, however, spending a lot of time pursuing my passion – learning to become a diligent software engineer, working on mobile services, next generation entertainment and communication software, and of course ECM. You can teach a violinist how to use their long fingers to type fast, but you can’t teach them how to compose poetry with their keyboards. Being able to do just that is something I am proud of. Thank you, school!

I am back, and hope to make this blog mine once again. Thanks for being a reader.

The point of this post is to mull over how age and experience really play a role in how you look at these things. For example, I saw this site today. It belongs to a passionate 18 year old open source software developer who is most probably a college student. From a technical standpoint, he is definitely more than qualified to do the jobs of some very experienced people I have met. He is on the cutting edge of his technical spectrum, so to speak. When I was growing up and in college, I was like that, too. I used to work on websites as a hobby, write interesting C programs in my summers, and just generally mess around with a lot of software code. With the rise of the Internet, though, it has become all too easy, and sometimes expected of you, to showcase your passion and talent for the rest of the world. This is an example of the raised threshold/baseline I mentioned earlier. So, is the kid exceptional? In comparison to some other peers in college, sure, but being on the cutting edge and passionate is expected from you. When you are grown up, this is how you look at it.

When you’re 18 years old, you just want to do things because they’re fun, and not because you realize that being passionate is ultimately going to help your overall perception of your future career. Youngsters these days have this wonderful opportunity to be taken seriously, to be able to start open source projects that have the potential to be used by a lot of people, to be able to contribute in the same vein as other more experienced people, thanks to the Internet. So, for someone like me, while it was considered exceptional to just be passionate about programming languages or writing hobby programs, I think the bar has been raised quite a bit in the last two decades.

So, do you compete with these youngsters? Feel threatened? No.

These are just signs that the technology landscape is changing so quickly, and that is very good. What we could do, though, is align our passion with theirs and create synergies that would ultimately advance future technologies.