jfahrenkrug

"Let us help you make your password more secure by sending it over the wire a gazillion times."

My thoughts exactly. It's ridiculous.

I totally agree. We need to learn how to use the right tool for the job. If your job is to cut down trees you wouldn't say "Well, I know how to use a pocket knife and I think a pocket knife is much easier to use than a chainsaw, so I'll just cut down trees with my pocket knife." No, you'd obviously invest a little time to learn how to use a chainsaw to get the job done properly.

I don't dislike the web. I dislike it when web technologies are used to mimic native apps because that creates expectations that can't be fulfilled.

That might unfortunately be true. However, even that is a misconception on the part of companies thinking it is "easier, faster, cheaper" to create web-based apps. Building something with web technologies that's on par with native is hard and difficult work. It's a myth that it's so much easier and faster to build an app with web technologies. It could very well take longer and still have a worse user experience. Building a simple native app is, well, simple. It might be way more complicated to build it with web technologies (if you try to mimic native).

True, but it doesn't seem to me as if Google tries to push web apps as an "as-good-as-or-better-than-native-Android-apps" approach to make apps.

"Never" is much too strong a word to use, but I think that it is very very very unlikely that any major mobile vendor (Apple, Google, Microsoft) will invest much time and money to make the web a first-class citizen for apps on their platform. Each company wants to offer the best experience on THEIR platform and offer features that are only available on THEIR platform so that more developers develop apps for only their platform which in turns means more sales of their products. They are interested in exclusivity.

I agree that the web is the exception to this rule (see http://www.springenwerk.com/2011/09/thoughts-on-mobile-ui-de...). I quote: "Surprisingly, cross-platform UI works on the web. People are used to it. People don't think it's odd that GMail doesn't look like Outlook or Mail.app. They don't complain that the buttons on Twitter look different from the button of the other apps they use. They are able to use Google+ and Facebook although the UI looks "foreign" in comparison to other apps on their platform. Strangely enough, all those things that make cross-platform UI a bad idea seem to be absolutely OK on the web. Why is that? It has to do with expectation. When users open their web browser, they know that they are entering a very diverse space."

I fully agree. As stated in my article http://www.springenwerk.com/2011/09/thoughts-on-mobile-ui-de... I think that the web is the one place where cross-platform UI actually works. Don't destroy it by using that freedom to mimic a native UI. Plus, in quite a few cases a great mobile website would be a much better solution than an app anyway.

Cross-platform UI is a bad idea on the desktop. Cross-platform UI also is a bad idea on mobile. We need to learn from the past. Cross-platform UI is a conceptual mistake. An app that has an icon on the home screen is perceived by the user as "an app", no matter if it actually launches the browser without the toolbar, if it is a web app wrapped in a PhoneGap shell of if it is a native app. To the user, it's an app. It has an icon, so it's an app. The rest are implementation details that the user doesn't (and shouldn't) care about. So if the user perceives it to be a native app like all the other apps, it has to behave like one. Otherwise the user will be disappointed. Web apps that mimic native apps simply don't behave exactly like native apps: Imitating native UI with web technologies on a mobile device will only disappoint.

They did a nice job on this framework, but I think it is a fundamentally wrong approach. Here is why: http://www.springenwerk.com/2011/09/thoughts-on-mobile-ui-de... Or, if you prefer a video: http://vimeo.com/32256530

Don't make the mistake of thinking "Storyboard == Auto Layout". I really like Auto Layout and I think it is much easier to understand and read when declared in code. I strongly dislike Storyboards, though, for the 15 reasons outlined here: http://stackoverflow.com/questions/9404471/when-to-use-story... However, some pains can be removed with this tool I wrote: https://github.com/jfahrenkrug/StoryboardLint It helps you to keep your IDs in code and in your Storyboards in sync.

That is really cool, thank you for sharing! I also fully agree with the guy that said that the Autolayout support in IB is a nightmare to work with. Plus, IB does _not_ show you exactly what your UI will look like: You have to Build & Run anyway to really see what things will look like, esp. with autolayout.