Chameleon - UIKit for Mac development | Hacker News Reader

Chameleon - UIKit for Mac development

chameleonproject.org

97 pointssahillavingia29 comments

I really don't get the point of this at all. When I've ported iPhone apps to iPad (i.e. make them Universal) there was always little-to-no work to do on the underlying model classes, but always a lot of work to do designing new views since the UI model is so much different (mainly from the bigger screen). Same deal with Mac OS X, except the UI changes are even more extreme. If I want my iOS app to work on a Mac's screen, I'll have to spend the time to redesign the UI. Which is fine, so how is this thing going to save me any time at all, really?

It could be useful for lots of folks that know UIKit inside and out but haven't dealt with AppKit before.

But a Mac's interface is not an iOS interface. There are different constraints and different best practices, and sometimes completely different widgets. To make a decent UI, you have to understand the native platform.

Sometimes perfect is the enemy of the good.

The ability of a stopgap measure such as this is a good way to let established iOS players test the Mac waters without a huge investment.

Definitely agree. And no doubt this is why Apple hasn't announced UIKit on Mac (yet).

I think the same argument can be made with regard to iPhone apps running on iPad. iPhone apps on the iPad are not very pleasant but if you absolutely must have that iPhone app on your iPad then you can put up with a suboptimal experience just to have the functionality.

I think the same thing occurs on the desktop. Many times I use iPad applications and wish they were available on the desktop. iPad applications especially I think can work very well on the desktop due to the large display.

But don't take my work for it. Have a look at the streamtome app on the mac app store. The interface mimics that of the iPad. I am not sure if it uses chameleon but there's a good chance I would guess.

http://itunes.apple.com/app/streamtome/id405892506?mt=12

>It could be useful for lots of folks that know UIKit inside and out ...

Then they'll have a very easy time picking up AppKit — certainly much easier than someone coming from any other platform would have, mobile or desktop. The lineage from AppKit is supposed to be one of the advantages of UIKit. These frameworks are very similar.

AppKit and UIKit aren't at all similar. And they aren't related. UIKit was written from the ground up for iOS and is based on Core Animation. AppKit was written by NeXSTEP and is based on software rendering with dirty rects.

This argument seems strange to me.

UIKit was written, from the ground up, by people who either worked on AppKit or worked with AppKit, with full access to the AppKit source base. They share almost all design patterns, and some source code. UIKit is clearly based on AppKit.

Pervasive use of layers is indeed a difference. That's hardly the only thing interesting about either framework, though.

Compare NSView vs. UIView. Or NSViewController vs. UIViewController. Or NSTableView vs. UITableView. NSButton vs. UIButton. Same names but very different design patterns and APIs.

I've worked on many iOS and Mac apps. I'm honestly not sure how anyone can claim AppKit and UIKit are essentially the same.

What would you consider the essential Cocoa design patterns? I would point at the items listed at http://developer.apple.com/library/ios/#documentation/Cocoa/... . Delegation, notification, target action, the responder chain - these are all shared.

The frameworks are not identical, but to say they're not related… they only look wildly different if you're focusing in incredibly closely. If you consider .Net, or Java, or Rails, or GTK, or almost anything else, the differences between AppKit and UIKit are miniscule.

Nobody is saying that that they're not related. They clearly are (although the presence of other UI libraries does not affect any comparison of that relationship at all.

Your examples of delegates, responders, targets etc are concepts - and indeed UIKit and AppKit are both built around the same concepts.

The implementations of both is quite different however, to the point that porting something of complexity from UIKit to AppKit involves a lot of tedious changes - or worse: creation of abstraction layers if the codebase is to be maintained for both apps.

> AppKit and UIKit aren't at all similar. And they aren't related.

Actually, they're incredibly similar in terms of class hierarchy, design patterns (e.g., delegates, data sources, target/action for the most part), graphics principles (points vs pixels), use of various Foundation and CoreGraphics data structures, etc.

And yes, Core Animation works quite well with layer-backed views in AppKit, which is where it started.

