I had the same experience with my first Cocoa Touch/UIKit project. The GUI stuff far eclipsed the rest of the app in terms of development effort, which I did not expect. This hadn't been the case with previous GUI stuff I'd done (Windows apps, game UIs and the web), and took me completely by surprise.
The "no layouting engine" issue mentioned in the article applies to Cocoa Touch in the same way as it does to Cocoa, with the added wrinkle that if you want to support autorotation, this bites you even harder. Yes, there's the "struts & springs" system, but it's very limited - no equivalent to 'min-width' or 'max-width', and yeah I can't believe I'm citing CSS as a good example. It also doesn't help at all if you need to change the relative placement due to autorotation, or if you need to adjust positioning depending on content.
Styling is another issue - most UI elements can't even have custom colours. (this will improve with iOS 5, but not until iOS4 compatibility is no longer an issue) The default button looks awful. You have to come up with your own table view cells for pretty much anything but the most bare bones of lists.
In the end, I actually built my own fully fledged layouting system, which is content sensitive, has a fairly flexible elasticity system and supports a "flow" layouting mode which is somewhat similar to the way display:inline-block; HTML elements are laid out (but with grow-to-fit). I also built styleable versions of some of the views. If only I wanted to be in the business of building iOS apps, I'd be extremely well prepared at this stage. :-)
My recent foray into Cocoa on the Mac actually has been easier, but that's probably because you can get away with using the default widget styles. Apart from table cells anyway.
Um, there is a layout engine for Cocoa. It's called UIWebkitView... But the fact that you felt the need to write your own layout system instead of using the existing one suggests that generic layout systems don't give the needed flexibility, which means that it is more important for an API to provide the tools to build a layout system than to provide a layout system. Cocoa is one of the better frameworks for building layout systems in my experience (Java SWT, Cocoa, MFC - haven't tried .NET).
UIWebView is (presumably deliberately) pretty restrictive in its JS<->native bindings. Having to redirect to URLs which are then intercepted on the Objective-C side is pretty awkward. Then there's the fact that HTML/CSS aren't even that great for designing UIs, since they were created for document styling.
Any interest in either open sourcing said layout system or perhaps even selling it to those of us who struggle with these sort of problems (a la Sensible TableView)?
We've put some of the styling-related components online on http://appuicomponents.com/ but the layouting engine isn't there yet, I do feel it's valuable enough to productise eventually. The main problem is lack of polish right now. Interface Builder isn't much use once you get to that level of customisation - there's no way to set properties your subclasses introduce, let alone previewing the automatic layouting. I'd like to fix that at some point and have some ideas on how it could be done. Aside from that, I also still need to document the system, and tidy up the code implementing the layouting, as it's currently not the easiest to debug or find out why something isn't being laid out as you were expecting, even if the layout system itself isn't doing anything wrong.
Then of course there's the fact that I'm spending almost all my time on our startup, which is completely unrelated to iOS. (but it has a Cocoa-based Mac GUI, hence my recent Cocoa adventures)
Actually, if you're interested in the layout kit, go ahead and drop me a line (email on the website I mentioned, or in my HN profile) with what you're trying to do - if it does what you want, I'd be quite happy to progressively tidy it up and document it if I've got one or two users who are willing to put up with the rough edges initially, in exchange for some hand-holding.
The "no layouting engine" issue mentioned in the article applies to Cocoa Touch in the same way as it does to Cocoa, with the added wrinkle that if you want to support autorotation, this bites you even harder. Yes, there's the "struts & springs" system, but it's very limited - no equivalent to 'min-width' or 'max-width', and yeah I can't believe I'm citing CSS as a good example. It also doesn't help at all if you need to change the relative placement due to autorotation, or if you need to adjust positioning depending on content.
Styling is another issue - most UI elements can't even have custom colours. (this will improve with iOS 5, but not until iOS4 compatibility is no longer an issue) The default button looks awful. You have to come up with your own table view cells for pretty much anything but the most bare bones of lists.
In the end, I actually built my own fully fledged layouting system, which is content sensitive, has a fairly flexible elasticity system and supports a "flow" layouting mode which is somewhat similar to the way display:inline-block; HTML elements are laid out (but with grow-to-fit). I also built styleable versions of some of the views. If only I wanted to be in the business of building iOS apps, I'd be extremely well prepared at this stage. :-)
My recent foray into Cocoa on the Mac actually has been easier, but that's probably because you can get away with using the default widget styles. Apart from table cells anyway.