More features in the Qt for iOS port
labs.qt.nokia.com
labs.qt.nokia.com
As a developer this is interesting and cool. As someone who loves good UX, and as an iPhone user, I sincerely this doesn't catch on.
The look and feel of iOS is an incredibly core part of the user experience of the platform (as it is with any platform), the wholesale replacement of these stock widgets with completely custom ones breaks user expectation, generates inconsistencies, and if the goal of cross-platform write-once-compile-anywhere is being sought, will simply create lowest common denominator UI - i.e., leverages none of the strengths of any platform, leaving only the most bland, mundane, and uninspiring intersection of all its target OSes.
To be clear, I'm not at all opposed to innovating with custom widgets and UI elements (the drag-down-to-refresh is one of the more ingenuous new UI patterns that's come from the community instead of one of the big companies), but this is trying to completely build a completely parallel UI layer beside the native OS one.
It's the same reason why I oppose Java-based UIs. No matter which platform you use it on, it never really behaves like the native widgets, and there are inconsistencies big and small that drive users up the wall. The core theme of consumer software in the past few years has been that superior UX trumps everything, up to and including having inferior features to your competition. Have we learned nothing? Why are we still so lazy with our UIs?
Ultimatively it comes down to economics: are you willing to pay five dollars for a native app or 1 for a cross-platform one?
There was a time when the functionality of our products compared to the status quo (e.g., word processing vs. typewriters) was so ridiculously skewed that we could get away with bloody murder. And we did. We invented insipid modal UIs that jerked users around the app. We invented gigantic toolbars with hundreds of vague icons because we were too lazy figure out how to let users access their most used functions quickly. We created unforgiving apps where just glancing at it wrong resulted in data loss. We abdicated our responsibility to make features accessible, and instead printed large manuals and tear-out cheat-sheets, and made fun of people who couldn't handle the information overload.
That era's long gone. Look at the App Store - it's a parade of failed apps eviscerated by users for bad UI. It's a gallery of obscure apps that never made it out of the gate because they didn't put thought into their UX. Now look at any of the top apps (in whatever way you define it: top grossing, most downloaded, highest reviewed, whatever), and you will see that one main common thread that connects is that their UI doesn't suck.
People's tolerance for bad UI has decreased rapidly for years, continues to decrease, and the number of places where you can get away with it is rapidly shrinking. On the desktop you might still have that much breathing room - on the hyper-competitive winner-takes-all arena of the App Store, you have no chance.
As a side note - I highly doubt Qt will save a developer enough time to make the difference between a $1 app price vs. a $5 app price. There are so many low-level fundamental UX differences between iOS, Android, and any of the other mobile platforms that full abstraction is simply not possible in the way that we have been able to do on the desktop.
Although Eclipse drives users up the wall in every other way, it uses SWT [1], which uses native controls.
I think it's actually worse feeling than a toolkit like GTK+, which is more of a Linux toolkit that "happens to work" on Mac OS. Qt apps feel like they're trying to sneak something past me (except on KDE, of course), and there's a very uncanny valley-esque effect. A GTK+ application is more "upfront" about it, so at least I understand what to expect immediately.
Cyberduck, a file transfer application, is written in Java, but I had no idea because it uses actual bindings to Cocoa. If you want to provide the best user experience in a Java application, that's the way to go, write swappable front ends for each operating system with the native toolkit bindings.
I don't have a problem with using different UI toolkits as long as they look like native apps. The problem is these toolkits are always a step behind in exposing features of the platform you are developing for.
SWT, however, does actually use native widgets. Try out an app that uses it - it will behave the way you would expect an app to behave.
I understand you fear that the widgets will be inconsistent compared to native widgets, but I don't understand why custom widget set would need to be any lower quality (or "bland, mundane and uninspiring") than the native counterparts.
Nokia also has said that they intend to use Qt on their Series 40 operating system, which powers the hundreds of millions "dumbphones" that Nokia sells each year.