Now we’re rolling: we can visually create automatically-resizing GUIs in nib files, connect them to methods and properties in the view controller class that owns the view, and write code in Objective-C to do stuff. Life is good.

 Except that we’re still taking a lot on faith when it comes to calling stuff in our code. We can search the documentation for cool-looking methods all day, but maybe we should make sure we understand where all these classes are coming from and how they’re organized first. learn ios course

The iOS SDK divides its functionality into a set of frameworks. We saw this in the last chapter when we inspected the project’s build phases and added Social.framework to the frameworks that were already part of the project. 

Conceptually, we can divide the SDK’s frameworks into four layers: Cocoa Touch Layer The top-level abstractions over applications and their UIs (UIKit) and integration with system-provided features like mapping (MapKit) and Game Center (GameKit).

Media Layer Graphics, sound, and video frameworks. Core Services Frameworks for essential, non-UI functionality, like file-system access, in-app purchase (StoreKit), motion- and orientation-sensing (CoreMotion), and so on. 

Core OS Low-level frameworks and libraries needed by the upper layers, including the BSD libraries that are the core of iOS and Mac OS X. In this book, we will spend most of our time working with the frameworks that are included by default in the Xcode project templates: Foundation and UIKit.

get more knowledge about iOS from iOS app development course