[mirkules]

I agree with the overall sentiment of the page. A few questions to seasoned iOS devs:

"With websites, you can simply add one more page, then create a link to that page when you needed. However, you can’t do that with iOS app, everything has to be set in the beginning, any changes might result in significant other changes that you might not be able to understand why."

Isn't this what the Navigation Controller is for? You just push a view controller onto the stack, and pop it when you're done.

Regarding the UITabBar: "if you want colors icons instead of the blueish tint, the change in code is substantial!"

I have been using this method, which is not really complicated: http://sugartin.info/2011/07/01/customizing-tab-bar/

You need to make images for the bar in both orientations (if you need it). The only time-consumer is the "more" button, for which you'll have to create a custom UITableView -- and still not have the handy "edit" command to rearrange the tab bar buttons.

...unless this is the wrong method to use, in which case I would love to see an example of the right way to do it.

[lnanek]

He's writing for business people. Business people often request new features late in the game without knowing how hard or easy they are to implement. So a new feature may require a new or modified API on the server, for example, which means updating the server, updating the app to use the new API, updating the interface, getting the new app reviewed, etc.. Now if the change affects other things in the system, like a new way to cancel a record that all the other display logic has to respect, for example, you can end up modifying almost every part.

[zedwill]

I believe he might be talking about modifying a view, as he presents the example of adding an email button or a facebook one.

It still doesn't make sense as you can use tools such as Interface Builder. The only thing that applies, you could still be building the view programmatically or need custom animations. That needs coding. And of course a facebook button needs to handle things such as authentication than an emailing one does not.

About the UITabBar, you can always use the black one. Or use this little trick for greater effect which is less demanding on custom images: http://stackoverflow.com/questions/571028/changing-tint-back...

I also do apps for a living and it is true that business has unreasonable expectations on time and cost. Not to speak of the myriad of people that want a whatsapp clone for 500$

[pmjordan]

It still doesn't make sense as you can use tools such as Interface Builder.

I was bitten by this on my first major contract iOS app, so I think I know what he means. Interface Builder will get you most of the way fairly quickly, which is deceptive.

Then you start refining to try and match the photoshop mock-up for visual design, and find the built-in UI classes don't handle this. Buttons not supporting labels below an image by default, or multiple buttons next to each other on the navigation bar, or a background that moves with a table view, etc. etc. [1]

You get to work on custom subclasses (or adapting some open source ones). Interface Builder doesn't let you set properties of custom views, so your view controller starts being filled up with all sorts of stuff that really should be in the nib file.

Then you find out that actually, various labels and text views need to support multiple lines of text. This messes up your beautiful layout from IB. Struts & Springs are now useless for half your screen elements, and you put custom layouting code in a custom container view's layoutSubviews method or your view controller just to push stuff down the screen and resize your scroll view's contentSize. The complexity of this layout code grows for every supported orientation and device type.

Your NIB files are now a mere shadow of their existance at the beginning of the project, so at this point, making a change to move some views to a different screen (is that only on iPhone/iTouch or iPad too?) is no longer a trivial exercise at all.

Yes, it's all manageable. But there's a whole range of sudden complexity bumps at "80% done" where the existing tools leave you stranded. If you originally quoted for functionality covered by IB but then need to customise it, that will take a lot of time, and you'd better have budgeted for it.

[1] The situation has improved somewhat with iOS5, which makes supporting iOS4 (let alone 3) devices the IE of iOS development.

[DougWebb]

Thank you for this description. I've done a bit of Android work, but no iOS work yet. Most of my career I've done web apps, and my recommendation to my company is to do web apps instead of native apps for all of our mobile projects. You've reconfirmed my suspicion that native apps get into a lot of hidden complexity that's not apparent from the "Hello World" tutorials.

[fieldforceapp]

FWIW, the iOS5 based Storyboard has been helpful to get around some of the issues you mentioned; we just finished an app, granted with a very limited number of screens, but Storyboard was a time save for sure. Details, here: http://blog.fieldforceapp.com/weekend-project-ios5-storyboar...