Final guide: Should choose Objective-C or Swift?

There are many factors to consider when starting a new project so choosing Objecitve-C or Swift is not a clear decision. Since this is one of the most popular questions in iOS programming, we have decided to offer a variety of aspects to discuss this topic for the last time.

Remember, there are no arguments that play a major role in your decision. Your decision only comes immediately after weighing the following factors:

Experience with Objective-C vs Swift

The first point is your current experience. If you have experience equivalent to both languages, language selection will depend on other factors listed below such as: 3rd party library compatibility, API support, components team member …

Conversely, if only one of the languages ​​and project or team requirements are not objectionable, choose the language you are familiar with if. Of course, if you choose an unfamiliar language to be an app then you will have the opportunity to learn about that language, but the high possibility is that you will bear technical debt – a technical debt (in programming, sometimes We choose to solve "instant noodles", solve the problem immediately, but will make it difficult for the development and maintenance process later. Accumulated Techinical will cause many incalculable dangerous consequences) or delay project schedule.

Sometimes you have a situation like building a house on a sand that cannot be rescued. In other words, this initial "technical debt" will leave you with no choice but to rewrite the application from scratch.

On the other hand, if you decide to create a prototype – test for your production app , you can program with the language that you are least familiar with. This way helps you familiarize yourself with the new language, support the production app because you will approach the application, access features and solve its problems from 2 insight angles.

Time frame, scope and scale of the project

First see the special requirements and constraints in the project. Your experience, team members, project size will help you lean on 1 in 2 languages.

► Time frame

Production apps in a language you are not familiar with will lead to large technical debts. This debt must be paid in due time. If the timeline is urgent, you will have to choose the language you have more experience. In case you haven't had much experience, choose Swift.

If you have a gentle schedule, you can consider programming languages ​​that you don't know at all (to learn more). And if you accidentally fall into a "mysterious" project that doesn't have a fixed timeline, you should definitely choose the language you don't know at all. This is a golden opportunity, not often available in your career to optimize the ability to expand the language and upgrade the game.

► App team

Compared to technical issues, this is a topic that is often ignored but should not be. You need to talk to your team before making language choice decisions – even if you are working in an independent codebase area.

For example, if you were working in a company with the Objective-C dev team with many years of experience? If you start with Swift and the whole team is still not fully acquainted with it, it is not a good idea. Even if you have enough reason, the ability to argue and predict everything, you should not go alone with your own language. Team conflict can lead to bad consequences two and eventually, no one wins. As long as you listen to the members and follow a democratic plan, all will be fine.

► Scope of the project

Small projects have the right to choose the appropriate language because the costs incurred when converting Swift code if there are changes are negligible. On the other hand, big projects need to be careful when receiving this language. Swift is still incomplete and each version (even small versions) can pull a series of conversions related to syntax and new expressions. Nobody wants their code broken in just a few days every time the new version of Swift comes out. Or worse, become a programmer all day explaining to management or stakeholders why the code is broken.

Xcode provides Swift x code conversion tools to Swift x + 1. However, the tools do not capture everything. This is not a bad thing for the Xcode team because, simply, some language-related changes are almost impossible to automatically convert without understanding the context behind those lines of code.

Technical concerns

Objective-C and Swift languages ​​themselves have a lot of different technical advantages.

► Tooling support

Team Xcode has successfully updated the programming process to support Swift. They have perfected a complex language and supported it to work in a completely different language (Objective-C). Even IDE is slow and the tooling support for Swift is negligible. Sometimes, you're lucky to have syntax highlighting. Sometimes, you still code ahead without autocomplete. And refactoring tools are not working. If you want to be strongly supported by modern IDEs, you should work with Objective-C or consider other IDEs.

► Runtime

Objective-C's runtime is more powerful than Swift. In the coming years, Swift's runtime probably won't keep up with Objective-C. If you are planning to write code to take advantage of reflection and introspection of objects and types (often appearing in powerful SDKs, but sometimes also in normal applications), then Objective- C is very useless. If you don't understand what the last sentence is about, then you should start with Swift.

