In modern days the objective с vs swift rivalry is growing quite savage. It is very understandable, since they both have their benefits and some developers grow confusion on how to choose a programming language for a project.
First of all, there is no strict answer. There are factors and features, flaws and strong points, say, lots of things to be considered before the choice is made. So, instead of pointing fingers, we’ve decided to make an overview, to show the difference between objective с and swift, pros and cons of both sides, because we think it is wise to choose what is best for each developer team and each specific project.
Read also: why you need to outsource mobile app development
Swift or Objective-C: management considerations.
Team, Threshold, Expertise
The very first consideration is the given team. Even though Swift is often called a simpler, smoother syntax language that takes away some of troubles of more complex Objective-C, there still is some enter threshold. The right question here is not “if the team is capable of building the new project using Swift/Objective-C?”, but “is the team qualified enough right now, and would it execute the deadline?”.
Get together and consult with your team, they must be sure they not only “could do that in Swift”, but also want to and be sure they’d be in time. In case the team is an Objective-C expert, it’s not a good idea to force them to work using Swift on a project with strict deadline. Same is true vice versa. Strict deadline defines the most comfortable language for the team to be used (if not overridden by circumstances).
Project size
The next consideration might be the size of the forthcoming project. Where small projects can benefit from Swift’s features concerning simpler syntax, file structure, etc., while big projects, on the contrary, may be affected by Swift’s young nature. Sure there are means of Xcode conversion to newer versions, but they are not perfect, and things get worse with project growth. Being young also brings some faults, bugs and instabilities to Swift’s native IDE - Xcode, there’ve been many reports of crashes, Xcode language incompatibilities and so on, though Xcode makes progress quite fast, many bugs are already resolved. Some new came.
Read also: How to manage your remote development team
Swift or Objective-C: technical reasons.
There is more than one difference between these two languages, but they share at least one important trait - they both are Apple’s main programming languages for app development for the full range of Apple’s platforms. Objective-C is much, much older, been developed in the early eighties it belongs to Generation X. Original Cocoa was written in it, though Swift written parts are added ever since it was introduced in 2014 to both Cocoa and Cocoa Touch.
Objective-C is a strict superset of C, deriving its object-oriented syntax from Xerox Smalltalk. Its nature is highly dynamic, with dynamic binding and dynamic typing, whereas Swift has static type checking.
Now let us look at the advantages of both languages and name some reasons for each of them. The pros of one can effectively be considered as cons of the other.
Read also: How to integrate Siri in your iOS app
Why choose Swift
Ease of use
Swift was designed to be easier to live with, easier to read than Objective-C. Its syntax is closer to natural English, dropping down some legacy conventions - no more bracket chains, no more “@” before any object-related keyword or Objective-C specific type. Cleaner looks, easier comma separated calls; Swift is sometimes called “The Objective-C without The C”. Swift is not based on C, not only simplifying grammar, but also lowering the threshold for Java, Python, C++, etc. programmers for mastering Swift.
Swift is also less verbose, especially in string handling and even supports adding strings with a simple “+”. Who knows, the next language might be called Hemingway.
Memory management is now unified throughout the code, with Automatic Reference Counting (ARC) now working in both object-oriented and procedural parts of code, unlike only object-oriented in the predecessor. Objective-C allowed big memory leaks in its time, Swift makes it impossible and frees programmers time for the development itself.
In addition, Swift doesn’t use two-file system, no more .h header files + .m implementation files, just one .swift code file (with thanks to LLVM compiler and Xcode IDE dependencies handling).
Safety
Swift was designed to be a safe language. There is no failsafe language in this world, but error handling is very nicely thought through and typing system is very strong.
Unlike Objective-C that didn’t throw exceptions on nil pointer calls, say, it was okay if you tried to call a method with an uninitialized pointer variable, it just made this expression a no-op, in Swift the optional types and value types make it clearly possible to generate a compiler error on a nil pointer calls. This means that no-op related unpredictable erratic behaviour is gone, it seriously shortens bug fixing expenses, due to a shorter feedback loop and fixture on the development stage.
Dynamic libraries
In iOS 8 a long awaited new tech was brought to the mobile platform - support of dynamic libraries. Since then, Swift applications are able to link with Swift’s newer versions, allowing Swift to be faster in evolution than the iOS, a must for a modern language. The dynamic libraries are also external for the apps executables allowing smaller initial downloads and differentiation of loads of mobile and embedded apps.
Future
Swift might be around for only two years, but its popularity has skyrocketed to around 30 percent of all open source Cocoa projects since 2014. With Apple clearly aiming Swift to replace Objective-C as their main language future proofing means shifting towards Swift. It isn’t a question of tomorrow by any means, this transition will take some time, but it is expected around 5-10 years, so there is time for the developers to adapt.
Efficiency of the rather favored Apple Bug Reporter utility shows how much effort Apple places into Swift promotion. Apple also is set to accommodate community’s ideas, assimilate its knowledge and experience and implement their solutions in future releases. The way to perfection.
So is it the case as in a joke we heard a couple of days ago in a meeting with fellow mobile app developers:
“Through Objective-C away,
Swift has come to save the day.”
Hardly so, because Objective-C still has its own aces, and the transition period has just begun.
Why Objective-C
Compatibility and support
Despite all the effort of the Xcode team the IDE is not that great in tooling support for the Swift, it is too new, probably. Autocomplete is laggy, syntax highlighting is almost non-functional, the refactoring tools refuse to work. Programming with Objective-C was here for a while already (>30 years!), it is polished as it gets and has brilliant tooling support.
Since Swift is the “without The C” language, C++ libraries are unusable here. Same with C++ multiplatform SDKs and Foundation APIs (e.g. CoreFoundation).
There are tools like bridging and wrapper classes, but the effort is usually not worth it, sticking to Objective-C is preferable in case of C++ and Foundation APIs use.
Swift is not only young, but also is not compatible with older operating systems, its support starts in iOS 7.0+ and Mac OS 10.9+ (tvOS and watchOS support Swift in any version), so Objective-C is the tool of choice for older platforms.
Expertise
Not only some home teams are more experienced in Objective-C, but it is easier to find third party specialists in it, in case you are interested in outsourcing some parts of your project. Bridging (the mechanism of using both languages in one project) is still here, but it can become a pain in bigger projects.
Dynamic
While Swift can benefit in optimization from its static type checking, methods adding on-the-fly is no longer available, and all types are defined before the run time. If you absolutely need dynamic typing, then Swift is a no go.
Runtime
Objective-C is a far more established platform, thus it has a much more stable, tough and reliable runtime. We don’t want to say Swift is not capable of achieving that scale, but it would take time, and lots of it.
Conclusion
As we can see, both languages have their advantages and tradeoffs, each occupies its niche, yet they do have a possibility to work together (in smaller projects preferably, but nevertheless). Robustness vs optimization, versatility vs ease of use, it is much like old vs new, or rather established and experienced vs modern and progressive. Just like Dumbledore, Objective C is wise, experienced and strong while Swift is Harry Potter in this comparison, being young, progressive, having all the potential to tackle the most difficult problems. For now, their union can be the most powerful solution.
Anyway, each team and each project require individual approach, we hope with the use of our hints and consultations with your team you will have an easier time choosing.
