Apple legt nog meer nadruk op Cocoa-framework in Mountain Lion

Apple legt in het aankomende OS X Mountain Lion nog meer de nadruk op het Cocoa-framework. Zo zal de Carbon-api als deprecated worden beschouwd en voor het X11-framework is voortaan een optionele opensource-package nodig.

Bij het installeren van een applicatie die het X11- framework nodig heeft, zal Mountain Lion niet langer de mogelijkheid bieden om een optioneel X11-pakket van Apple te installeren, zo meldt Apple Insider. Het besturingssysteem zal voortaan doorverwijzen naar een opensource-variant van het framework, XQuartz geheten. Na installatie kan een gebruiker alsnog op X11-gebaseerde software draaien.

In OS X 10.8 Mountain Lion, dat deze zomer beschikbaar moet komen en momenteel als developer preview is te verkrijgen, is ook de verouderde Carbon-api definitief afgeschreven. Zo mist Carbon ondersteuning voor 64bit-applicaties.

Met het stapsgewijs 'afdanken' van Carbon in de laatste OS X-releases en het doorschuiven van X11- en Java-ondersteuning naar externe opensource-projecten, stuurt Apple meer en meer OS X-ontwikkelaars richting het Cocoa-framework. Apple biedt Cocoa al enige tijd aan in OS X en zijn iOS-platform en het bedrijf acht zijn native api nu voldoende rijp om als hèt standaard framework voor OS X-software.

Reacties (67)

Cocoa al aan voor zijn iOS-platform en het bedrijf acht zijn native framework nu ook voldoende rijp om als basis te dienen voor OS X-software.

Sinds osx 10.4 ofzo was Cocoa al de default omgeving voor het ontwikkelen van OSX applicaties, de rest was gewoon legacy wat er steeds meer uitgehaald wordt.

Het is geen verrassing, Apple heeft met elke opeenvolgende release van het OS het aandeel van 'carbon code' en frameworks gebaseerd op carbon vermindert.

Carbon had initieel als doel om native OS 9 (PPC) applicaties en frameworks in OSX relatief gemakkelijk te gebruiken.

De intrede van intel architectuur luidde de finale 'doodslag' in voor carbon.
Carbon was een 'overgangs technologie'.

De reden om Carbon te houden was vn omdat Adobe (een belangrijke voorwaarde om OS X users te laten upgraden in vroege OS X tijden) nog niet zover was alles geheel te herschrijven.

Zo gaat het gerucht dat voor Adobe programma's Carbon wel 64-bit (PPC,G5 toen nog) is gemaakt, maar toen is al besloten dat niet voor gebruikers uit te brengen, met de Intel migratie aanstaande

[Reactie gewijzigd door marcovtjetje op 19 februari 2012 22:38]

Apple biedt Cocoa al aan voor zijn iOS-platform en het bedrijf acht zijn native framework nu ook voldoende rijp om als basis te dienen voor OS X-software.

Euh, wat? Cocoa is al de basis voor OSX toen OSX er nog niet eens was (toen nog in de vorm van Yellow Box in Rhapsody) en dan zo'n zin? Dat getuigt niet direct van kennis van zaken.

http://en.wikipedia.org/wiki/Cocoa_(API)#Cocoa_history
Historie van de Cocoa-API.

Je hebt helemaal gelijk.

Ik heb er in het redactieforum een postje aan gewijd.

Cocoa was er al sinds de introductie van OS X, alhoewel ook toen al gedacht werd aan een "gentle migration", door middel van Classic en Carbon.

In de keynote in 2000 legt Steve Jobs het idee van Classic, Carbon en Cocoa uit (vanaf 4:45):
http://www.youtube.com/watch?v=Ko4V3G4NqII&t=4m45s

[Reactie gewijzigd door Keypunchie op 19 februari 2012 23:49]

Jammer veel nuttige tools en utilities zijn geschreven voor de carbon api. Nadeel van Cocoa vind ik vooral de overhead vanwege de message passing van objective c

En het feit dat Objective C Apple centrisch is. De oude procedurele APIs maken toch een wat vrijere tool keuze mogelijk.

De Carbonicide was vooral een klap voor de oude Apple shareware sector, die snel achter elkaar

