Cocoa (API): Difference between revisions

Content deleted Content added
Bender the Bot (talk | contribs)
m Other bindings: HTTP to HTTPS for SourceForge
 
(390 intermediate revisions by more than 100 users not shown)
Line 1:
{{Short description|MacOS framework}}
<!-- Deleted image removed: [[image:Cocoa dev screenshot.png|thumb|right|200px|A Cocoa application being developed using [[Xcode]]. [[Interface Builder]] windows are also visible.]] -->
{{Use mdy dates|date=October 2013}}
'''Cocoa''' is [[Apple Inc.]]'s native [[object-oriented]] application program environment for the [[Mac OS X]] [[operating system]]. It is one of five major [[Application programming interface|API]]s available for Mac OS X; the others are [[Carbon (API)|Carbon]], [[Macintosh Toolbox|Toolbox]] (for the obsolete [[Classic (Mac OS X)|Classic]] environment), [[POSIX]] (for the [[Berkeley Software Distribution|BSD]] environment), and [[Java platform|Java]].
{{Infobox software
| name = Cocoa
| logo =
| developer = [[Apple Inc.]]
| released = <!-- {{start date and age|df=yes/no|199?|MM|DD}} -->
| latest release version =
| latest release date =
| latest preview version =
| latest preview date =
| programming language = [[C (programming language)|C]], [[C++]], [[Objective-C]], [[Swift (programming language)|Swift]]
| operating system = [[macOS]]
| genre = [[Software framework]]
| license = [[Proprietary software|Proprietary]]<br />with some open source components{{citation needed|date=June 2016}}
| website = {{URL|developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CocoaFundamentals/WhatIsCocoa/WhatIsCocoa.html|Apple Developer}}
}}
'''Cocoa''' is [[Apple Inc.|Apple]]'s native [[object-oriented programming|object-oriented]] [[application programming interface]] (API) for its [[Desktop computer|desktop]] [[operating system]] [[macOS]].
 
