Apple to sweeten Snow Leopard with more Cocoa

Posted:
in macOS edited January 2014
According to developer build notes leaked on the web, Mac OS X 10.6 Snow Leopard's new Finder and "almost all" other graphical apps will be delivered using Cocoa. Here's why, and what benefit this additional use of Cocoa will provide to users.



A Yellow Box of Cocoa



Cocoa is Apple's marketing name for one of the two prominent application development environments in Mac OS X. It derives from the object oriented development tools that originated at NeXT, acquired by Apple in 1996.



During the development of Mac OS X, NeXT's technology was first referred to as the Yellow Box, in contrast with the Blue Box of classic Mac development tools, and then was later renamed Cocoa to suggest an association with Sun's Java, which was at its apex of hype as a popular buzzword at the time. Java itself had borrowed concepts from NeXT.



Apple's existing procedural development tools for the Mac OS were renamed Classic, and portions were carried forward in a modernized environment called Carbon. This allowed existing code written in the 90s to be carried forward to the new Mac OS X and run natively, once relatively minor adaptations were made.



Carbon vs Cocoa



While Carbon and Cocoa are often portrayed as pitted against each other in dramatic rivalry as two opposing camps of development, Apple has actually worked to advance both to serve different needs. As Apple notes in its MacÂ*OSÂ*X System Architecture documentation, Carbon has been positioned as a lower level framework that provides access to bare metal functionality. Cocoa is designed to help developers build robust, complete applications rapidly by providing easy to use frameworks that handle a lot of the background work for them.



At the same time, there is some overlap between the two, particularly in the realm of building user interfaces. Developing and promoting two separate development environments to do many of the same things has stretched the company's resources with increasingly less upside.



Once it delivered a fully functional Carbon environment, Apple could focus on promoting Cocoa as an easier to use, more consistent, and more flexible and portable set of Application Programming Interfaces. Last year, Apple made it easier for Carbon developers to add Cocoa to their apps. It then announced that, starting with Leopard, portions of the APIs used to build 64-bit graphical apps would only be delivered for Cocoa.







That meant that while both Carbon and Cocoa could continue to be used to build 32-bit apps or 64-bit servers and other faceless apps, any efforts to deploy 64-bit apps with a graphical front end would need to have their user interfaces built in Cocoa.



After signaling the intention at this year's WWDC to deliver all bundled apps in Snow Leopard with 64-bit capabilities (and the ability to run as 32-bit in order to support existing Macs without 64-bit processors), the writing was clearly on the wall that Apple would need to port the graphical portions of all its bundled apps to Cocoa.



Apple's Cocoamotion



The move to Cocoa benefits Apple because it can devote its limited resources into a single set of APIs for developing graphical apps. By tying the move to 64-bits with a transition to Cocoa, Apple is also pushing developers of legacy Carbon apps to make both jumps together rather than stringing things along for years.



This is less than ideal for companies such as Adobe and Microsoft, which have built cross-platform tools based on the lower level Carbon. Their move to a Cocoa user interface will take additional effort, something that Adobe noted as the cause for its failure to ship 64-bit Photoshop CS4 for the Mac. When they do deliver their 64-bit apps however, those apps will benefit from being developed in Cocoa. Apple faces the same challenges in building a Cocoa face for its own Carbon apps, including Final Cut and Logic.



Developers benefit from the move to Cocoa because it gives them a consistent user interface, more of which comes for "free." Rather than custom coding large parts of their user interface, Cocoa makes it easier to adopt the new widgets and interface conventions Apple has pioneered in its iLife, iWork, and other apps, and subsequently made available to third parties. Using Cocoa also gives developers a leg up in supporting the resolution independence built into Mac OS X.



What Cocoa does for users



For users, the move to Cocoa means that applications will have more consistent appearance and behavior. Apps that make use of standardized interface controls rather than building their own will not only be more familiar, but users will also benefit from the code exercise and reuse, which removes bugs and allows for centralized optimizations. In other words, Apple can address user interface problems that in turn impact all apps.



This doesn't mean Apple is abandoning Carbon or a variety of other new APIs that are similarly procedural, C language APIs. The new (in Leopard) Core Text is defined as part of Carbon, and Cocoa provides an object oriented wrapper for it in the Cocoa Text System. Core Video, QuickTime, and Quartz lie outside the definitions of Carbon and Cocoa, and Apple presents dual Cocoa and Carbon interfaces for working with these.



