Mobile developers at CROC solve real problems of customers and end users: they create applications for remote visual acuity testing, integration with smart glasses for the Dubai police or access to a corporate social network. In this article, the mobile development team explained why Objective-C is still alive and why it should be taught in 2022.
Deep understanding of processes
Most of the internal code of macOS, XCode and the iOS kernel is written in C and C++. Objective-C “fits in” with them very well, because formally it is not a programming language, but a large preprocessor to pure C.
The entire Apple ecosystem is built on top of Objective-C. The same Swift is largely written on top of it, and in order to understand how the system works from the inside and why Swift looks the way it looks and works the way it works, it is useful to know the “base”.
For example, Objective-C helps to understand that not all NSProxy is NSObject and what is the difference between Int, NSInteger and NSNumbe. And also due to what Swizzling works, what a Selector is, how the responder chain works, and so on. In Swift, this is highly encapsulated and abstracted, and therefore not very clearly visible.
In addition, Objective-C, like any C language, helps to understand how links, pointers and memory work in principle. You have to work with links directly in it, so it’s enough to write 1-2 small projects to understand the topic.
Advantages of the interview
At most interviews, you will be asked tricky questions about operations that are visible when developing in Objective-C, but are rarely found in Swift.
For example, atomicity and copy attributes. For a long time, memory control in Objective-C was manual, and atomicity — that is, the availability of variables simultaneously from different threads — is a rather painful topic. Therefore, after working N times on Objective-C, you begin to understand this well: you can explain what problems arise when working with threads, when you need to provide atomicity or think about how the value will be copied, whether an additional processor is needed.
Objective-C is still used in development
Firstly, it seems that any project that has existed for more than 2-3 years has a part of the code base written in Objective-C. It can be at least a hidden layer that is made dependent and does not really fit into the common code base — but it is there and you need to work with it periodically: fix bugs or add features.
Secondly, while some applications cannot be rewritten to Swift— it requires time and money that the company or the customer is not ready to spend. Therefore, the Objective-C database is growing.
Thirdly, if complex work with the network, memory, and device resources is necessary, then you have to use languages with a lower level of abstraction than Swift. It can be Objective-C, Objective-C++, or just C and C++ – depending on how low a level we need.
This is quite rare, for example, when working with messengers (Telegram), streaming (Zoom) or video services (Kinopoisk). In such cases, you can also abstract and either make part of the logic into a separate dependency, or transfer the rendering or the entire logic of data bundling to the backend. But not always.
Some things are harder to do on Swift than on Objective-C
Sometimes solving problems on Swift is long and inconvenient — it’s easier to use crutches that have been in Objective-C. for a long time.
Basically, we are talking about memory management: to pull a message into unauthorized memory, manually manipulate memory management or threads. Let’s analyze a couple of cases.
Objective-C has purely “sish” things: memory allocation, managing pointers and links directly, and so on. Therefore, where you need to work very carefully with memory (for example, when working with video and audio streams), using Objective-C, you can subtly optimize the application, improve performance and memory estimates. In Swift, you will have to rely on ARC (although there are also life hacks here).
In addition, ARC does not solve many problems — for example, with the lifetime of objects. Let’s say we have a voice message for 14 minutes. The user has already listened to 12 – and they “ate” all the RAM. In Objective-C, we can easily clean them — at the level of pointers and bytes – leaving only the current minute and the last two. And on Swift, this will require a high level of abstraction and a lot of code (or using Objective-C tricks via the Swift interface).
Finally, often loaded, complex and highly optimized libraries that implement video or photo recognition, computer vision or cryptographic calculations are written in C++. And integrating with them via Swift is painful, long and expensive. As a rule, it is easier to create a header file in Objective-C, write a couple of methods for a beautiful wrapper and refer to them already. Such cases are very common when integrating with third libraries.
What is the result?
Yes, Objective-C is not perfect, but it is useful to learn it.
It is still a popular programming language. It helps to better understand how Swift and the Apple ecosystem as a whole works, and allows you to work with low-level tasks in a granular manner. In addition, Objective-C still has most of the codebase written that needs to be maintained. And finally, knowledge of the language is a bonus in interviews.