• meerdere architectuur veranderingen (32-bit PPC -> 64-bit PPC -> 32-bit Intel. Nu 64-bit Intel, maar daar zat wat meer tijd tussen)
• een API verandering,
• en daaraan een nieuwe taal en IDE verbonden. Tuurlijk, in theorie niet, maar in praktijk komt het daar wel op neer.

voor de kiezen kreeg.

Kort gezegd, weggooien en geheel opnieuw beginnen. Maar dat vereist investeringen, en dat bij toegenomen concurrentie. De sector was gemiddeld ook al op leeftijd (zeg wat nu veertigers zijn, al waren ze toen (2003) bijna 10 jaar jonger)

De kleine jongens zijn er grotendeels uitgestapt, en er is grotendeels alleen stapels oppervlakkige "apps" voor in de plaats gekomen.

[Reactie gewijzigd door marcovtjetje op 19 februari 2012 22:59]

Ze hebben dat dan wel een beetje aan zichzelf te danken. Volgens mij was vanaf dag 1 dat OS X uit kwam al duidelijk dat Carbon een overgangs-API was. Dat veel applicaties daar in zijn blijven hangen, is een gegeven waarbij ik me serieus afvraag of de applicatie-bouwers daar niet laks zijn geweest. Of misschien was Apple wel naief om te denken dat vendors eventually wel over zouden stappen op Cacoa.

Klopt, maar dat wil niet zeggen dat het substituut toen al klaar was. Dat kwam pas met 10.3/10.4.

En ik denk ook niet dat Apple er zo makkelijk vanaf gekomen was als IPhone en IPad niet zo'n success waren geweest. De nieuwe platformen zijn de reden dat Apple dit zich überhaupt kan permitteren.

[Reactie gewijzigd door marcovtjetje op 20 februari 2012 16:34]

Klopt, maar dat wil niet zeggen dat het substituut toen al klaar was. Dat kwam pas met 10.3/10.4.

Cocoa was al vóór de release van OSX de standaard voor het programmeren van apps voor het nieuwe OS destijds, inclusief het gros van de software die bij de eerste release van het OS zat (zelfs de versie zonder aqua).

De nieuwe platformen zijn de reden dat Apple dit zich überhaupt kan permitteren.

Apple heeft in haar geschiedenis veel grote overgangen van technologie gemaakt, 3 processor architecturen, 3 OSen, ook toen ze nog geen iPod of iPhone hadden. Al deze ontwikkeling komt ook uit de tijd vóór de iPod/iPhone/iPad. Zo nu en dan het roer omgooien, migreren zonder (goede) backwards compatibility zijn altijd de kenmerken geweest van Apple (los van of het goed of fout is). De tijd dat ze het langst zijn blijven haken op een standaard is de slechtste periode van Apple geweest.

[Reactie gewijzigd door Kura op 20 februari 2012 17:03]

Er is een verschil tussen intentie en realiteit.

En wat betreft de "slechtste periode", dat is een smaak issue. Een lange termijn, zeer diverse industrie omzeep halen is twijfelachtig.

Tuurlijk, de huidige transitie van een hardware verkoper naar een entertainment hub is achteraf gezien financieel gezien een gouden greep. Maar dat was toen niet bekend.

Daarom is de carbonicide helemaal niet zo absoluut gegaan als je nou doet voorkomen, maar stapje bij stapje, waarbij Apple keek hoe ver ze konden gaan, en hoe sterk ze stonden.

En dat bleek dankzij IPod/Iphone ijzersterk te zijn.

Vanuit softwareontwerp oogpunt is dat message passing gedoe wel een mooie manier om je programma modulair op te bouwen.

Modulair opgebouwde programma's kun je net zo makkelijk in C schrijven.

Het kan wel, maar niet net zo makkelijk. By far niet.

Modulair opgebouwde programma's kun je net zo makkelijk in C schrijven.

In feite is Objective-C gewoon C plus een hele berg uitbreidingen om object-georienteerd en/of component-based te kunnen programmeren, met een soort hybride dynamic-typing/duck-typing die het mogelijk maakt code te schrijven die onafhankelijk is van de exacte interface en implementatie van classes die je er mee aanroept, zo lang ze maar op de juiste manier op de juiste messages reageren.

Er is niks in C dat niet mogelijk is in Objective-C (het is immers 100% compatible), maar er is wel van alles mogelijk in Objective-C waar je heel veel moeite voor moet doen in C. De opmerking dat het 'net zo makkelijk is' om wat dan ook te implementeren in C als in Objective-C raakt dan ook kant noch wal.

