In regards to iPhone development, how do you now when your using a Cocoa vs pure Objective-C objects. For example, the following are Objective-C:
But these are Cocoa:
And to be clear, does
Cocoa Touch == iPhone development
Cocoa == Mac OS X development
You've got it a little wrong.
NSTimer, NSString, NSMutableArray are all Cocoa. int and float are actually C, but since Objective-C is a strict superset of C, you are able to use them in your Objective-C code.
Pure Objective-C requires linking only to the Objective-C runtime library and no other frameworks or libraries. Cocoa is a framework that includes things like NSObject and NSString. Other frameworks, like AppKit, extend the Cocoa framework.
Coding in pure Objective-C usually means deriving from the root object called Object and not NSObject. Things like @implementation, @interface, @selector etc. are the Objective-C extensions to C and these are what are common in all Objective-C source, pure or not. If you want to code in pure Objective-C you cannot use anything other than your own objects derived from Object.
#import <objc/Object.h>
As already pointed out, The NS* classes are actually Cocoa, not Objective-C. Objective-C is a language, while Cocoa is a framework (an implementation of OpenStep). This framework can be considered to be the "stdlib" equivalent of C++. The UI* classes are Cocoa Touch, another framework created for the iPhone.
As to the last question, yes, Cocoa Touch is for the iPhone only. Cocoa is for Mac OS X development. However, as stated above, Cocoa is an OpenStep implementation. Alternatives to Cocoa exist, such as GNUstep and Cocotron. These alternative frameworks allow to use the same code on multiple platforms. The OpenStep frameworks are therefor not only for Mac OS X development, but can also be for Linux and Windows.
Another thing to note is that other Objective-C runtimes are different. There is no single Objective-C specification. The Portable Object Compiler is yet another way of doing this. Since Apple is the dominant user of Objective-C, and it controls Cocoa, it's considered the de facto Objective-C implementation.
In regards to iPhone development, how do you now when your using a Cocoa vs pure Objective-C objects.
If you're not using anything but Objective-C in your app, then all Cocoa objects are Objective-C objects.
If you're using Python or Ruby, then your objects will be Python or Ruby objects. But as long as they inherit from Cocoa classes, they'll be accessible to other Cocoa objects whether or not they're written in Objective-C.
(There is Core Foundation, which provides objects that work fine in Cocoa but are not written in Objective-C. This is an implementation detail; don't worry about it.)
For example, the following are Objective-C:
- NSTimer
- NSString
- int, float
- NSMutableArray
Only NSTimer, NSString, and NSMutableArray are Objective-C classes. int and float are primitive types, not classes. And none of them come from Objective-C: int and float come from C, and the NS* classes all come from Cocoa.
As sebnow wrote while I was writing this, Cocoa is a framework, whereas Objective-C is a language. The NS* classes all come from the Cocoa framework, not the Objective-C language.
But these are Cocoa:
- UILabel
- UIColor(?)
- UIView
No, those are Cocoa Touch. They are not available in a Cocoa app. Likewise, Application Kit classes are not available in Cocoa Touch.
(Cocoa is Foundation + AppKit; Cocoa Touch is Foundation + UIKit.)
And to be clear, does
Cocoa Touch == iPhone development
Cocoa == Mac OS X development
Yes. Cocoa Touch is the iPhone framework; Cocoa is the Mac framework.
It's true that Cocoa Touch is for iPhone development and "plain" Cocoa for Mac OS X development, but they're not very different and share most of basic classes.
In iPhone development you don't need to care whether you're using pure Objective-C or Cocoa. Cocoa is 1st class citizen on iPhone and you don't gain anything by avoiding it.
There is a slight difference between Objective-C and plain old C subset. Object allocation and method calls have higher overhead than stack-allocated structures and direct function calls, but 99% of the time you don't need to care about this either (don't try to optimize prematurely!).