[Jabbles]

I have no experience designing iOS apps. Could someone explain briefly why they are so inflexible?

Tightly integrated code: 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. The way iOS codes are structured is like a breadboard, everything is hard-wired, you still can change a few things here and there, but if you change the wrong wire, the whole board might stop working. Even extremely well structured code does not increase the flexibility by a lot. Adding an additional email button to ‘About’ screen might only be worth a few more lines of code, but adding a Facebook Like button on the same page is a different story, don’t expect that to be done in a few hours.

[natesm]

This:

> The way iOS codes are structured is like a breadboard, everything is hard-wired, you still can change a few things here and there, but if you change the wrong wire, the whole board might stop working

Seems very wrong. It sounds like something that someone that doesn't really understand Objective-C would write. It's a very dynamic language, using features like first-class classes should help prevent that C++-esque nightmare.

A Facebook like button is not a fair comparison at all. In a web app, you can just paste it in. If you had to implement the button yourself it would take just as long as implementing it from scratch on iOS.

Instead, consider a data type. If we're writing a Facebook clone, let's say we only have status messages and now we want to add photos. On the web, you'll need to write the template to generate HTML for that in the news feed. On iOS, you need to write a cell class. It's true that the iOS one will probably take longer, but that doesn't make it less flexible. It's just the nature of declaring your interface in code instead of in markup.

[phil]

People are saying this is exaggerated and it probably is, somewhat. But there's some truth to it.

Take a list of things for example -- let's say a list of contacts. On the web that's probably a styled <ul>. On iOS, it's a UITableView.

So, let's say late in the game you're asked to sort contacts by first name, and put a little section indicator in for each letter.

On the web that's easy, sort the array, then as you're iterating over it and rendering, insert your section header when the first letter changes. If the list changes, ajax the changes in and use an id on each item to update. Done.

On iOS, first you'll need to set up a collation on your table view. Decompose your array of contacts into section arrays. For efficiency, you'll probably want to keep a pointer to that list. Change your section and row count delegates so they match the new structure. Now when you're rendering the cells, you'll need to locate the contact by section and row, and if a cell is tapped you'll need to change that too. If you support editing (delete, etc), there are several other places where you'll need to make similar changes. Speaking of which, what if the user deletes the last contact in a section? You can't delete the last row in a section without deleting the section as well, so you'll need to detect that and react appropriately. Can updates arrive while the list is displayed? You could just reload the whole list, but that will probably result in an annoying UI pause. Better to just update the cells that need to change, so you'll want to find each changed row in your collated lists and update it, being sure to watch for any sections you need to insert/delete...

...And on and on. None of this is rocket science, but the point is that there can be a lot of complexity behind a minor changes that someone with a web perspective would think of as trivial.

[justinvoss]

The author may be overstating how rigid they are. iOS apps can be much less dynamic than web apps, mostly because you're working at a "lower" level in the GUI stack. Instead of having a layout engine that recalculates the positions of your UI elements for you (eg, HTML and the box model), you mostly have to manage the position and sizes of everything yourself.

You could create your own layout engine, but most developers choose not to, especially since the consistency of iOS hardware means they can predict screen sizes easily. Your other option is to make your app a thin wrapper around a Webkit view, but that tends to produce poor results (see the Netflix iOS app for an example).

[randomdata]

> Instead of having a layout engine that recalculates the positions of your UI elements for you (eg, HTML and the box model), you mostly have to manage the position and sizes of everything yourself.

I'm not sure that is strictly true. The autoresize model[1] will cover a lot of cases. The place where it does break down, and where HTML does shine, is with variable sized data such as paragraphs of text. However, that is starting to encroach on document territory anyway – meaning you'll probably want to use something like UIWebView to display that data.

Anyway, not trying to point out the obvious. I've just noticed that not all iOS devs are even aware of the autoresize functionality, so I figured it was worth noting.

[1] http://developer.apple.com/library/mac/#documentation/Cocoa/...

[justinvoss]

I'm definitely aware of the autoresize tools, but like you said, as soon as you start to have variable sized data it all sort of falls down. Then you wind up having to switch to using a UIWebView, which means redoing a lot of work. It can also be a huge headache to support both portrait and landscape mode with only the autoresize tools.

[harpastum]

Interface builder (and now storyboards) have allowed WYSIWYG iOS interface layouts since 2008. There are definitely more dependencies and interrelation between a native app vs web app, but there is definitely a high-quality layout engine that makes basic formatting tasks easy.

[justinvoss]

The basics are definitely easy. A lot of apps need more than the basics; even changing between landscape and portrait can be tricky and more complex that a simple autoresizing mask can handle (I would know, since I'm neck-deep in developing an iPad app that needs this kind of complex layout and needs to support all orientations).