Nadeel van Cocoa vind ik vooral de overhead vanwege de message passing van objective c

Klop, Objective-C message dispatch is trager dan een C++ virtual function call.
Maar met Cocoa (UI,networking,diskio) is dat in de praktijk eigenlijk nooit een probleem.

Ik heb tijdens mijn 10+ jaar Objective-C ervaring nog maar één keer meegemaakt dat die overhead een performance probleem tot gevolg had.

Dat programma deed gigantisch veel set bewerkingen op CoreFoundation sets met duizenden objecten.

Daar het in de mainthread gebeurde werd de UI (op een Mac-mini G4) voor 4-5 seconden geblokkeerd.

Dat UI probleem was eenvoudig op te lossen door de bewuste routine in een aparte thread te zetten, maar 5 seconden kijken naar een progressbar is ook niet ideaal.

Uiteindelijk heb ik de CoreFoundation collection classes vervangen door STL (C++) en voilà de executie tijd was gereduceerd tot iets minder dan 1 seconde

[Reactie gewijzigd door Carbon op 20 februari 2012 11:08]

Klop, Objective-C message dispatch is trager dan een C++ virtual function call.
Maar met Cocoa (UI,networking,diskio) is dat in de praktijk eigenlijk nooit een probleem.

Sterker nog, alleen de eerste message die naar een selector van een bepaalde instance wordt gestuurt is trager (2x zo traag naar het schijnt) dan een virtual method call in C++, alle volgende aanroepen worden ge-IMP-cached, en dan zijn ze 2x zo snel.

Als de overheid van message parsing relevant is voor de snelheid of de responsiveness van je applicatie, dan doe je iets verkeerd, en wil je waarschijnlijk een loop opschrijven waar je uberhaupt geen functie calls uitvoert (zoals in jouw voorbeeld, STL collections zijn template-based waardoor bijna alle operaties door de compiler kunnen worden geinlined).

Op de schaal van efficiente programmeertalen valt Objective-C in hetzelfde groepje als C en C++, met andere woorden: veel sneller krijg je het niet.

Ach, XQuartz wordt toch al door Apple medewerkers gemaakt, dus veel zal er niet veranderen. Alleen dat je het dus zelf even moet downloaden.

Hierdoor wordt de installatie lichter Een steeds groter deel van het OS wordt optioneel gemaakt via downloads, waardoor de installatie sneller wordt (en dus ook de download, aangezien Apple heeft gekozen om te stoppen met fysieke media). 99% van de gebruikers zal X11 toch niet gebruiken. Ditzelfde gold voor Rosetta in Leopard en ook voor Java.

Ik denk dat meer OSX gebruikers java gebruiken dan dat ze er zelf erg in hebben. Adium is bijvoorbeeld in java geschreven en zo zijn er nog wat meer populaire applicaties.

Euhm.. niet echt.. De meeste applicaties zijn geschreven in Objective-C / C/ C++. Slechts enkele applicaties zijn ontwikkeld in java, en dan met name de IDE's zoals IntelliJ, Eclipse en wat subversion clients. En dat zijn meestal ook de geheugen vreters... De pain van cross-platform support (maar anders hadden we die pakketten misschien ook niet gehad op de Mac;) ).

Adium is written primarily in Objective-C.

bron

Wat betreft het uitfaseren van X11, dat is ook niet echt onverwacht. Ik denk dat 99.9% van de gebruikers niet weet wat het is, laat staan dat ze het hebben gebruikt. Voor die overige 0.1% kan je het prima door de open source community op laten lossen (bijvoorbeeld via MacPorts of een dedicated installer). De enige keren dat ik zelf gebruikt heb gemaakt van X11 is om via X11forwarding op een remote machine applicaties te starten, maar aangezien servers in het algemeen ook geen X11 (en dus X11 apps) hebben, komt die usecase ook nauwelijks voor.

Wat betreft Cocoa vs Carbon, Carbon wordt al jaren uitgefasseerd en alle API's en Frameworks zijn -voor zover ik weet- gericht op gebruikt icm met Cocoa. Ik weet nog te weinig van Obj-C (lerende;) maar ik vraag me af of je Grand Central Dispatch, Core Animation, Core Video etcetera wel kan gebruiken in Carbon. Dat Apple deze stap zet in Mountain Lion is eigenlijk meer evolutie van een proces dat al jaren in gang is, en niet overwacht.