Rather than the removal of Carbon, Apple's move to Cocoa in Snow Leopard is a consolidation of future efforts, starting with the user interface. More effort has gone recently into making new Cocoa 'kits' than in building entirely new Carbon APIs. The QTKit, PDFKit, and Core Animation are all examples of new, recommended Cocoa tools for doing things that are easier and more powerful than building from scratch in Carbon.



The Cocoa iPhone



The iPhone has already become 'fully Cocoa' in its user interface, highlighting why Apple is investing its efforts into one environment with the portability to stretch beyond conventional desktop computing. As Apple evaluates new product directions, from netbooks to tablets to TV boxes, having consolidation behind a single, modern application framework will make it easier to both create new products and to gain third party developer support behind them.



As mobile developers rush to get up to speed with the iPhone's Cocoa Touch to participate in the wild success of the Apps Store, they'll gain crossover skills in developing for the Mac, too. In just a year, Apple's smartphone has effectively increased the installed base of its Cocoa systems from the roughly 20 million Macs running Mac OS X to more than 30 million devices in total. Apple expects this installed base to grow rapidly.



By decisively pushing developers to implement their user interface using Cocoa, Apple will end up with less code maintenance, more focused development efforts, and a broad, flexible platform that's easier to pilot into the future.

«134

Comments

  • Reply 1 of 69
    This won't stop Adobe from completely bypassing any benefits a Cocoa GUI would bring to their development processes and the user by creating a custom interface that nobody likes and that steals time away from developing new features that are actually worth 500+ dollars in upgrade price.



    The WHOLE POINT of Cocoa is to make the interface as easy and painless to create as possible so that the developers can concentrate on developing features instead of reinventing the wheel in the 'interface department'.



    Hey, Adobe, if you want to create your own interface paradigms, build your own effin' OS.
  • Reply 2 of 69
    mcarlingmcarling Posts: 1,106member
    Hopefully, 10.6 will strip out support for developing Carbon apps but will still run legacy apps and 10.7 will completely strip out all run-time support for Carbon apps. That should have happened back about 10.3 or 10.4. It's time to move forward.
  • Reply 3 of 69
    I've always found Cocoa applications like Safari and Mail much more stable than Carbon apps, such as iTunes or Finder. I don't know which one is better, or if one can ever reach such a conclusion, but I sincerly look forward to more Cocoa seeing as Multiclutch only works with Cocoa-apps.



    Is there any developer or programmer on these boards that could join in with their opinions regarding this strategy?
  • Reply 4 of 69
    cubertcubert Posts: 728member
    Yeah, Appleinsider! What you said.
  • Reply 5 of 69
    lorrelorre Posts: 396member
    Quote:
    Originally Posted by Windy View Post


    I've always found Cocoa applications like Safari and Mail much more stable than Carbon apps, such as iTunes or Finder.



    Ha yes, Safari. The only program that gives my machines spinning beachballs... I hope those will disappaer with Safari 4 cause it's just rediculous imo.



    Also, perhaps I misinterpret this but seems like Apple is only Pushing Cocoa for the GUI layer, lots of background stuff will still be Carbon.
  • Reply 6 of 69
    ajpriceajprice Posts: 320member
    Does any of this have any relation to resolution independence actually happening in Snow Leopard? RI is something thats been talked about and demonstrated for a long time, but never shipped in its full form.
  • Reply 7 of 69
    asciiascii Posts: 5,936member
    I don't think this article is quite right. Carbon is not the lower level C API that Cocoa (the higher level Objective C API) is built on - that is Core Foundation.



    Carbon really can be totally removed and leave Core Foundation as the pure C API. The only thing they won't be able to do in Core Foundation is GUI. But if anything is suited to OO style, it's GUI development, so it really does make sense for Apple to insist that people use Objective-C if they want a GUI.
  • Reply 8 of 69
    MacProMacPro Posts: 19,718member
    Quote:
    Originally Posted by kim kap sol View Post


    This won't stop Adobe from completely bypassing any benefits a Cocoa GUI would bring to their development processes and the user by creating a custom interface that nobody likes and that steals time away from developing new features that are actually worth 500+ dollars in upgrade price.



    The WHOLE POINT of Cocoa is to make the interface as easy and painless to create as possible so that the developers can concentrate on developing features instead of reinventing the wheel in the 'interface department'.



    Hey, Adobe, if you want to create your own interface paradigms, build your own effin' OS.



    I hear you, I know this is just personal preferences, but I just spent the weekend trying out the new CS4 suite from Adobe and felt like I was running an alien OS! As a long time FCPro Studio user I found using Premiere was like going back in time to the days of the Radius video editing system (yeah I know all about the history of the programmer there). I think if Apple would only add a pro app to replace Photoshop I'd give up on Adobe altogether!
  • Reply 9 of 69
    I just can't beleive Apple has let certain inconsistent and/or ugly elements of the Aqua GUI last and it looks like these elements will live through Snow Leopard too.



    Elements such as the blue, bubbly scroll bars, or the shadows behind windows, etc.



    Mac OS X is WAY due for a GUI overhaul or at least a serious polishing.
  • Reply 10 of 69
    boogabooga Posts: 1,082member
    Quote:
    Originally Posted by ajprice View Post


    Does any of this have any relation to resolution independence actually happening in Snow Leopard? RI is something thats been talked about and demonstrated for a long time, but never shipped in its full form.



    In general, Resolution Independence is a way to spend a lot of extra processing power to make things slower and look worse. Instead of pixel-perfect icons you get kinda-sorta rasterized icons that may or may not look good at a particular resolution.



    However, it does make super-high DPI screens shine, so as display technology improves and GPUs start taking over more of the processing burden it may make sense. Until then, be glad it wasn't forced down your throat.
  • Reply 11 of 69
    taurontauron Posts: 911member
    This is an excellent development for Apple. By modernizing the way they do software, it is going to be a lot easier to develop kickass programs for the mac whereas for winblows it will be next to impossible to follow the lead.



    I predict this will do a lot to increase mac marketshare and to lift many humans from slavery called windows.
  • Reply 12 of 69
    Quote:
    Originally Posted by Booga View Post


    However, it does make super-high DPI screens shine, so as display technology improves and GPUs start taking over more of the processing burden it may make sense. Until then, be glad it wasn't forced down your throat.



    Yea, 'Until then'. Apple had just released those new 24" Cinema Displays which have the same resolution as the 23" Cinema Display's had, that means LESS DPI... it seems Apple is going the wrong way hardware wise.



    (the 17" MBP does have the same resolution as those 23" and 24" cinema displays (and the 24" iMac), so it is a step in the right direction. I just hope they dont negate that with the next gen 17" MBP.. even though they already made a bad move by dropping the matte option.)
  • Reply 13 of 69
    Quote:
    Originally Posted by Macvault View Post


    I just can't beleive Apple has let certain inconsistent and/or ugly elements of the Aqua GUI last and it looks like these elements will live through Snow Leopard too.



    Elements such as the blue, bubbly scroll bars, or the shadows behind windows, etc.



    Mac OS X is WAY due for a GUI overhaul or at least a serious polishing.



    Hi, I feel compelled to write my first post ever on AI :



    Do not touch my beloved bubbly scroll bars !
  • Reply 14 of 69
    Quote:
    Originally Posted by Macvault View Post


    I just can't beleive Apple has let certain inconsistent and/or ugly elements of the Aqua GUI last and it looks like these elements will live through Snow Leopard too.



    Elements such as the blue, bubbly scroll bars, or the shadows behind windows, etc.



    Mac OS X is WAY due for a GUI overhaul or at least a serious polishing.



    While a lot of people have wondered why Apple has (so far) retained the "aqua" scroll bars, your other comments make absolutely no sense.



    The "shadows behind windows" are one of the most helpful and well-liked features of OS-X and you are the first I have ever heard arguing for them being removed. They were also significantly changed and overhauled in the very last iteration of the OS.



    In fact the entire UI was overhauled quite substantially in both the last release (Leopard) and the one previous to it (Tiger), so the idea that we are dealing with an ancient interface desperately in need of an overhaul is a bit much isn't it?
  • Reply 15 of 69
    ronboronbo Posts: 669member
    Quote:
    Originally Posted by cozagada View Post


    Hi, I feel compelled to write my first post ever on AI :



    Do not touch my beloved bubbly scroll bars !



    I'm with you
  • Reply 16 of 69
    Quote:
    Originally Posted by kim kap sol View Post


    This won't stop Adobe from completely bypassing any benefits a Cocoa GUI would bring to their development processes and the user by creating a custom interface that nobody likes and that steals time away from developing new features that are actually worth 500+ dollars in upgrade price.



    The WHOLE POINT of Cocoa is to make the interface as easy and painless to create as possible so that the developers can concentrate on developing features instead of reinventing the wheel in the 'interface department'.



    Hey, Adobe, if you want to create your own interface paradigms, build your own effin' OS.



    Right on. They ignored the direct advice to move to xCode for universal development, got egg on their face and have been a year behind ever since. Amazing they couldn't simply take their lumps and make the switch and served the very population that made them what they are today. Just how obstinate can one company be?
  • Reply 17 of 69
    Quote:
    Originally Posted by digitalclips View Post


    I hear you, I know this is just personal preferences, but I just spent the weekend trying out the new CS4 suite from Adobe and felt like I was running an alien OS! As a long time FCPro Studio user I found using Premiere was like going back in time to the days of the Radius video editing system (yeah I know all about the history of the programmer there). I think if Apple would only add a pro app to replace Photoshop I'd give up on Adobe altogether!



    Finally got brave enough to stop by the Apple Store to see the state of PS Elements. Euugghh. Can't they simple deliver a simple cocoa PS5.0 core without an interface hack, iPhoto wannabe and twelve other add-ons when all most of us need to decent photo editing and compositing? Get GIMP out of X11 and I'd likely forget how to spell Adobe.
  • Reply 18 of 69
    sequitursequitur Posts: 1,910member
    Quote:
    Originally Posted by cozagada View Post


    Hi, I feel compelled to write my first post ever on AI :



    Do not touch my beloved bubbly scroll bars !



    Welcome aboard. I like the bubbly scroll bars, too.
  • Reply 19 of 69
    Quote:
    Originally Posted by jpellino View Post


    Right on. They ignored the direct advice to move to xCode for universal development, got egg on their face and have been a year behind ever since. Amazing they couldn't simply take their lumps and make the switch and served the very population that made them what they are today. Just how obstinate can one company be?



    It's not a matter of being obstinate, it's about being a business monopoly.



    Just the same as MS, Adobe is in a monopoly situation (and has been for a long time with some of it's products like Photoshop.) This means the product will sell no matter what it is, and creates a strong disconnect between the design of the program and the wishes/needs of the customer. As long as that link is broken, a program *may* conform to the customers needs, but it will not fail if it doesn't happen to.



    The failure happens (and is not corrected because of the aforementioned disconnect) because of two other parts of having a monopoly like that:



    1a) The customer Adobe is selling to changes from the artists and individual users, to (like Office, Windows or any other similar monopoly situation), businesses and business groups. The licences are bought up in large numbers and the product is aimed at the large licensee (company), not the end user. This sometimes helps the professional users who work at those companies, but generally works against the "regular" end user of the product. This is also why the price is so high and why at some point you end up seeing the company put out a "light" version of the professional product to attract "regular" users back.



    1b) Because the product is now sold to large institutions and companies as opposed to end users, it starts acquiring all kinds of extra features as the price/value proposition is what's being hyped in the marketing materials. You get an "all features plus the kitchen sink" approach that makes the program all things to all people, except it has the side effect of making it almost useless to a user with a focussed set of tasks.



    The "suite" approach to software also creates a very similar set of problems all by itself, so a monopoly suite-based software solution is a kind of "double-whammy" and is always going to be a pile of doo-doo. What's needed is really the opposite to a suite which is an "extensible tools" approach but that's a long argument.



    Morphologically though, it's the difference between a big round blob, and a stellate shape.
  • Reply 20 of 69
    Quote:
    Originally Posted by ascii View Post


    I don't think this article is quite right. Carbon is not the lower level C API that Cocoa (the higher level Objective C API) is built on - that is Core Foundation.



    Carbon really can be totally removed and leave Core Foundation as the pure C API. The only thing they won't be able to do in Core Foundation is GUI. But if anything is suited to OO style, it's GUI development, so it really does make sense for Apple to insist that people use Objective-C if they want a GUI.



    You're only partially right. In the long term, all the public frameworks and API's are going to be either Cocoa or Core Foundation-like. However, as things stand, a lot of API's are implemented in or are part of Carbon, particularly Audio, Video, and File System management APIs. Some steps have been made to transition away from Carbon in Leopard by replacing functions that expect Carbon objects with ones that expect Core Foundation ones, but many of them are likely just wrappers around the old functions until a clean implementation can be written (ex. the new ExtendedAudioFile functions that expect CFURLs instead of FSRefs - CFURL objects are easily converted to FSRefs and back).
Sign In or Register to comment.