It's easy to point out specific differences between these frameworks, but I think any developer who's already learned one would object to the underestimation of his/her intelligence that would be implied by comparing the subsequent difficulty in moving to the other with that of any other non-Apple platform SDK.

Perhaps you'd like to point out another SDK that is more similar to AppKit than UIKit?

But AppKit is pretty awful. I'm much more interested in Chameleon as a Core Animation-based replacement for AppKit than as an easy way to port iOS apps.

Right after opening, the app store seemed flooded with programs that had UIs that clearly showed their iOS heritage. And I've yet to see a singly one where this actually is good (no, Twitter for Mac isn't one). Going further along this road doesn't seem like a good idea to me. Yes, you'll save some time. But unless you're making a throwaway, gimmicky application, you'd better invest some time in creating a new GUI that'll better integrate into the desktop. This time, most likely you're not the only thing on the screen.

There is huge value in "throwaway" applications.

The decision to spend considerable time to even test the Mac market is a huge barrier to entry. This would be a good stepping stone to prove that there is an audience there.

Providing a poor quality application doesn't necessarily tell you anything about the audience a proper port would have, it can be significantly damaging to your brand, and is a waste of press attention.

Doesn't necessarily tell you anything. But it can. If you can find for 4-5k that "Yeah, people will buy stuff on mac like our iOS stuff, pull out the whole hog" it makes an excellent business case.

Also, not everything is brand based. For many things, removing the old thing from the store completely obliterates all mention ever made of it (as it wasn't the sort of thing that gets press attention anyhow).

Not everyone is selling apps that make 6-7 figure incomes. Many people are selling multiples that rake in 4-5 and doing quite nicely with that, and with no marketing.

Am pretty excited about this -- I have an iOS app that would work great as effectively a desktop accessory on the Mac.

Unfortunately the UIKit implementation isn't there yet -- there's no NIB loading, table views aren't editable, etc -- though what is done is very impressive. Will be watching this one.

Definitely a cool, will make porting iOS apps easier. However, a lot of the ideas in UIKit are meant for a touchscreen and wont translate well.

This is what I was trying to say, but it's much more concise. Thank you :)

Sure but it's all in how you use it. Not everything comes over cleanly but a lot does. AppKit is old and crufty and doesn't play well with Core Animation. Since Chameleon is Core Animation-based, it's already off to a better start than AppKit.

Everyone here is missing the point, this is not exactly meant for direct ports of iOS applications to Mac OS X. For example, look at Twitter for Mac and Twitterific in the Mac App Store, they aren't direct / touch-based ports, but rather, they take cues from their iOS counterparts.

Fascinating idea, but as also mentioned in the article: won't Apple do something similar?

There are way more iOS developers than there are Mac developers, and many more flock to the iOS platform every day. Surely, Apple has some incentive to make it easy for iOS developers to make software for the Mac.

From the article:

  Apple already has a version of UIKit that runs on the Mac: 
  every time you launch the iOS Simulator, 
  you're using that framework.

I know right? You'd think Apple would do this themselves but for some reason they haven't show any interest. Especially weird considering AppKit is so old and crufty.

Of course, Apple executives may change their priorities when they see how many developers are interested in a tool like Chameleon. Many people have speculated that the popularity of the Jailbreak SDK accelerated the release of the original iPhone SDK. It would be great if history repeated itself.

Great, so they're trying to position themselves to take credit for what may be inevitable.

Aren’t you way too cynical?

I guess i should say: Chameleon looks great, and I applaud their work. I just pulled the only quotation that peeved me.

In regards to your question, cynicism involves a belief about someone's motivations, and I'm only going off of what they have put in black & white: that it would be so awesome if they were able to repeat the most spectacularly dubious credit-taking in iPhone history. I realize that those 4 months between the availability of the first iPhone and the announcement of the official SDK were agonizing and suspenseful, but I don't believe for a second that the most notoriously secretive tech company didn't already have an SDK in the works. If I were iconfactory, I wouldn't labor to connect myself with that event.

Or they're trying to work to make the future possible.

I'm sure lots of things are inevitable too, doesn't mean you don't laud the person who actually brings it about.

Reply on news.ycombinator.com