21–30 of 36 posts
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
>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.
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.
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.
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
>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.
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?
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
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,…
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.
Earlier quoted context omitted.
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.
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.