Truth be told, something palatable and pleasant that works can be a very, very high bar from a UX perspective. When software collides with the real world, you get a lot of complexity. Even organizations the size of Google and Apple can't produce a Maps app that doesn't do wacky stuff that seems designed to frustrate the user while trying to get someone killed. By comparison, how something looks is dirt cheap. (As usual, it's far cheaper to signal quality than it is to build it.)
When it has to deal with the "real world," mobile QA and UX is hard, and doing it to a high level is probably greatly underestimated in cost while being quite expensive. They say a picture is a thousand words, and seeing it yourself is a few more orders of magnitude. If your only feedback is logging/callbacks/snippets of text from users, you're only getting a small sliver of the true picture.
If your bar is too high on the UX side, as a lone contract programmer who is NOT the designer, you probably will have the same problems shipping as the person described in the article. Real artists ship. Lone consultants cannot do Apple/Google/Microsoft/well funded startup level UIs where there's a guy who's only job on the project is the interaction between code and design.
Citation, please. I deal with clients on a regular basis who think that software with 20+ years of time invested can be duplicated by 1-2 engineers working for 3-6 months.
Earlier today, I had to give a rough estimate on writing a custom app that can read, write, share and sync arbitrary CAD files, and explain why building all of that might not be the best approach.
Not at all a straw man. Maps might be much, much larger than a small MVP, but Google and Apple have a lot more resources than a lone contract developer. You are the one getting caught up with scale. I'm talking about the increased complexity of apps when they have to bump up against the real world. I've been greatly offended and materially affected by seemingly arbitrary choices made by a developer on a username field. Namely, that starting to edit the username field would blank out the password field, instead of doing this on start-edit of the password field. In a time critical situation on low-bandwidth, this can leave a user with a password vault cursing, high and dry, while the app starts this kafkaesque cycle of doing the most annoying thing.
Lone consultants cannot do Apple/Google/Microsoft/well funded startup level UIs where there's a guy who's only job on the project is the interaction between code and design.
If the aim is to make a substantive tool that stands up to real-world complexity in UX, someone, somewhere is going to have to spend a lot of time testing the heck out of it and make careful observations. Otherwise, the lone consultant is just going to check off the requirements, call it a day, and bill. The only alternative is to be really good about feedback, and implement in such a way that corrections can be distributed in a matter of a few hours or less.
I tried to put together a workable MVP as quickly as possible. The designs that I thought were aspirational designs for a finished product that would be completed eventually, but no, the CEO really wanted all of the fancy transparency, the exact button spacing, the exact imagery and fonts (despite the fact that they used fonts that weren't licensed for app usage...sigh...).
So we spent tons of time that was supposed to be MVP instead making a polished final product.
And then the CEO threw a new set of art to us and asked for a third redesign (ours was apparently the second, after the initial developer resisted making major design changes). And then a FOURTH redesign.
It amazes me that this guy (continues!) to get funding. But he's managed it. :|
On the flip side why would a non-developer bother to install Xcode and learn IB when they can export their ideas directly from Sketch/Photoshop into clickable "prototypes"?
For large changes, it can be unmanageable. But large changes are hard to code review anyway, so we try to avoid those.
At work we had two teams who had very different opinions of IB's usefulness. In our case, it was based on the nature of each application. IB does not provide much value when the majority of the screen is dynamically determined: different elements based on user preferences, locale, document contents, etc. The team that disliked IB, their app was almost all dynamic (and lists/tables, whose cells were also fairly dynamic).
Our team, on the other hand, had a very static UI. It had very little runtime customization (other than the contents of labels, images, etc). We loved IB.
And then child ViewControllers came along, and made it easier to mix static/dynamic content on the same screen.
I haven't used UIStackView yet, but I suspect it also will help with screens that contain dynamic content.
While I absolutely hated AL at first (and the IB just plain sucks) I do find it very time-saving once it clicked.
Whether it was written down or not, it seems like a good idea in theory. The old, stand-alone IB wasn't all that hard to figure out (though struts and springs might bring the death of your sanity). Get the UI all prettied up, and hook up an implementation behind it. Not that I've ever seen that in practice, however.