Cocoa consists of the [[Foundation Kit]], [[Application Kit]], and [[Core Data]] frameworks, as included by the <code>Cocoa.h</code> header file, and the libraries and frameworks included by those, such as the C standard library and the Objective-C runtime.<ref name="apple1">[https://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/OSX_Technology_Overview/SystemFrameworks/SystemFrameworks.html Mac Technology Overview: OS X Frameworks]. Developer.apple.com. Retrieved on September 18, 2013.</ref>
Cocoa applications are typically developed using the development tools provided by Apple, specifically [[Xcode]] (formerly [[Project Builder]]) and [[Interface Builder]], using the [[Objective-C]] language. However, the Cocoa programming environment can be accessed using other tools, such as [[Pascal (programming language)|Pascal]], [[Python (programming language)|Python]], [[Perl]] and [[Ruby (programming language)|Ruby]], with the aid of bridging mechanisms such as [[PasCocoa]], [[PyObjC]], [[CamelBones]] and [[RubyCocoa]], respectively. It is also possible to write Objective-C Cocoa programs in a simple [[text editor]] and build it manually with [[GNU Compiler Collection|GCC]] or [[GNUstep]]'s [[makefile]] scripts.
 
Cocoa applications are typically developed using the development tools provided by Apple, specifically [[Xcode]] (formerly [[Project Builder]]) and [[Interface Builder]] (now part of Xcode), using the [[programming language]]s [[Objective-C]] or [[Swift (programming language)|Swift]]. However, the Cocoa programming environment can be accessed using other tools. It is also possible to write Objective-C Cocoa programs in a simple [[text editor]] and build it manually with [[GNU Compiler Collection]] (GCC) or [[Clang]] from the command line or from a [[Make (software)|makefile]].
For [[end-user (computer science)|end-users]], Cocoa [[Application software|application]]s are considered to be those written using the Cocoa programming environment. Such applications usually have a distinctive feel, since the Cocoa programming environment automates many aspects of an application to comply with Apple's [[Human interface guidelines]].
 
For [[end user]]s, Cocoa [[application software|applications]] are those written using the Cocoa programming environment. Such applications usually have a familiar look and feel, since the Cocoa programming environment provides a lot of common [[User interface|UI elements]] (such as buttons, scroll bars, etc.), and automates many aspects of an application to comply with Apple's [[human interface guidelines]].
== Cocoa history ==
 
For [[iOS]], [[iPadOS]], [[tvOS]], and [[watchOS]], APIs similar to Application Kit, named [[UIKit]] and WatchKit, are available; they include [[gesture recognition]], [[animation]], and a different set of [[graphical control element]]s that are designed to accommodate the specific platforms they target. Foundation Kit and Core Data are also available in those operating systems. It is used in [[application software|applications]] for Apple devices such as the [[iPhone]], the [[iPod Touch]], the [[iPad]], the [[Apple TV]], and the [[Apple Watch]].
Cocoa is derived from the [[NeXTSTEP]] and [[OPENSTEP]] programming environments developed by [[NeXT]] in the late 1980s. Apple acquired NeXT in December [[1996]], and subsequently went to work on the [[Rhapsody (operating system)|Rhapsody]] operating system that was supposed to be the direct successor of OPENSTEP. It was to have an emulation base for [[Mac OS]] applications, called ''Blue Box''. The OPENSTEP base of libraries and binary support was termed ''Yellow Box''. Rhapsody evolved into Mac OS X, and the Yellow Box became Cocoa. As a result, Cocoa classes begin with the acronym "NS" (standing either for the NeXT-Sun creation of OPENSTEP, or for the original proprietary term for the OPENSTEP framework, NeXTSTEP<ref>[http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/WhatIsCocoa/chapter_2_section_6.html Apple explains the history of the NS prefix]</ref>): NSString, NSArray, etc.
 
==History==
Much of the work that went into developing OPENSTEP was applied to the development of Mac OS X, Cocoa being the most visible part. There are, however, some differences. For example, NeXTSTEP and OPENSTEP used [[Display PostScript]] for on-screen display of text and graphics, while Cocoa depends on Apple's [[Quartz (graphics layer)|Quartz]] (which uses the [[Portable Document Format|PDF]] imaging model). Cocoa also has a level of Internet support, including the NSURL and WebKit [[HTML]] classes, and others, while under OPENSTEP there was only rudimentary support for managed network connections through NSFileHandle classes and [[Berkeley sockets]].
{{further|History of macOS}}
Cocoa continues the lineage of several [[software framework]]s (mainly the ''App Kit'' and ''Foundation Kit'') from the [[NeXTSTEP]] and [[OpenStep]] programming environments developed by [[NeXT]] in the 1980s and 1990s. Apple acquired NeXT in December 1996, and subsequently went to work on the [[Rhapsody (operating system)|Rhapsody]] operating system that was to be the direct successor of [[OPENSTEP]]. It was to have had an emulation base for [[classic Mac OS]] applications, named ''Blue Box''. The OpenStep base of libraries and binary support was termed ''Yellow Box''. Rhapsody evolved into Mac OS X, and the Yellow Box became Cocoa. Thus, Cocoa classes begin with the letters ''NS'', such as NSString or NSArray. These stand for the original proprietary term for the OpenStep framework, NeXTSTEP.<ref>{{cite book|url=https://books.google.com/books?id=K8vUkpOXhN4C&q=NS+prefix|quote=Cocoa is an important inheritance from NeXT, as indicated by .. the "NS" prefix|title=Mac OS X Internals: A Systems Approach|author=Amit Singh|date=June 19, 2006|publisher=Addison-Wesley Professional |isbn=0-321-27854-2}}</ref>
 
Much of the work that went into developing OpenStep was applied to developing Mac OS X, Cocoa being the most visible part. However, differences exist. For example, NeXTSTEP and OpenStep used [[Display PostScript]] for on-screen display of text and graphics, while Cocoa depends on Apple's [[Quartz (graphics layer)|Quartz]] (which uses the [[Portable Document Format]] (PDF) imaging model, but not its underlying technology). Cocoa also has a level of Internet support, including the NSURL and [[WebKit]] [[HTML]] classes, and others, while OpenStep had only rudimentary support for managed network connections via NSFileHandle classes and [[Berkeley sockets]].
Prior to its current use, the "Cocoa" trademark was the name of an application that allowed children to create multimedia projects. It was originally known as [[KidSim]], and is now licensed to a third party and marketed as [[Stagecast Creator]]. The program was discontinued in one of the [[rationalization (economics)|rationalizations]] that followed [[Steve Jobs]]' return to Apple. The name was re-used to avoid the delay while registering a new [[trademark]], with Stagecast agreeing to market the older Cocoa under a new name.
 
The API toolbox was originally called “Yellow Box” and was renamed to Cocoa - a name that had been already trademarked by Apple. Apple's ''Cocoa'' trademark had originated as the name of a multimedia project design application for children. The name was intended to evoke "Java for kids", as it ran embedded in web pages.<ref>{{cite news|last1=Mardesich|first1=Jodi|title=A Sour Note in Apple's Rhapsody Once-Loyal Software Writers Wary of New OS as Crucial Conference Looms|url=http://nl.newsbank.com/nl-search/we/Archives?p_product=SJ&p_theme=sj&p_action=search&p_maxdocs=200&s_dispstring=allfields(Peter%20Jensen)%20AND%20date(1/1/1997%20to%201/1/1998)&p_field_date-0=YMD_date&p_params_date-0=date:B,E&p_text_date-0=1/1/1997%20to%201/1/1998)&p_field_advanced-0=&p_text_advanced-0=(%22Peter%20Jensen%22)&xcal_numdocs=20&p_perpage=10&p_sort=YMD_date:D&xcal_useweights=no|access-date=13 August 2015|agency=San Jose Mercury News|issue=Morning Final|date=April 14, 1997|archive-url=https://web.archive.org/web/20160306122132/http://nl.newsbank.com/nl-search/we/Archives?p_product=SJ&p_theme=sj&p_action=search&p_maxdocs=200&s_dispstring=allfields(Peter%20Jensen)%20AND%20date(1/1/1997%20to%201/1/1998)&p_field_date-0=YMD_date&p_params_date-0=date:B,E&p_text_date-0=1/1/1997%20to%201/1/1998)&p_field_advanced-0=&p_text_advanced-0=(%22Peter%20Jensen%22)&xcal_numdocs=20&p_perpage=10&p_sort=YMD_date:D&xcal_useweights=no|archive-date=2016-03-06|url-status=dead}}</ref> The original "Cocoa" program was discontinued following the return of [[Steve Jobs]] to Apple. At the time, Java was a big focus area for the company, so “Cocoa” was used as the new name for “Yellow Box” because, in addition to the native Objective-C usage, it could also be accessed from Java via a bridging layer.<ref>{{Citation |last=Apple Inc. |title=WWDC 1999 |date=1999-05-10 |url=http://archive.org/details/1999-05-10-wwdc-keynote-bad-audio |access-date=2024-04-27}}</ref> Even though Apple discontinued support for the Cocoa Java bridge, the name continued and was even used for the [[Cocoa Touch]] API.
 
==Memory management==
One feature of the Cocoa environment is its facility for managing dynamically allocated memory. Cocoa[[Foundation Kit]]'s NSObject class, from which most classes, both vendor and user, are derived, implements a [[reference counting]] scheme for memory management. Objects derivedthat derive from the NSObject root class respond to a <code>retain</code> and a <code>release</code> message, and keep a retain count which can be queried by sending a <code>retainCount</code> message. A newlymethod allocated object created withtitled <code>allocretainCount</code> orexists, <code>copy</code>but hascontrary ato retainits countname, ofwill one.usually Sendingnot that object a <code>retain</code> message incrementsreturn the retain count, while sending it a <code>release</code> message decrements theexact retain count. Whenof an object's. retain count reaches zero, itIt is deallocated,mainly itsused memoryfor freed. (Deallocation is to [[Objectivesystem-C]]level objects as [[destructor (computer science)|destruction]] is to C++ objectspurposes. TheInvoking <code>dealloc</code>it method is functionally similar to a C++ ''destructor''. <code>dealloc</code>manually is not guaranteedrecommended toby be invoked.) This reference counting approach is very similar to that of Microsoft's [[Component Object Model|COM]] which features the [[IUnknown]] interface. [[IUnknown]] provides equivalents to <code>retain</code> and <code>release</code> in the form of <code>AddRef</code> and <code>Release</code>Apple.
 
A newly allocated object created with <code>alloc</code> or <code>copy</code> has a retain count of one. Sending that object a <code>retain</code> message increments the retain count, while sending it a <code>release</code> message decrements the retain count. When an object's retain count reaches zero, it is deallocated by a procedure similar to a C++ ''destructor''. <code>dealloc</code> is not guaranteed to be invoked.
 
Starting with Objective-C 2.0, the Objective-C runtime implemented an optional [[Objective-C#Garbage collection|garbage collector]], which is now obsolete and deprecated in favor of [[Automatic Reference Counting]] (ARC). In this model, the runtime turned Cocoa [[reference counting]] operations such as "retain" and "release" into [[no-op]]s. The garbage collector does not exist on the [[iOS]] implementation of Objective-C 2.0. Garbage collection in Objective-C ran on a low-priority background thread, and can halt on Cocoa's user events, with the intention of keeping the user experience responsive. The legacy garbage collector is still available on Mac OS X version 10.13, but no Apple-provided applications use it.
In addition to manual [[reference counting]], application programmers may choose to make use of ''autorelease pools''. Sending an object an <code>autorelease</code> message registers a future release with that thread's nearest autorelease pool. When the autorelease pool is itself released, it sends a corresponding <code>release</code> message for every registered <code>autorelease</code>. Autorelease pools are generally created and released at the beginning and end of the event loop, guaranteeing program flow has passed out of the block where objects were autoreleased. This means the application has predictable performance and memory collection is generally invisible to the user, whereas under most fully automated schemes the application will sometimes suddenly stop responding when the garbage collection system is started.
 
In 2011, the [[LLVM]] compiler introduced [[Automatic Reference Counting]] (ARC), which replaces the conventional garbage collector by performing static analysis of Objective-C source code and inserting retain and release messages as necessary.
Automatic garbage collection for Cocoa is also supported starting with Objective-C 2.0, using [[Xcode]] 3.0 which is included with [[Mac OS X v10.5|Mac OS X 10.5]] Leopard. The programmer now has the choice of whether to manually manage memory of objects or not. Opinions on this are divided. Some say that [[reference counting]] is superior because it allows the programmer to have precise control over when objects are deallocated, but does not add the burden of doing so for every object a program allocates, nor incur the performance penalty usually associated with automatic garbage collection. Others say the entire scheme is unnecessary, that Java-style automatic [[garbage collection (computer science)|garbage collection]] is superior, because it significantly reduces the possibility of programmer error in memory management. Cocoa garbage collection is fully backwards compatible; it is only used if the project settings are modified to take advantage of it. Furthermore, garbage collection can be turned on or off at different points in the program.
 
==Main frameworks==
Cocoa consists of three [[Objective-C]] object libraries called ''[[Application framework|frameworks]]''. Frameworks are functionally similar to [[Library (computer science)|shared libraries]], a compiled object that can be dynamically loaded into a program's address space at runtime, but frameworks add associated resources, header files, and documentation. The Cocoa frameworks are implemented as a type of [[bundle (macOS)|bundle]], containing the aforementioned items in standard locations.
 
* ''[[Foundation Kit]]'' (''Foundation''), first appeared in Enterprise Objects Framework on NeXTSTEP 3.<ref>[http://www.cilinder.be/docs/next/NeXTStep/3.3/nd/Foundation/HybridWorld.htmld/index.html HybridWorld]. Cilinder.be. Retrieved on September 18, 2013.</ref> It was developed as part of the OpenStep work, and subsequently became the basis for OpenStep's AppKit when that system was released in 1994. On macOS, Foundation is based on [[Core Foundation]]. Foundation is a generic object-oriented library providing [[string (computer science)|string]] and value manipulation, [[container (data structure)|containers]] and [[iteration]], [[distributed computing]], [[event loop]]s (run loops), and other functions that are not directly tied to the graphical user interface. The "NS" prefix, used for all classes and [[constant (programming)|constants]] in the framework, comes from Cocoa's OPENSTEP heritage, which was jointly developed by NeXT and [[Sun Microsystems]].
Cocoa consists primarily of two [[Objective-C]] object libraries called ''[[application framework|framework]]s''. Frameworks are functionally similar to [[Library (computer science)|shared libraries]], a compiled object that can be dynamically loaded into a program's address space at runtime, but frameworks add associated resources, header files, and documentation.
* ''[[Application Kit]]'' (''AppKit'') is directly descended from the original NeXTSTEP Application Kit. It contains code programs can use to create and interact with [[graphical user interface]]s. AppKit is built on top of Foundation, and uses the same ''NS'' prefix.
* ''[[Core Data]]'' is the object persistence framework included with Foundation and Cocoa and found in Cocoa.h.<ref name="apple1"/>
 
A key part of the Cocoa architecture is its comprehensive views model. This is organized along conventional lines for an application framework, but is based on the [[Portable Document Format]] (PDF) drawing model provided by [[Quartz (graphics layer)|Quartz]]. This allows creating custom drawing content using [[PostScript]]-like drawing commands, which also allows automatic printer support and so forth. Since the Cocoa framework manages all the clipping, scrolling, scaling and other chores of drawing graphics, the programmer is freed from implementing basic infrastructure and can concentrate on the unique aspects of an application's content.
* ''[[Foundation Kit]]'', or more commonly simply '''Foundation''', first appeared in OpenStep. On Mac OS X, it is based on [[Core Foundation]]. Foundation is a generic object-oriented library providing [[string (computer science)|string]] and value manipulation, [[container (data structure)|containers]] and [[iteration]], [[distributed computing]], [[event loop|run loop]]s, and other functions that are not directly tied to the graphical user interface. The "NS" prefix, used for all classes and [[variable#Constant|constant]]s in the framework, comes from Cocoa's '''N'''eXT'''S'''TEP heritage.
* ''[[Application Kit]]'' or '''AppKit''' is directly descended from the original NeXTSTEP Application Kit. It contains code with which programs can create and interact with [[graphical user interface]]s. AppKit is built on top of Foundation, and uses the same "NS" prefix.
 
==Model–view–controller==
A key part of the Cocoa architecture is its comprehensive views model. This is organized along conventional lines for an application framework, but is based on the [[Portable Document Format|PDF]] drawing model provided by [[Quartz (graphics layer)|Quartz]]. This allows creation of custom drawing content using [[PostScript]]-like drawing commands, which also allow automatic printer support and so forth. Since the Cocoa framework manages all the clipping, scrolling, scaling and other chores of drawing graphics, the programmer is freed from implementing basic infrastructure and can concentrate only on the unique aspects of an application's content.
{{Main article|Model–view–controller}}
 
The [[Smalltalk]] teams at [[Xerox PARC]] eventually settled on a design philosophy that led to easy development and high code reuse. Named ''[[model–view–controller]]'' (MVC), the concept breaks an application into three sets of interacting object classes:
==Model-view-controller==
 
* Model classes represent problem ___domain data and operations (such as lists of people/departments/budgets; documents containing sections/paragraphs/footnotes of stylized text).
The [[Smalltalk]] teams at [[Xerox PARC]] eventually settled on a design philosophy that led to easy development and high code reuse. Known as "[[model-view-controller]]" (MVC), the concept breaks an application into three sets of interacting object classes. Model classes represent raw data, such as documents, settings files, or objects in memory. Views are, as the name implies, representations (often visual) of the data. Controller classes contain logic which links the models to their views, and maintains state to keep them synchronized.
* View classes implement visual representations and affordances for human-computer interaction (such as scrollable grids of captioned icons and pop-up menus of possible operations).
* Controller classes contain logic that surfaces model data as view representations, maps affordance-initiated user actions to model operations, and maintains state to keep the two synchronized.
 
Cocoa's design is a fairly, but not absolutely strict application of MVC principles. Under OpenStep, most of the classes provided were either high-level View classes (in AppKit) or one of a number of relatively low-level model classes like NSString. Compared to similar MVC systems, OpenStep lacked a strong model layer. There was noNo stock class which represented a "document," for instance. During the transition to Cocoa, the model layer was expanded greatly, introducing a number of pre-rolled classes to provide functionality common to desktop applications.
 
In Mac OS X 10.3, Apple introduced the NSController family of classes, which provide predefined behavior for the controller layer. These classes are considered part of the [[Cocoa Bindings]] system, which also makes extensive use of protocols such as [[Key-Value Observing]] and [[Key-Value Binding]]. The term 'binding' refers to a relationship between two objects, often between a view and a controller. Bindings allow the developer to focus more on declarative relationships rather than orchestrating fine-grained behavior.
 
With the arrival of Mac OS X 10.4, Apple extended this foundation further by introducing the [[Core Data]] framework, which standardizes change tracking and persistence in the model layer. In effect, the framework greatly simplifies the process of making changes to application data, undoing changes (ifwhen necessary), saving data to disk, and reading it back in.
 
ByIn providing framework support for all three MVC layersdomains, Apple's goal is to reduce the amount of boilerplate or "glue" code that developers have to write, freeing up resources to spend time on application-specific features.
 
==Late binding==
In most object-oriented languages, calls to methods are represented physically by a pointer to the code in memory. This restricts the design of an application since specific "''command handling"'' classes are requiredneeded, usually organized according to the [[Chain of responsibility pattern|chain-of-responsibility]] [[design pattern (computer science)|design pattern]]. While Cocoa retains this approach for the most part, the "lateObjective-C's [[Name binding#Late static|late binding]]" of [[Objective-C]] opens up more flexibility.
 
Under Objective-C, methods are represented by a '''selector''', a string describing the method to be calledcall. When a message is sent, the selector is sent into the ObjCObjective-C runtime, matched against a list of available methods, and the method's '''implementation''' is called. Since the selector is text data, this allowslets it to be saved to a file, transmitted over a network or between processes, or manipulated in other ways. The implementation of the method is looked up at runtime, not compile time. There is a small performance penalty for this,<ref>[http[Wikibooks:Programming Mac OS X with Cocoa for beginners//en.wikibooks.org/wiki/Programming_Mac_OS_X_with_Cocoa_for_beginners/Objective_CObjective C,_the_language_and_its_advantages the language and its advantages#Some_ObjectiveSome Objective-C_advantagesC advantages|Wikibooks - Some Objective-C advantages]]</ref>, but late binding allows the same selector to reference different implementations.
 
By a similar token, Cocoa provides a pervasive data manipulation techniquemethod called ''[httpkey-value coding'' (KVC).<ref>{{Cite web |url=https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/KeyValueCoding/index.html key|title=Key-valueValue coding]''Coding (KVC).Programming Guide |access-date=September 27, 2021}}</ref> This permitsallows a piece of data or property of an object to be looked up or changed at runtime by name. &mdash; theThe property name acts as a key to the value itself. In traditional languages, this late binding is not possibleimpossible. KVC leads to great design flexibility. &mdash; anAn object's type doesneed not need to be known, yet any property of that object can be discovered using KVC. In additionAlso, by extending this system using something Cocoa callsterms '''Keykey-Valuevalue Observing'observing'' (KVO), automatic support for Undo/Redo[[undo|undo-redo]] is provided.
 
Late static binding is a variant of binding somewhere between static and dynamic binding. The binding of names before the program is run is called static (''early''); bindings performed as the program runs are dynamic (''late'' or ''virtual'').
 
==Rich objects==
One of the most useful features of Cocoa is the powerful ''base objects'' the system supplies. As an example, consider the Foundation classes <code>NSString</code> and <code>NSAttributedString</code>, which provide [[Unicode]] [[string (computer science)|strings]], and the <code>[[NSText]]</code> system in AppKit, which allows the programmer to place string objects in the GUI.
 
<code>NSText</code> and its related classes are used to display and edit strings. The collection of objects involved permit an application to implement anything from a simple single-line text entry field to a complete multi-page, multi-column text layout schema, with full professional [[typography]] features such as [[kerning]], [[Ligature (typography)|ligatures]], running text around arbitrary [[shape]]s, [[rotation]], full Unicode support, and [[Spatial anti-aliasing|anti-aliased]] [[glyph]] rendering. Paragraph layout can be controlled automatically or by the user, using a built-in "[[ruler]]" object that can be attached to any text view. Spell checking is automatic, using a system-wide set of language dictionaries. Unlimited undo/redo support is built in. Using only the built-in features, one can write a text editor application in as few as 10 lines of code. With new controller objects, this may fall towards zero.
One of the most useful features of Cocoa is the powerful "base objects" the system supplies. As an example, consider the Foundation classes <code>NSString</code> and <code>NSAttributedString</code>, which provide [[Unicode]] [[string (computer science)|string]]s, and the <code>NSText</code> system in AppKit, which allows the programmer to place string objects in the GUI.
When extensions are needed, Cocoa's use of Objective-C makes this a straightforward task. Objective-C includes the concept of "[https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocCategories.html#//apple_ref/doc/uid/TP30001163-CH20-SW1 categories]," which allows modifying existing class "in-place". Functionality can be accomplished in a category without any changes to the original classes in the framework, or even access to its source. In other common languages, this same task requires deriving a new subclass supporting the added features, and then replacing all instances of the original class with instances of the new subclass.
 
==Implementations and bindings==
<code>NSText</code> and its related classes are used to display and edit strings. The collection of objects involved permit an application to implement anything from a simple single-line text entry field to a complete multi-page, multi-column text layout schema, with full professional [[typography]] features such as [[kerning]], [[ligature (typography)|ligature]]s, running text around arbitrary [[shape]]s, [[rotation]], full Unicode support and [[antialiasing|anti-aliased]] [[glyph]] rendering. Paragraph layout can be controlled automatically or by the user, using a built-in "[[ruler]]" object that can be attached to any text view. Spell checking is automatic, using a single dictionary used by all applications that uses the "squiggly underlining" introduced by [[Microsoft]] (actually a dashed red underline in Cocoa). Unlimited Undo/Redo support is built in. Using only the built-in features, one can write a text editor application in as few as 0 lines of code. With new controller objects, this may fall to zero. This is in contrast to the [[TextEdit (API)|TextEdit]] APIs found in the earlier Mac OS.
The Cocoa frameworks are written in [[Objective-C]]. Java [[language binding|bindings]] for the Cocoa frameworks (termed the ''Java bridge'') were also made available with the aim of replacing Objective-C with a more popular language<ref>{{cite journal|url=http://www.mactech.com/articles/mactech/Vol.19/19.12/CocoaAppsinJava/index.html|title=Writing Cocoa Apps in Java|author=Steve Klingsporn|journal=[[MacTech]]|volume=19|issue=12|year=2003}}</ref> but these bindings were unpopular among Cocoa developers and Cocoa's message passing semantics did not translate well to a statically-typed language such as Java.<ref>{{cite web|url=https://developer.apple.com/legacy/library/documentation/Cocoa/Conceptual/Legacy/JavaBridge/JavaBridge.pdf|title=Using the Java Bridge|publisher=[[Apple Inc.]]|quote=Because Java is a strongly typed language, it requires more information about the classes and interfaces it manipulates at compile time. Therefore, before using Objective-C classes as Java ones, a description of them has to be written and compiled.}}</ref> Cocoa's need for runtime binding means many of Cocoa's key features are not available with Java. In 2005, Apple announced that the Java bridge was to be deprecated, meaning that features added to Cocoa in macOS versions later than 10.4 would not be added to the Cocoa-Java programming interface.
 
At [[Apple Worldwide Developers Conference]] (WWDC) 2014, Apple introduced a new programming language named [[Swift (programming language)|Swift]], which is intended to replace Objective-C.<ref>{{cite web |url=http://appleinsider.com/articles/14/06/04/apples-top-secret-swift-language-grew-from-work-to-sustain-objective-c-which-it-now-aims-to-replace |title=Apple's top secret Swift language grew from work to sustain Objective-C, which it now aims to replace|date=June 4, 2014 }}</ref>
When extensions are needed, Cocoa's use of Objective-C makes this a straightforward task. Objective-C includes the concept of "[http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/chapter_4_section_7.html#//apple_ref/doc/uid/TP30001163-CH7-TPXREF139 categories]" which allows for modifications to an existing class "in-place". Functionality can be accomplished in a category without any changes to the original classes in the framework, or even access to its source. Under more common frameworks this same task would require the programmer to make a new subclass supporting the additional features, and then change all instances of the classes to this new class.
 
===AppleScriptObjC===
==Implementations==
Originally, AppleScript Studio could be used to develop simpler Cocoa applications.<ref>{{cite web|title=AppleScript Studio Programming Guide (Not Recommended): About AppleScript Studio|url=https://developer.apple.com/legacy/library/documentation/AppleScript/Conceptual/StudioBuildingApps/chapter02/studio_about_book.html#//apple_ref/doc/uid/20001249-TPXREF101|publisher=Apple, Inc.|access-date=November 20, 2013}}</ref> However, as of Snow Leopard, it has been deprecated. It was replaced with AppleScriptObjC, which allows programming in [[AppleScript]], while using Cocoa frameworks.<ref>{{cite web |title=AppleScriptObjC Release Notes |url=https://developer.apple.com/library/mac/#releasenotes/ScriptingAutomation/RN-AppleScriptObjC/ |publisher=Apple, Inc. |access-date=November 20, 2013}}</ref>
 
===Other bindings===
The Cocoa frameworks are written in [[Objective-C]], and hence Objective-C is the preferred language for development of Cocoa applications. Java [[binding (computer science)|bindings]] for the Cocoa frameworks (known as the "Java bridge") are also available but have not proven popular amongst Cocoa developers. Further, the need for runtime binding means many of Cocoa's key features are not available with Java. In [[2005]], Apple announced that the Java bridge was to be deprecated, meaning that features added to Cocoa in Mac OS X versions later than 10.4 would not be added to the Cocoa-Java programming interface.
 
The Cocoa programming environment can be accessed using other tools with the aid of [[language binding|bridge mechanisms]] such as [[PasCocoa]], [[PyObjC]], [[CamelBones]], [[RubyCocoa]], and a [[D (programming language)|D]]/Objective-C Bridge.
[[AppleScript Studio]], part of Apple's [[Xcode]] Tools makes it possible to write (less complex) Cocoa applications using [[AppleScript]]. There is also a third-party scripting language specifically designed for Cocoa, called [http://www.fscript.org/ F-Script], that allows for native access to Cocoa objects and provides a suite of graphical introspection tools.
 
<!--Try to organize bindings, alphabetically by language.-->Third-party bindings available for other languages include [[AppleScript]], [[Clozure CL]], [[Monobjc]] and [[NObjective]] ([[C Sharp (programming language)|C#]]), [[Cocoa Sharp|Cocoa#]] (CLI), Cocodao and [[D (programming language)|D]]/Objective-C Bridge,<ref>[https://sourceforge.net/projects/cocodao/ Cocodao], bridge to create Cocoa applications in D language.</ref><ref>[http://michelf.com/weblog/2007/d-objc-bridge/ D/Objective-C Bridge], a [[language binding]] mechanism for Cocoa.</ref> [[LispWorks]], [[Object Pascal]], [[CamelBones]] ([[Perl]]), [[PyObjC]] ([[Python (programming language)|Python]]), [[FPC PasCocoa]] ([[Lazarus (IDE)|Lazarus]] and [[Free Pascal]]), [[RubyCocoa]] ([[Ruby (programming language)|Ruby]]).<ref>[http://osx.hyperjeff.net/Reference/cocoa.php more extensive list of implementations]</ref>
Third party bindings are also available for other languages:
*[[Pascal (programming language)|Pascal]] - [[PasCocoa]] [http://wiki.lazarus.freepascal.org/PasCocoa]
*[[Python (programming language)|Python]] - [[PyObjC]] [http://pyobjc.sourceforge.net]
*[[Ruby programming language|Ruby]] - [[RubyCocoa]] [http://rubycocoa.sourceforge.net/]
*[[Perl]] - [[CamelBones]] [http://camelbones.sourceforge.net]
*[[C Sharp programming language|C#]] - [[Cocoa Sharp|Cocoa#]] [http://www.cocoa-sharp.com/] - [[Monobjc]] [http://www.monobjc.net/]
*[[Objective-Basic]] - [[ObjB]] [http://www.objective-basic.com/]
 
A Ruby language implementation named [[MacRuby]], which removes the need for a bridge mechanism, was formerly developed by Apple, while [[Nu (programming language)|Nu]] is a [[Lisp (programming language)|Lisp]]-like language that uses the [[Objective-C]] object model directly, and thus can use the Cocoa frameworks without needing a binding.
A [http://osx.hyperjeff.net/Reference/cocoa.php more extensive list of implementations] is available.
 
===Other implementations===
There are also open source implementations of major parts of the Cocoa framework that allows cross-platform (including MS Windows) Cocoa application development:
There are also open source implementations of major parts of the Cocoa framework, such as [[GNUstep]] and Cocotron,<ref>[http://www.cocotron.org/ Cocotron], free software implementation of Cocoa.</ref> which allow [[cross-platform]] Cocoa application development to target other operating systems, such as [[Microsoft Windows]] and [[Linux]].
*[[GNUstep]]
 
*[[Cappuccino (Application Programming Interface)]]
==See also==
*[[libFoundation]] [http://sourceforge.net/projects/libfoundation]
{{col-list|colwidth=25em|
*[[Cocotron]] [http://code.google.com/p/cocotron/]
* [[Carbon (API)]]
* [[GNUStep]]
* [[Objective-C]]
* [[Xcode]]
* [[iOS SDK]]
* [[Interface Builder]]
* [[Aqua (user interface)]]
* [[Rosetta (software)]]
* [[XNU]]
* [[Quartz (graphics layer)]]
* [[X11]]
* [[QuickDraw]]
* [[SIMBL]]
* [[Swift (programming language)]]
}}
 
==References==
{{Reflist|30em}}
<div class="references-small">
*[[Aaron Hillegass]]: <cite>Cocoa Programming for Mac OS X</cite>, Addison-Wesley, 3rd Edition 2008, Paperback, ISBN 0-321-50361-9.
*[[Stephen Kochan]]: <cite>Programming in Objective-C</cite>, Sams, 1st Edition 2003, Paperback, ISBN 0-672-32586-1.
*[[Michael Beam]], [[James Duncan Davidson]]: <cite>Cocoa in a Nutshell</cite>, O'Reilly, 1st Edition 2003, Paperback, ISBN 0-596-00462-1.
*[[Erick Tejkowski]]: <cite>Cocoa Programming for Dummies</cite>, 1st Edition 2003, Paperback, ISBN 0-7645-2613-8.
*[[Simson Garfinkel]], [[Michael K. Mahoney]]: <cite>Building Cocoa Applications : A Step by Step Guide</cite>, O'Reilly, 1st Edition 2002, Paperback, ISBN 0-596-00235-1.
*[[James Duncan Davidson]]: <cite>Learning Cocoa with Objective-C</cite>, O'Reilly, 2nd Edition 2002, Paperback, ISBN 0-596-00301-3.
*[[Scott Anguish]], [[Erik M. Buck]], [[Donald A. Yacktman]]: <cite>Cocoa Programming</cite>, Sams, 1st Edition 2002, Paperback, ISBN 0-672-32230-7.
*[[Bill Cheeseman]]: <cite>Cocoa Recipes for Mac OS X</cite>, Peachpit Press, 1st Edition 2002, Paperback, ISBN 0-201-87801-1.
*Andrew Duncan: <cite>Objective-C Pocket Reference</cite>, O'Reilly, 1st Edition 2002, Paperback, ISBN 0-596-00423-0.
*[[Apple Inc.]]: <cite>Learning Cocoa</cite>, O'Reilly, 1st Edition 2001, Paperback, ISBN 0-596-00160-6.
 
==Bibliography==
{{Reflist}}
*[[Aaron Hillegass]]: ''Cocoa Programming for Mac OS X'', Addison-Wesley, 3rd Edition 2008, Paperback, {{ISBN|0-321-50361-9}}.
</div>
*[[Stephen Kochan]]: ''Programming in Objective-C'', Sams, 1st Edition 2003, Paperback, {{ISBN|0-672-32586-1}}.
*[[Michael Beam]], James Duncan Davidson: ''Cocoa in a Nutshell'', O'Reilly, 1st Edition 2003, Paperback, {{ISBN|0-596-00462-1}}.
*[[Erick Tejkowski]]: ''Cocoa Programming for Dummies'', 1st Edition 2003, Paperback, {{ISBN|0-7645-2613-8}}.
*{{cite book |title= Building Cocoa Applications: A Step by Step Guide |publisher=[[O'Reilly Media]] |edition=1st |date=2002 |first1=Simson |last1=Garfinkel |author-link1=Simson Garfinkel |first2=Michael K. |last2=Mahoney |isbn=0-596-00235-1 |citeseerx=10.1.1.394.3248 }}
*[[Paris Buttfield-Addison]], [[Jon Manning]]: ''Learning Cocoa with Objective-C'', O'Reilly, 3rd Edition 2012, Paperback, {{ISBN|978-1-4493-1849-9}}.
*[[Scott Anguish]], [[Erik M. Buck]], [[Donald A. Yacktman]]: ''Cocoa Programming'', Sams, 1st Edition 2002, Paperback, {{ISBN|0-672-32230-7}}.
*[[Erik M. Buck]], [[Donald A. Yacktman]]: ''Cocoa Design Patterns'', Addison-Wesley Professional, 1st Edition 2009, Paperback, {{ISBN|978-0321535023}}
*[[Bill Cheeseman]]: ''Cocoa Recipes for Mac OS X'', Peachpit Press, 1st Edition 2002, Paperback, {{ISBN|0-201-87801-1}}.
*Andrew Duncan: ''Objective-C Pocket Reference, O'Reilly'', 1st Edition 2002, Paperback, {{ISBN|0-596-00423-0}}.
 
==External links==
* [httphttps://developer.apple.com/documentationlibrary/Cocoamac/navigation/#section=Frameworks&topic=Cocoa.html%20Layer Mac Developer Library, Cocoa Layer], Apple's Cocoa documentation]
* [https://web.archive.org/web/20190202170514/http://www.cocoaboardidevapps.com/ Cocoa BoardiDevApps] - International, Mac OS X Cocoaprogramming Usergroupforum
* {{usurped|1=[https://web.archive.org/web/20201114133049/http://cocoadevcentral.com/ Cocoa Dev Central]}}
* [http://www.cocoacast.com CocoaCast] - Podcast for cocoa beginners
* [https://web.archive.org/web/20080801025517/http://www.cocoadev.com/ Cocoa Dev]
* [http://osx.hyperjeff.net/reference/CocoaArticles.php Cocoa Literature List]
* [https://stackoverflow.com/questions/tagged/cocoa Stack Overflow: Cocoa] <!-- Stack Overflow is a popular and well regarded when it comes to Cocoa and Cocoa Touch -->
* [http://pyobjc.sourceforge.net/ PyObjC]
* [http://rubycocoa.sourceforge.net/ RubyCocoa]
* [http://www.cocoadevcentral.com/ Cocoa Dev Central]
* [http://www.cocoadev.com/ Cocoa Development Wiki]
* [http://cocoablogs.com/ Cocoa Blogs] &mdash; aggregates blogs of Cocoa developers
* [http://homepage.mac.com/redbird/cocoa/ Project Cocoa] &mdash; About the "old" Cocoa, also known as [[KidSim]]
* [http://www.gnustep.org GNUstep] &mdash; cross-platform framework based on the [[OpenStep]] and major parts of Cocoa.
* [http://www.cocotron.org Cocotron] &mdash; cross-platform (focus on Windows) framework, similar approach as GNUstep.
* [http://actionstep.org ActionStep] &mdash; cross-platform framework for building rich web applications in Flash based on Cocoa
* [http://developer.apple.com/cocoa/pyobjc.html Apple's PyObjC Tutorial]
* [http://www.objective-basic.com Objective-Basic - Full featured object oriented modern BASIC programming language for Cocoa]
* [http://www.cocoalab.com/BecomeAnXcoder.pdf Become an Xcoder] - PDF for learning how to write Cocoa in [[Xcode]]
* [http://www.latenightcocoa.com/ Late Night Cocoa] A Podcast for Cocoa Developers
* [http://cocoa.0x00000000.net/ Cocoa Development Thoughts/Code]
 
{{Mac OS X}}
 
{{macOS}}
[[Category:Mac OS X APIs]]
{{Widget toolkits}}
 
[[daCategory:CocoaMacOS APIs]]
[[Category:Apple Inc. developed frameworks]]
[[de:Cocoa]]
[[es:Cocoa (informática)]]
[[fr:Cocoa (Apple)]]
[[it:Cocoa]]
[[nl:Cocoa]]
[[ja:Cocoa]]
[[pl:Cocoa]]
[[pt:Cocoa]]
[[ru:Cocoa]]
[[sv:Cocoa]]
[[zh:Cocoa]]