Misschien dat ze nu met die stap komen omdat de grootste speler die nog op Carbon zat (Adobe) nu ook alles heeft omgeschreven naar Cocoa. Ik kan me voorstellen dat Apple aan Adobe een Ultimatum heeft gegeven, tot 2012 supporten we Carbon, daarna alleen nog maar Cocoa...

Adobe had wanted to add the GPU acceleration and background save features to Photoshop for some time, but programmers had been derailed by the need to move from Apple’s older Carbon user interface to its newer Cocoa interface after Apple canceled its plans for 64-bit Carbon support, said John Nack, an Adobe principal product manager.

“Both of these features have been in the team’s sights for a long time, but they kept getting derailed by things like the Carbon-to-Cocoa conversion effort. Nice to have that behind us,” Nack said...

bron

[Reactie gewijzigd door 4np op 20 februari 2012 09:59]

maar ik vraag me af of je Grand Central Dispatch, Core Animation, Core Video etcetera wel kan gebruiken in Carbon.

Grand Central Dispatch en Core Video hebben een C API en zijn gewoon bruikbaar onder Carbon.

Voor Carbon heeft Apple HICocoaView bedacht zodat je binnen een Carbon App gebruik kunt maken van o.a. Core Animation.

Klets. Carbon was diehard oude code die deels (o.a. qua principes) nog uit de tijd van <10MB geheugen stamde.

Een kleine minor uitbreiding aan cocoa en daar past carbon 5 keer in.

[Reactie gewijzigd door marcovtjetje op 19 februari 2012 22:37]

Ik had het eigenlijk over X11.

Klets. Carbon was diehard oude code die deels (o.a. qua principes) nog uit de tijd van <10MB geheugen stamde.

Een kleine minor uitbreiding aan cocoa en daar past carbon 5 keer in

Carbon is niet mega groot nee, maar overdrijven is ook een vak. Het stamt zeker niet 'uit de tijd van <10 MB geheugen', ik denk dat jij aan OS 8 en OS 9 zit te denken. Die hadden origineel geen Carbon: Carbon was een soort her-implementatie van OS 9 API's, met daar bovenop van alles en nog wat dat altijd alleen voor OS X beschikbaar is geweest. Zo zijn er in de loop van de tijd allerlei systeem frameworks aan OS X toegevoegd die Carbon-specifiek zijn, en nu dus waarschijnlijk allemaal opgeruimd kunnen worden.

Hoe kan ik zien van welk framework mijn applicatie gebruik maakt? Ik kan wel GCC vertellen om Cocoa te gebruiken (-framework cocoa) maar ik vraag me af of hij dan default Carbon gebruikt.

Als je "-framework cocoa" meegeeft als parameter include hij waarschijnlijk gewoon Foundation (basis Cocoa) in je applicatie, het is niet dat je code zich magisch aanpast om de juiste functies aan te roepen.

Vrij simpel gezegd, als je in XCode sinds 10.4 een nieuwe applicatie maakt is het standaard Cocoa.

[Reactie gewijzigd door ZpAz op 19 februari 2012 18:45]

Ik maak echter geen gebruik van XCode, maar gewoon van command line GCC en GNU make.

Dan heb je hier niks mee te maken. Cocoa is een framework dat je zelf kan gebruiken, in plaats van dingen zelf maken (bijv. GUI's, werken met bestanden, Apple API's e.d.) kan je dus een groot aantal van tevoren voorbereide onderdelen van Apple gratis gebruiken.

Als je bijv. gewoon lekker in C of C++ of Obj-C bezig bent en geen frameworks/libs/headers aan het includen bent die binnen Carbon vallen heb je nergens last van.

Als je "-framework cocoa" meegeeft als parameter include hij waarschijnlijk gewoon Foundation (basis Cocoa) in je applicatie, het is niet dat je code zich magisch aanpast om de juiste functies aan te roepen.

Ik vraag me af of de switch '-framework cocoa' uberhaupt iets doet, volgens mij geef je daar altijd de naam van een framework aan mee, en Cocoa.framework bestaat volgens mij niet eens. Wel een hele sloot aan losse frameworks die verschillende onderdelen van Cocoa implementeren, waaronder de meest basale die je zelf al noemt, Foundation.framework. Het zou me niet verbazen als OS X gcc Foundation.framework gewoon automatisch meelinked, ook als je niks opgeeft (een beetje net zoals libstdc++ voor C++ applicaties dus).

