Hacker News Reader

Qt is a lot more than just a UI toolkit, so I'm very glad to see the iOS port progressing. You can write a native UI on top of a cross-platform codebase a lot easier than re-writing the whole thing from scratch, so having QtCore and friends on iOS would be a huge boon for desktop developers who want to port their apps to mobile platforms.

What features of the target OS does a widget set need to utilize? It needs to capture input (multi-touch in this case which all mobile platforms provide) and display the widgets on screen (which obviously all platforms also provide). What "strengths" are there to leverage?

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.

Widgets must also play nice with accessibility features of the OS. I do not know whether doing that is possible on iOS without using native controls.

> 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.

Although Eclipse drives users up the wall in every other way, it uses SWT [1], which uses native controls.

[1] http://www.eclipse.org/swt/

Qt also "uses native widgets". It doesn't matter, it's still wrong. Yes, the buttons have the right pixels, but nothing behaves exactly right.

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 wonder if that is why scrolling in Cyberduck is extremely slow. http://trac.cyberduck.ch/ticket/3799

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.

Qt doesn't actually "use native widgets". However, it's capable of using native API's to draw native-looking widgets pixel-perfectly, which is more than enough on GNOME, KDE and Windows. In addition, it takes care of many cross-platform details such as button order and native dialogs, etc. On OS X I'd consider using native API's instead since I've heard so many complaints about Qt there.

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 your reluctance, but from a developer time perspective it may make sense to use a cross-platform toolkit even if the users isn't going to enjoy it as much.

Ultimatively it comes down to economics: are you willing to pay five dollars for a native app or 1 for a cross-platform one?

As a developer, I would much rather write a more expensive high-quality app than some bargain bin POS.

That's indeed the Mac way, or more correctly the Apple way. It's the reason why the Mac was dominated by highly polished not-cross platform apps.

As far as I can see, every platform is dominated by not-cross-platform apps.

That's precisely my point though - I think the software market has reached a point where developer laziness like this simply won't fly.

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.

What does "having a UI that doesn't suck" to do with using native controls? When I look at the top 20 paid apps (germany), 13 of them don't use a single native control (most of them being games). Most sucking applications in the App Store suck even though they are using native controls.

I understand that the UI will not be native, but it is very possible to create nice UI with Qt. Just look at the N9 and the apps therein, which uses Qt only for the UI. With QML/QtQuick, it's even very easy to build nice UIs.