Last Updated:

Objective - C

All programming for iPhone and Cocoa macOS X is conducted using the Objective-C language.

Objective-C was created in the long 80s by Brad Cox and Tom Love. Objective-C is an add-in to the C language and makes it possible to write ordinary C-code. Objective-C brings object-oriented capabilities that it borrows from Smalltalk. Initially, objective-C concepts and terminology cause some confusion. But then it's a matter of habit and after a short work, the strange syntax no longer looks so unusual.


So, Objective-C is an object-oriented language, which means full support for objects, data members, methods, encapsulation, inheritance, and polymorphism, and everything involved. The header file (.h) and the implementation file (.m) together represent an object in Objective-C terms. At some point in time, you'll use the built-in objects that come with the iPhone OS framework, but much more often you'll have to develop new classes or inherit from existing ones to add new behavior. When you do this, you will need to add a new pair of files (.h) and (.m) that will represent your new class.

Let's look at the six main syntax elements of the Objective-C language:

  • Category — category is used to extend the class without using the inheritance mechanism;
  • Class - a class it is a class that defines the type of object;
  • Message – A message is a command that is sent to an object. In other words, a method call;
  • Properties — properties allow convenient use of Get/Set methods;
  • Protocols - The protocol defines the methods that are required to be implemented, similar to interface in C#;
  • @ is a directive used by the compiler.

Now, in order.

Message - Message

A message is sent when one object asks an arc to perform a specific action. In our usual language, to send a message is to make a call to a function/method. Calling a simple message looks like this:

More life examples:


Here, the message sends the makeKeyAndVisible command to the window object, which tells it to appear and start accepting input from the user.


If I were to do the same in C#, the above construct would be written to window.makeKeyAndVisible(); At first it was easier for me to perceive, later I got used to writing Objective-C.

There are three other ways to use the message:

  1. The message can accept arguments.
  2. Messages can be cascaded.
  3. a message can be forwarded to one of more than one recipient.

Argument message

To send a message with a single argument, simply separate the message name and argument with a colon. Example:

Real-life example:


In C#, I would write this: textView.setText(@"Hello world!");


If you want to send a message with multiple arguments, then every argument except the first argument is labeled. Example:

Real-life example:


In C#, I would write myButton.setTitle(@"OK", UIControlStateNormal);


What I wouldn't be able to repeat in C# is the use of labels. Labels make it possible to use an argument without thinking about its sequence in the list of arguments, it is enough to know the label of the argument.

Cascading Messages

I think everything is clear here. Messages we can cascade nesting one into the other, example:

In other words, this expression could be written:


Message recipients


You can send a message to a class:



The example sends a buttonWithType message to the UIButton class with a UIButtonTypeRoundedRect argument. I would write the same thing in C#: UIButton myButton = UIButton.buttonWithType(UIButtonTypeRoundedRect);


The buttonWithType method of the UIButton class is static.

The message can be sent to the object (instance) of the class, I already gave an example above

here, an initWithFrame message with a textFieldFrame argument is sent to an object (instance) of the UITextView class.


There are two more keywords using which we can send a message to the object of the class:

I think everything is clear here. In C#, I would write this: this.setText(@"Hello World!");


Send a message to the ancestor. In C#, I would write it like this: base.initWithFrame(frame);


Class Definition


Classes in Objective-C are defined in a pair of files (.h), (.m). The file (.h) defines the interface of the class, and the file (.m) defines the implementation of that class. The definition of a class intrarfesis begins with the @interface directive and ends with the @end directive. Just an example:

Here we defined the MyClass class, which inherits from the UIImageView class. The class has the variable strTitle and an instance method showTitle.

In C#, I would write the same thing like this:

There's an interesting subtle point here that you may have already noticed is the odd "-" sign before defining the method. This defines an instance method in Objective-C that can be used only after the object of the class has been created. The "+" sign means that we are defining a class method or a static method. To provide dynamic typing or type detection at run time, the id keyword is used, which is a pointer to "any object".



The implementation is carried out in the (.m) file and begins with the @implementation directive and ends with the @end directive. Example:

The example begins with the #import directive, which is analogous to the #include directive. Also #import has additional functionality that ensures that the header file is included only once. What is the analogue of such code in C/C++:

I don't know if any comments are needed here on the implementation. I think I understand.



The need for properties is to get rid of writing a huge number of getter/setter methods. Objective-C offers syntax to simplify access to instance variables. The @property directive is part of a @interface expression and is intended to provide access to an instance variable. Just for example:

The property definition starts with defining an instance variable, then using the @property directive we repeat that definition. And we end with a @synthesize directive in the @implementation class implementation file. That's pretty much it, we've defined a method to access an instance variable that can read and write to a variable. By default, the property is of type assign, but we can change this by specifying the appropriate attribute. An example of using the property:

Syntax "."


Objective-C suggests the syntax "." to make it easier to use object properties. Below is an example that I gave above, but using the syntax ".":

In my opinion, it's easier that way, at least for me as a person from the world of C++/C# - this entry is familiar and recognizable. Also, the syntax "." can be cascaded, i.e. the expression myClass.Array.Length is legitimate and applicable.


It's not all by properties. Properties can also include attributes that change the behavior of a property when assigned and the method of accessing the property. Properties can be dynamic, i.e. added at run time, using the @dynamic directive. And much more, but here and now I will not consider it.

Categories and Protocols

The last two elements of Objective-C that I'd like to touch on are category and protocol.



About the category in general terms.

The category came to Objective-C from the world of Smalltalk. A category is used if you want to add a behavior to a class without inheriting from it. That is, the category allows you to extend the class and add new methods to it and you do not need the source code of the class, and the added methods automatically become available to all classes inherited from the modified. A mechanism that allows you to extend existing classes (by adding new methods, you cannot add new instance variables in this way) is called categories. As usual, you start by creating a pair of files containing the @interface interface and the implementation of the @implementation.

A category has its own name, a list of methods, and the name of the class it extends. The description of the category is as follows:

The implementation of the category is as follows:


I won't go into the category any further.



The Objective-C language supports the full operation of protocols. In C++ it is a purely abstract class, in C# it is an interface. The protocol represents only a list of method descriptions. A class implements a protocol if it contains an implementation of all the methods described in the protocol.

Protocol Description:

A more vital example:


a protocol can inherit from an arbitrary number of other protocols


When describing a class, it is possible to specify not only the parent class, but also a set of protocols: