4 ms·

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 und

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?

glhaynes 16y ago
It could be useful for lots of folks that know UIKit inside and out but haven't dealt with AppKit before.
- shaggyfrog 16y ago
  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.
  - gte910h 16y ago
    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.
    - deleted 16y ago
      [deleted]
  - glhaynes 16y ago
    Definitely agree. And no doubt this is why Apple hasn't announced UIKit on Mac (yet).
  - silkodyssey 16y ago
    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 http://itunes.apple.com/app/streamtome/id405892506?mt=12
- deleted 16y ago
  [deleted]
- scrod 16y ago
  >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.
  - joshaber 16y ago
    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.
    - kenferry 16y ago
      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.
      - joshaber 16y ago
        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.
        kenferry 16y ago
        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/Conceptual/CocoaFundamentals/CommunicatingWithObjects/CommunicateWithObjects.html 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.
joshaber 16y ago
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.

glhaynes 16y ago

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

shaggyfrog 16y ago
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.
- gte910h 16y ago
  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.
  - deleted 16y ago
    [deleted]
- glhaynes 16y ago
  Definitely agree. And no doubt this is why Apple hasn't announced UIKit on Mac (yet).
- silkodyssey 16y ago
  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 http://itunes.apple.com/app/streamtome/id405892506?mt=12
deleted 16y ago
[deleted]
scrod 16y ago
>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.
- joshaber 16y ago
  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.
  - kenferry 16y ago
    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.
    - joshaber 16y ago
      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.
      - kenferry 16y ago
        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/Conceptual/CocoaFundamentals/CommunicatingWithObjects/CommunicateWithObjects.html 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.

joshaber 16y ago

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.