More than 3 years passed since the first public announcement of Swift. So, it is a good idea to take a look at Objective-C in order to find out its place in the world of software development.
As of now, Apple changed ObjC for better Swift compatibility quite a bit, making it more type-oriented, which is definitely a bad idea for a dynamic language with duck typing, as it bloats the code for no apparent reason. Nonetheless, we are free to avoid using those features, although Xcode tries to suggest them with its auto-completion.
Other than that, modern ObjC is still a good old ObjC 2.0. Besides its flaws, it complies fast and still has great code generation based on C macros, which helps avoid code bloating. Writing unsafe convention-based code is lightning fast. One could argue that such code is more error prone than the strongly typed code, which does a lot of work during the compile time. But you would still need unit or behavioral tests to ensure the proper behavior, same for both strongly typed languages, such as Swift or Java, or duck-typed dynamic ObjC.
The most important thing in ObjC standing up to this day is the runtime. Although you should be extra careful when using it, dynamic subclassing, method swizzling, category method overloading, mixins, etc. are the perfect way to do anything you want fast and with minimal code.
For example, making all individual methods of any object thread safe on the basic level would just take several lines of code, which is a definite win over by any statically typed language without direct access and modification of AST. In ObjC we would just intercept messages sent to object using proxy and wrap them in some kind of lock, while in static strongly typed competitors we would have to subclass and overload each individual method by explicitly wrapping call to super into a lock.
The ease of development in ObjC is partially based on the fact that Xcode works well with it. Debug is a breeze with failures being pointed exactly at the line of failure (Xcode doesn’t show where the failure occurred for Swift from time to time), stack traces being much more informative, and debug info being much easily accessible. Autocompletion works like a charm for ObjC, compile time is much faster and Xcode doesn’t crash as often for ObjC, as it does when writing in Swift.
Let’s also note that Apple releases new frameworks and they are still written in Objective-C, e.g. Audio Unit v3. This happens due to both Objective-C interoperability with C ++ (Objective-C ++) and that working with direct memory access is really fast in execution while being unsafe in C fashion. Another reason, that I can only suppose is valid, is about Objective-C ABI and APIs backward compatibility, as I doubt Apple would wish to rewrite their frameworks with each Swift version having to support the same framework branches for all Swift versions.
On the other hand, we see that open source ObjC support diminishes, with most of the frameworks being rewritten or written entirely in Swift, while using ObjC only for C ++ interoperability. No wonder people try to stay modern and get the competencies necessary to secure better positions and improve their Swift knowledge.
From the resources point of view, ObjC is still a winner. During the time it existed, it accumulated an enormous developer base, who are highly proficient and professional.
The real deal here is games. They are still written in Objective-C ++ and it seems it will stay like that forever. While consumer apps tend to start in Swift, a lot of companies have a large ObjC code base they are unwilling to rewrite or just don’t want to take risks with Swift adoption.
So, what is the place of ObjC? Stable code for apps that would be easily supportable for several years (or, ideally, wouldn’t need any support at all), games, DSP algorithms, efficient and fast computations, rendering. It will stick with us for at least several more years, as even Apple doesn’t transition its framework codebase to Swift as of now. If Apple starts releasing Swift only frameworks, this would definitely mean that you should start the transition to Swift, but that’s not the case as of now.
(1 votes, average: 5.00 out of 5)
Loading...