[Reactie gewijzigd door johnbetonschaar op 20 februari 2012 16:13]

Het is al lang geleden dat ik nog OSX nog gebruikt heb (Tiger), maar moest je sowieso X11 niet apart installeren ?
Dat was toch niet standaard mee geinstalleerd ?

In Snow Leopard en Lion is dat iig wel standaard geïnstalleerd. Weet niet vanaf weer ze dat zijn gaan doen.

Al zolang als ik me herinner, dus waarschijnlijk ook in Leopard.

Sinds 10.5

Apple biedt Cocoa al aan voor zijn iOS-platform en het bedrijf acht zijn native framework nu ook voldoende rijp om als basis te dienen voor OS X-software.

Dat is onzin. Cocoa is al sinds de eerste versie van OS X stabiel en beschikbaar. Carbon was niets meer dan een overgangs-API om de transitie van classic naar cocoa te ondersteunen. iOS kreeg ook Cocoa als API, maar niet Carbon omdat dat, naja, nogal onlogisch zou zijn, omdat carbon geen touch support heeft.

Step/Cocoa had Touch ook niet, maar het is er aan toegevoegd. Dat het niet aan Carbon is toegevoegd is een keus, geen logica.

De enige logica is dat een en ander een gevolg is van de deprecatie van Carbon, technisch zijn er niet echt redenen. Cocoa steunt intern nog steeds deels op Carbon, alleen Apple wil meer vrijheid in die interne API.

[Reactie gewijzigd door marcovtjetje op 19 februari 2012 22:43]

Hoe bedoel je dat Cocoa steunt op Carbon? Volgens mij zijn zowel Cocoa als Carbon API's naar het subsystem van OS X, alleen is Carbon minder uitgebreid en had het C-support, zodat oude classic apps geport konden worden zonder taal-wissel. Nu iedereen zo'n beetje Cocoa gebruikt, is het voor Apple minder interessant Carbon te blijven bijhouden.

Anyway, mijn punt was dat in het artikel gesuggereerd wordt dat Cocoa nog niet volwassen was op OS X. Quite the contrary. Cocao is al jaren het platform waar men voor kiest bij de bouw van apps voor OS X, tenzij het echt niet kon.

Voor zover ik weet is er geen verschil tussen de kern van Carbon en het OS X subsysteem.

Sommige, meer uitwaards liggende lagen van Carbon zijn standalone, maar bij mijn weten is het overgrote deel van de OS lagen van OS X en Carbon een en hetzelfde. Veel is er echter niet over bekend, en ik ben altijd nieuwsgierig naar urls.

De Carboncide heeft veel meer met het stoppen van de end-user support (en per versie compatibility requirements) van die laag te maken dan met het verwijderen of obsolete zijn ervan.

Ach, X11 is eigenlijk niets meer dan XQuartz. Onder Lion is het nu XQuartz 2.6.3 dat als X11 wordt voorgesteld.

x11.app ja. X11 bestaat al heel lang.

Kan iemand de link uitleggen met Dashcode/Instruments/Quarz Composer/Xcode dat in het mapje Developer staat op de Mac?

Quartz is geloof ik de renderer van OSX's UI. Dus geen link.
EDIT:
Quartz Compositor is de windowing server van OSX. X11 is ook een windowing server. XQuartz zorgt ervoor dat applicaties die zijn gemaakt voor X11 ook onder Quartz werken.

Quartz Composer is een node-based programming tool, waarmee je dingen kan renderen op Quartz of iets dergelijks.

[Reactie gewijzigd door Wolfos op 19 februari 2012 18:26]

Weer een apple faal... Kom op tweakers dat kan echt beter. Apple acht cocoa niet nu pas rijp voor osx. Het is al jaren het default framework. Ze beginnen nu pas de andere uit te faceren als default geinstaleerd..

Dat klopt, Carbon is al deprecated sinds Leopard en is sinds Snow Leopard niet meer in XCode aanwezig.

Dat dacht ik ook meteen, het gaat hier om programmeurszaken! Iets dat toch wel correct mag verschijnen op een website als tweakers.net! We zijn tenslotte tweakers en geen doorsnee eindgebruikers.