Do you think Apple will kill Cocoa soon?

Discussion in 'Mac Programming' started by pier, Jan 23, 2018.

  1. pier macrumors 6502a


    Feb 7, 2009
    At this point Carbon is pretty dead. It has been deprecated since 2012 and nobody wants 32 bits apps anyway.

    So now with the transition to Swift and all the Obj-C types ****ery it seems inevitable that Apple will release a new SDK 100% in Swift.

    Another argument is that Apple could now have a cross platform SDK (macOS/iOS/watchOS/tvOS) which seems the most logical step.

    It would not surprise me if Apple announced this new SDK in WWDC18.
  2. casperes1996 macrumors 68040


    Jan 26, 2014
    Horsens, Denmark
    Cocoa is not dying. I won't deny that there'll perhaps be something else that's a middle thing between Cocoa and CocoaTouch, but Cocoa is certainly not dying. It still gets updated all the time and supports both Swift and obj-c.
  3. mfram macrumors 65816

    Jan 23, 2010
    San Diego, CA USA
    As Apple execs themselves have pointed out multiple times in the big presentations, the UI in iOS is primarily based on touch. The UI on the Mac is primarily based on a mouse. Those are very different things. And if you were to "combine" them, you would probably end up with something that doesn't work well on one or both of those platforms. Of couse, that doesn't mean they won't change their minds later.

    For example, the AirPort configuration utility on the Mac was eventually switched from the original Mac-based version to a lightly ported version of the one on iOS. And the interface suffered quite a bit on the Mac.

    Swift was specifically designed to be compatible with Obj-C. That doesn't really have anything to do with Cocoa and CocoaTouch.
  4. briloronmacrumo macrumors 6502


    Jan 25, 2008
    Cocoa( i.e. AppKit, Foundation and Core Data ) are fundamental to everything Apple does in both Objective-C and Swift. There might be some future convergence with Cocoa/Cocoa touch to help Apple reduce its own software maintenance( i.e. all the QA/QC for all frameworks on all devices ) but there is no evidence or need for it to disappear.
  5. pier thread starter macrumors 6502a


    Feb 7, 2009
    There are a couple of valid reasons. For example leaving behind all the type ****ery between Swift and Obj C or being able to share UI skills between macOS and iOS.

    Yes, touch and mouse are different, but the disparity between Cocoa and Cocoa Touch is not IMO the greatest dev experience. I don't expect desktop and mobile to have the same classes, but where they do share a similar thing (button, table view, etc) they should have the same API in all Swift platforms.
  6. Krevnik macrumors 68040


    Sep 8, 2003
    So, there's two ways to address a new language with an existing framework. You can rewrite the framework at a sizable expense, or you can keep making the bridge between the two languages better. I think it's pretty clear which approach Apple is taking. I wouldn't expect a framework written in Swift until after Obj-C itself gets deprecated for Mac/iOS development, and anything like that is maybe a decade out, IMO.

    I do agree it'd be nice to have better unification between how AppKit and UIKit fundamentally do things. The reality is a bit different, and oddly, Apple seems more interested in not completely ruining back compat in AppKit than porting back the architecture decisions they made with UIKit.
  7. superscape macrumors 6502a


    Feb 12, 2008
    East Riding of Yorkshire, UK
    I'd agree with that.

    There are lots of places where Cocoa and Cocoa Touch differ for entirely valid reasons. However, there are lots of places where they differ without good reason. I can't see why Apple would ditch one in favour of the other, but bringing Cocoa and Cocoa Touch a lot closer together and making them more consistent with each other would be a Good Thing in my opinion.

Share This Page

6 January 23, 2018