Objective-C Is a Total Abomination (opinion)

Objective-C is mainly used for developing software on Apple’s platforms, like macOS and iOS. Its syntax is notoriously difficult, combining elements of C with Smalltalk-style messaging. On paper, that sounds innovative. In reality, it’s a mess.

Concatenate two strings in Objective-C

1
NSString *string1 = @"Hello";
2
NSString *string2 = @"World";
3
NSString *combinedString = [NSString stringWithFormat:@"%@ %@", string1, string2];

This is unnecessarily verbose. Compare it to Swift.

1
let string1 = "Hello"
2
let string2 = "World"
3
let combinedString = "\(string1) \(string2)"

Swift is concise and clear. Objective-C, on the other hand, feels like you’re fighting with the language to do something simple.

Method Calls

Method calls in Objective-C are like reading a ransom note.

1
[myObject doSomethingWithParam1:param1 param2:param2 param3:param3];

Look at all those brackets and colons. It’s hard to read, and it’s easy to make mistakes. In contrast, Swift is straightforward.

1
myObject.doSomething(param1: param1, param2: param2, param3: param3)

Notice how much cleaner that looks. Swift’s syntax is modern, clear, and more like what you’d find in other languages. Objective-C feels like it was designed by someone who wanted to be different just for the sake of being different.

Memory Management: A Relic of the Past

Objective-C’s memory management used to be manual. You had to manage memory with retain, release, and autorelease.

1
MyClass *object = [[MyClass alloc] init];
2
[object retain];
3
// Do something with the object
4
[object release];

It’s clunky and prone to errors. Forgetting to release an object results in memory leaks. Retaining it too much causes crashes. This is a relic of a time before modern memory management.

Thankfully, Automatic Reference Counting (ARC) was introduced. But even with ARC, the language still shows its age. Compare this to Swift, where ARC is integrated seamlessly.

1
let object = MyClass()
2
// Use the object without worrying about memory management

Inconsistent Naming Conventions

Objective-C’s naming conventions are all over the place. Method names are long, descriptive, and sometimes too verbose.

1
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions;

There’s nothing wrong with being descriptive, but Objective-C takes it too far.

The result is code that’s difficult to read and maintain. Swift, by contrast, uses shorter, more consistent naming:

1
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool

Swift’s method names are clear but concise, making the code easier to read.

Lack of Modern Features

Objective-C lacks many of the modern features found in newer languages. For instance, it doesn’t have proper support for:

• Generics: Handling collections of a specific type is awkward.
• Optionals: Dealing with null values is painful.
• Type Inference: You have to declare types everywhere.

Here’s how you’d declare a generic array in Objective-C:

1
NSArray<NSString *> *array = @[@"Hello", @"World"];

And here’s how you’d do it in Swift.

1
let array: [String] = ["Hello", "World"]

In Swift, the syntax is cleaner, and you can often omit the type declaration because Swift infers it for you.

Working with Collections: A Tedious Affair

Working with collections in Objective-C is tedious. Let’s say you want to iterate over an array of strings.

1
NSArray *array = @[@"Hello", @"World"];
2
for (NSString *str in array) {
3
    NSLog(@"%@", str);
4
}

It’s not terrible, but it’s not great either. Now, look at the Swift version.

1
let array = ["Hello", "World"]
2
for str in array {
3
    print(str)
4
}

Swift’s version is not only cleaner, but it also benefits from type inference, making the code less verbose. You don’t have to declare the type of str explicitly; Swift figures it out for you.

Working with Blocks: A Confusing Endeavor

Blocks (closures) in Objective-C are another area where the language shows its age. Here’s an example of a block that adds two numbers.

1
int (^add)(int, int) = ^(int a, int b) {
2
    return a + b;
3
};
4
NSLog(@"Sum: %d", add(3, 4));

Compare that to the equivalent Swift closure:

1
let add = { (a: Int, b: Int) -> Int in
2
    return a + b
3
}
4
print("Sum: \(add(3, 4))")

Swift’s closure syntax is more intuitive and less cluttered. The Objective-C version is hard to read, and the syntax feels bolted on rather than integral to the language.

The Ugly Legacy: Header and Implementation Files

Objective-C splits code across header (.h) and implementation (.m) files. This is a relic from C, and it’s an outdated practice that clutters the codebase.

Header File (MyClass.h):

1
#import <Foundation/Foundation.h>
2

3
@interface MyClass : NSObject
4

5
@property (nonatomic, strong) NSString *name;
6

7
- (void)printName;
8

9
@end

Implementation File (MyClass.m):

1
#import "MyClass.h"
2

3
@implementation MyClass
4

5
- (void)printName {
6
    NSLog(@"%@", self.name);
7
}
8

9
@end

In Swift, this would be combined into a single file:

1
class MyClass {
2
    var name: String
3

4
    init(name: String) {
5
        self.name = name
6
    }
7

8
    func printName() {
9
        print(name)
10
    }
11
}

Swift reduces boilerplate and keeps everything in one place, making your code easier to navigate and maintain.

Here’s a classic Objective-C class that illustrates the verbosity and complexity of Objective-C syntax, especially when compared to modern languages like Swift.

Person.h (Header File)

1
#import <Foundation/Foundation.h>
2

3
@interface Person : NSObject
4

5
@property (nonatomic, strong) NSString *firstName;
6
@property (nonatomic, strong) NSString *lastName;
7
@property (nonatomic, assign) NSInteger age;
8

9
- (instancetype)initWithFirstName:(NSString *)firstName lastName:(NSString *)lastName age:(NSInteger)age;
10
- (void)displayPersonDetails;
11

12
@end

Person.m (Implementation File)

1
#import "Person.h"
2

3
@implementation Person
4

5
- (instancetype)initWithFirstName:(NSString *)firstName lastName:(NSString *)lastName age:(NSInteger)age {
6
    self = [super init];
7
    if (self) {
8
        _firstName = firstName;
9
        _lastName = lastName;
10
        _age = age;
11
    }
12
    return self;
13
}
14

15
- (void)displayPersonDetails {
16
    NSLog(@"Person Details: %@ %@, Age: %ld", self.firstName, self.lastName, (long)self.age);
17
}
18

19
@end

Contrast with Swift

In Swift, the same functionality can be achieved with much less code, in a single file, and with a clearer, more modern syntax.

1
class Person {
2
    var firstName: String
3
    var lastName: String
4
    var age: Int
5

6
    init(firstName: String, lastName: String, age: Int) {
7
        self.firstName = firstName
8
        self.lastName = lastName
9
        self.age = age
10
    }
11

12
    func displayPersonDetails() {
13
        print("Person Details: \(firstName) \(lastName), Age: \(age)")
14
    }
15
}

Why We Should Move On

Objective-C was revolutionary in its time. It brought object-oriented programming to Apple’s platforms and powered apps for decades. But today, it’s an abomination. It’s ugly, clunky, and difficult to work with.

Swift is the future. It’s modern, clean, and designed with today’s developer in mind. It’s time to leave Objective-C in the past where it belongs.

If you’re still using Objective-C, consider switching to Swift. Your eyes and your sanity will thank you.