UIKit for the Mac | Hacker News Reader

UIKit for the Mac

github.com

58 pointsadamnemecek38 comments

I'm still hoping for API convergence between the Mac and iOS, opening the road to universal Mac/iOS apps.

People keep bringing up how iOS is designed for touch and the Mac for mouse and keyboard, and how screen sizes are different and all that, but those differences can all be accounted for. Microsoft have shown it possible.

Why? Extend the Mac software ecosystem and allow for multi-paradigm devices, like the iPad Pro should have been.

Possible? Maybe. Desirable? No, not all. Don't get me wrong, AppKit is very much in need of a modernization, and it definitely is not as actively improved upon as UIKit is, but the two have very little in common from a design UI/UX standpoint. What has Microsoft shown with their multi-paradigm direction? That lowest common denominator is bad. And same would be for a possible "UXKit".

Why would you want different UI framework for each screen size/input device type?

Seems silly to have one set of API's for small touch devices and a completely different one for large mouse-driven devices. Shuts the door to large touch devices and small mouse-driven devices.

iPad Pro is already awkward. At that size, a mouse would be nice, along with lots of other desktop UX paradigms.

> What has Microsoft shown with their multi-paradigm direction?

Seems to be working. Windows Shell, modern Office, Edge, and Xbox dashboard are all using the same UI framework.

Define "working".

Since the introduction of iOS, Apple has seen a lot more growth and profits than Microsoft, and became the largest corporation in the world (by market cap).

I do think Microsoft's latest multi-paradigm devices (like Surface Pro), are gaining traction. But overall Apple has outpaced Microsoft while having different UI frameworks for mobile and PC.

I'm talking from a dev perspective, not a business perspective.

From a dev perspective, the best development environment is the one with the most customers willing to buy your products.

Other criteria come pretty far behind that.

From a dev perspective, why not just have one device only? Then we wouldn't have to worry about different screen sizes or input devices.

Exactly. Apart from anything else, we already have HTML. Why would you want to write a lowest common denominator UI that only targets the Apple ecosystem?

You'd be getting neither the benefits of native nor the benefits of cross-platform.

I agree that it's a terrible idea to put a touch UI on a mouse-operated desktop and pretend you're done. That doesn't mean you always have to build two completely separate apps or UIs for each platform though.

The differences between touch/mouse incarnations of basic components, such as lists, buttons, scrollviews etc. can often be resolved with adaptive design. Apple has already put the basics in place to allow for adaptive apps that scale from the smallest iPhone to the largest iPad. Doing the same for touch -> keyboard/mouse UI is not unthinkable.

AppKit is dead. Apple is using WebKit for all their UI needs, these days. Goodbye AppKit, you were never that great, but you served your purpose, and had a relatively long and fulfilling life. RIP.

I don't think that this is true...

Huh? What are you talking about?

Android apps work pretty well with mouse, on desktop.

I think the baseline toolkit could be the same, with some extra components for different form factors.

We're working on something like that (multi form factor UI toolkit) for Ubuntu, with Qt. Will see how far it goes.

Android apps work pretty well with mouse, on desktop.

No! No they absolutely don't!

Almost every Android app is clearly design for use on a touch device. Every aspect of the design is intended to be touch-first. That's totally fine – but the fact that they can be used with a mouse on a desktop does not mean that they work pretty well. The user interface paradigms are really very different.

Have you actually tried using Android with a mouse?

Yes. It is awful.

There is a decent amount of convergence in game development, since Sprite Kit has SKView, SKColor, etc. (whose base classes vary by platform but most methods are the same) and important frameworks like AVFoundation are identical.

The Mac has shown hints of iOS influence when looking at recent changes to NSViewController and the addition of other standard view-controller-based classes.

Realistically, though, I like Apple's separate-but-similar approach. I don't want Mac applications shoehorned in from iOS by lazy developers, I want applications that were actually written for the desktop.

I think it's gotta come from the other direction, ultimately. They're working hard to push AppKit forward and bring it into the future, but I think UIKit will figure out the hard problems (menuing, keyboard navigation, pointer input) before that.

I think pointing at Microsoft as having the solution to this problem is disingenuous. Modern Windows has had so many false starts, and I still feel their multi-modal devices are inherently compromised — jack of all trades, master of none.

Microsoft have shown that it is possible, and that it is terrible. Touch interfaces are a waste of the precise input methods and expansive real estate available on a desktop or laptop computer.