► Stability of the code

Swift is a safe programming language, thanks to its powerful typing and troubleshooting system. If you are studying idiomatic and want to avoid the operators! In code, certainly not less, many of your code will also encounter potential error cases. Memory leak from 1 retain cycle is an example commonly found in Swift and Objective-C code. The reason is because the automatic reference counting system does not change.

► Working with Foundation APIs

If your application primarily uses foundation APIs (such as CoreFoundation, AVFoundation and CoreAnimation), you should favor Objective-C. Swift has sustainable wrappers and helps manage memory more smoothly, as these are still function calls based on C APIs and C, so it will automatically be compatible with Objective-C codebase.

► Use C ++ code

Similar to Foundation APIs, using C ++ or C ++ SDK cross-platform libraries will adapt to the Objective-C project. You cannot import C ++ into Swift files. To use Swift , you have to go through a tedious, tedious task, often encountering a bug that creates Objective-C or Objective-C ++ wrapper classes. You must catch the bridge, adding each time you want to use another part of a C ++ library. If you intend to take advantage of C ++, Objective-C will be more suitable.

► Operation system version

Swift runs on iOS 7+, Mac OS 10.9+ and all versions of tvOS and watchOS. If the project needs to support lower operating systems, you have no choice but to use Objective-C.

► Evidence for the future (Future-proofing)

Most future bailout projects are written in Swift. In the past 2 years, the use of Swift has expanded to 1/3 of open source Cocoa projects. At this rate, in the next 4 years, the number of open source Cocoa projects using Swift will be equal to Objective-C. In addition, most new tutorials and blogs have been written in Swift . We believe that 5-10 years will have enough Swift information so that the developers do not need to know about Objective-C anymore. So, you have enough time to convert the code before Objective-C's role fades away.

Addition: Should you transfer your current Objective-C project to Swift?

Before answering this question, you need to understand why both Swift and Objective-C should be used in the project. This concept is called "bridging". When you add a Swift file to the Objective-C project, Xcode will create a "bridging header file", which is no different from regular Objective-C headers, unless you only use it to enter the ObjectiveC headers you want to render. in your Swift code. Xcode will automatically create headers that connect all Swift code with Objective-C. You can use this function by adding a line of ModuleName-Swift.h (eg, Mail-Swift.h if you're working on a project called Mail) where you want to use Swift code in Objective files -C.

The next thing to consider is the project scale. A big project will not be suitable for bridging, because Objective-C code is often leaked abstract (leaky abstractions), so the Swift code has less specific characteristics. For example, if you have a protocol that extends NSObjectProtocol to use the Objective-C runtime in protocol enforcement objects, the Swift protocol implementation class will have to inherit NSObject or another class in the NSObject hierarchy. Supporting this Objective-C runtime like this will slow down the performance of calls methods 4 times (because it uses dynamic dispatch instead of static). A small-scale project can coordinate Objective-C code smoother than a large project. However, experience shows that eventually you will want to convert the existing code to Swift and a small project will eventually become a to-do-list of Objective-C code that you want to switch to. Swift.

Other issues include team membership and project urgency. If you're working with a team, then you need to get consensus before complicating everything by bridging an Objective-C project to Swift. If you are starting to write Swift without a buy-in team (understood as a form of review and approval of the team), you will be labeled as a cowboy coder and must quickly get a new job. In addition, bridging code is also more painful than you think. If a project is urgent or has a fixed deadline, select Objective-C. Instead, start coding with Swift.

Conclusion

These are common factors that dev should consider before choosing Objective-C or Swift for their new project and current project. Of course, your project may have problems unlike many other projects. But the two points that you need to pay attention to are: the status of the project and the decisions of the team members.

Source: IDE Academy via SavvyApps