Introduction to the Frameworks

The Cocoa platform is now represented by four separate flavors, or sub-platforms, with the macOS, iOS/iPadOS, tvOS, visionOS, watchOS and SDKs. Each SDK is made up of individual libraries usually referred to as "Frameworks".

On the Objective-C side, each framework is a bundle with the .framework extension that contains both binary (.dylib, which is comparable to .dll on Windows) and Objective-C header files. For Elements, each framework in the SDK is represented by a .fx file that aggregates all the metadata from the headers to make them easier and faster for the Elements compiler to consume.

Elements comes with pre-created .fx files for all frameworks in the standard Apple SDKs that ship with the latest versions of the four SDKs (as well as for select older versions).

You can find a complete list of all frameworks in the lists below. You will see that many of the frameworks are shared by some or even all SDKs, providing a vast library of classes that let you write code that can be compiled for and shared between all sub-platforms, while each SDK also provides a significant number of frameworks that are platform-specific.

Let's have a look at some of these frameworks in more detail.

Foundation

Probably the most critical framework for any Cocoa app is the Foundation framework, because — as the name implies — it provides much of the foundation classes that make up an application on the Objective-C runtime. This includes most of the standard classes with NS* prefixes (aside from GUI classes, more on that below), from simple and essential types such as NSString, NSArray and the like, to classes that provide access to core OS services, such as NSFileManager for disk access, NSNotificationCenter for working with notifications, NSURL* classes to work with network requests, and many many more.

Read more at about Foundation.fx. It is available on all Cocoa sub-platforms.

User Interfaces: AppKit vs. UIKit vs. WatchKit.

The similarities between the iOS, watchOS, tvOS and macOS SDKs dissipate as we enter the realm of user interface development — and for good reason, as the UI for applications on these platforms is vastly different. For this reason, the SDKs provide three very distinct frameworks:

AppKit is included in the macOS SDK only, and provides all the classes and controls you need for creating Mac applications. For legacy reasons, most of these classes share a common naming prefix with Foundation and start with NS*, and classes you will be working with include NSWindow, NSButton, NSTableView and the like.

UIKit is the framework that both iOS and tvOS use to provide their UIs, and its classes start with a UI* prefix. Many concepts are shared by AppKit and UIKit, but the classes are different &mdash some more than others. For example, both frameworks have a class to represent color (NSColor and UIColor, respectively) that work very similarly, while other concepts are pretty unique to UIKit, such as its use of predefined controllers like UINavigationController and UITabBarController. UIKit also has differences (some minor, some very significant) between iOS and tvOS.

WatchKit, finally, is used by watchOS to build UI for the Apple Watch in terms of Apps, Glances and Notifications. (There is also ClockKit for building watch face Complications.) WatchKit uses a different and more simple approach for UI design than UIKit.

The different frameworks force the developer to rethink and design their application UI from the ground up, but that is a good thing, because the UI paradigms on each platform are fundamentally different, with UIKit being largely driven by touch (both direct and via the Siri Remote on Apple TV) and AppKit being used for more traditional mouse+keyboard style interaction.

But a lot of the concepts behind the frameworks are similar, and you will find that learning to create applications on one will in many cases translate easily to the other. For example, all three frameworks embrace the Model-View-Controller paradigm for separating the actual UI from the "controller" class that drives it. This becomes apparent the moment you start creating your first UI, because rather than implementing your own Window or View class (due to the single-window nature of iOS, UIKit applications think mostly in terms of views, not windows) in code as you would in .NET or Delphi, you implement a Window (or View) ''Controller''.

Other topics on this docs site, such as the Working with XIB Files article discuss these concepts in more detail.

Read more at about AppKit.fx, UIKit.fx and WatchKit.fx.

Note: A Cocoa.framework (and matching Cocoa.fx) exists in the macOS SDK. This framework is merely a bundle of Foundation and AppKit. It is not to be confused with our general use of the term "Cocoa" to refer to the entire platform.

More Specific UI Frameworks

Both SDKs contain additional frameworks that build on top of AppKit and UIKit to provide access to more advanced or specific UI elements.

For example:

  • The macOS, iOS and watchOS SDKs contain MapKit, which provides classes to integrate Apple Maps into your application, both to show maps, and to work with geographical data. (MapKit also works together tightly with CoreLocation, covered below.)
  • Both iOS and macOS contain the new Social framework that lets your application show UI for sharing content on Twitter, Facebook, Sina Weibo and other social networks.
  • iOS provides the MessageUI framework for interacting with email and letting the user send emails straight from your application.
  • SpriteKit, new in both iOS 7.0 and OS X 10.9 and SceneKit (new in OS X 10.9 and also in iOS as of version 8.0) makes it easier to create great game UI.

System Services

There are also a bunch of frameworks that let your application interact with system services, such as:

  • StoreKit to handle in-app purchases for iOS and Mac App Store apps.
  • Security to access the system key chain, store and retrieve passwords and certificates, etc.
  • CoreLocation to work with GPS (and Wifi-based location services).
  • CoreAudio and CoreVideo to work with and play audio and video media.
  • Addressbook and EventKit to work with users' Contacts and Calendars (alongside EventKitUI on iOS).
  • GameKit to integrate your games with Game Center.

(all shared between all platforms) and more.

Lower-level Frameworks

If you want to go beyond just AppKit/UIKit for your user interface development, both SDKs also provide frameworks that let you get your hands dirtier and work with the UI on lower levels.

  • CoreGraphics is the foundation of all graphics rendering in the core UI frameworks, and you can and will work with it when creating your own custom controls.
  • QuartzCore contains ''CoreAnimation'', the library that provides sophisticated yet easy access to adding animation to your applications — a must for any modern iOS and Mac app.
  • GLKit lets you add OpenGL based elements to your UIKit/AppKit applications, while the lower-level OpenGL (macOS) and OpenGLES (iOS and tvOS) frameworks give you full access to the raw OpenGL APIs.

rtl.fx, libToffee.fx, libSwift.fx

In addition to the core SDK frameworks, Elements provides three additional .fx files that are crucial to its operation.

  • rtl.fx is even more fundamental than the Foundation framework, and contains all the low-level C-style APIs that make up the core UNIX system of macOS, iOS, watchOS and tvOS; it also contains libraries such as Grand Central Dispatch and CommonCrypto. Essentially, rtl.fx represents most of the headers in /usr/include.
  • libToffee.fx contains helper types that are crucial to the Elements compiler itself. For example, it contains internal support for Future Types, generic NSArray<T> and NSDictionary<T> types, LINQ support, and more.
  • libSwift.fx provides additional types and functions specific to the Swift language.

Any Cocoa application will automatically reference rtl.fx, whether it is explicitly listed in the References or not. References to libToffee.fx and libSwift.fx are optional; the compiler will warn/error if features are used that require a reference to libToffee.fx or libSwift.fx and they are not referenced.

(All projects created from templates will automatically reference libToffee.fx by default; all Swift templates also reference libSwift.fx.)