> Microsoft have shown it possible.

I suspect Apple is perfectly happy to let Microsoft experiment with this until they figure it out (assuming they do). But from everything I hear they aren't quite there yet, and until they do, I'm happy that Apple is not using me as a beta-tester for such a 'universal interface'.

This article about UXKit is a good summary of why this is a bad idea.

http://inessential.com/2015/02/05/uxkit_skepticism

(Found this by Googling UXKit, after reading about it for the first time in this discussion.)

Yes, but it has been a pain road.

Windows 10 is the first one where you can finally use the same APIs for the store, phone and desktop.

Which is not really that usefull given how different usage and behavior a desktop and a smartphone app have. Even as a former Windows Phone hobbyist developer I don't have any interest in this API because I think the programming model in totally wrong and too limited for desktop programming. Not to mention the UI components which are not suited to big screens. The biggest proof of failure is probably the fact that in 4 years of Windows Runtime existance Microsoft itself didn't bring any killer software (Visual Studio for example) on it.

People always mentioned killer software like Studio and Office, forgetting that one just doesn't rewrite software like that.

For example Studio is still 32 bits, for many reasons, one of them being third party plugins that no one is going to re-write.

Windows File Explorer and Edge are two UWP applications on Windows 10.

Having separate XAML for mobile, tablet and desktop is no different than responsive HTML, with the benefit of being native.

But what can I say, I love WinRT as it feels C++ Builder is vindicated.

I don't understand why this post is titled "UIKit for the Mac". Apple already made UIKit work the same for iOS and OS X. EDIT: I'm wrong!

What are you talking about? It hasn't done anything of the sort. It's made some of the AppKit APIs similar to how they operate in UIKit, but it's a long way away from "work the same"

Read about UXKit; Apple did limited work on porting a small set of UIKit to OS X. But it's hardly complete or ready, and I don't think it's under active development as a possible public framework.

Thanks for clarifying so this is a rework of UIKit for OS X? Rather than an layer over AppKit to make it "the same" as UIKit.

If you want something that works now, there is Chameleon, the project this is based on:

http://chameleonproject.org/

Unfortunately, it seems the project's maintainers have mostly lost interest in the project (last push to Github in May 2014), but there's a few forks that have kept on. I maintained this one for a few years for our own uses:

https://github.com/toushay/Chameleon

Unfortunately, the company behind that fork, Toushay, went out of business last year so there won't be any further work done on that fork. There may be others out there that are still maintained.

Or, instead of debugging and maintaining over-ambitious lowest common denominator projects, which will limit you any way you look at them, just re-write the UI portion of your software with proper Mac design in mind, in AppKit.

Using something like Chameleon can get you up and running in a very short time. Literally, it took one afternoon for me to get our app running on Chameleon. True story. I actually did it without management approval on the day they said "we should have an OS X app" and demoed it to them at the end of the day. It wasn't perfect, and took another week or two to iron out a few bugs in Chameleon we ran into. That was the start of our fork, actually.

But it worked, and it would have taken two to three months to get to that point from scratch. I should know, because I did from-scratch ports to other platforms and that's how long it took each time.

You can mix and match Chameleon (UIKit) and AppKit in the same application, so you can incrementally replace Chameleon with a "proper" solution. If you find that's important to you.

Unless Apple are activly working on UXKit a better bet would be an implementation of UIKit with SpriteKit, with sane 'defaults' for Mac OS. I've missed something like CollectionView on Mac OS with same API as UIKit.

By sane default I mean something like: Tab Bar on IOS, Slidable Side Menu on iPad and regular side-panelMac OS.

UXKit has some issues, e.g you can't swipe back with the touchpad. So I take it has some work left before being a complete replacement of AppKit.

Hopefully this will take off!

Could use something like this as using OSX's frameworks is so painful (creating list views with items of various heights is overly complicated)

Twitter tried once upon a time:

https://github.com/twitter/twui

I thought that the Chameleon project is dead. I studied the source code a few years ago.

Seems risky to go for this when it's very likely something Apple is working on.

Is it really? UXKit has not moved at all. It has remained relatively static in the Photos app. It's a serviceable patch-work that Apple has done for their specific purpose, but I don't think it's actively being pushed forward for a possible AppKit replacement.

> UXKit has not moved at all.

This is speculation, unless you have inside information, UXKit could well be under active development - we don't know.

Reply on news.ycombinator.com