Does it matter to the customer what programming language a mobile application is written in? They weren’t planning to read the code. Even so, It’s worth understanding a little about Apple’s move to the Swift programming language. It’s replacing the Objective-C language, which used to be the main language for writing iOS and OS X applications. This change is good news not only to the people who write the code but to the people who want new applications developed.
Let’s look at some of the reasons iOS app developers are adopting Swift for iOS app development, without diving too deep into the mysteries of programming.
Before 2014, Objective-C was Apple’s recommended language for iOS applications. It’s based on C, which is one of the most popular programming languages ever, but dates back to the 1970s and lacks many features that modern programming needs. Objective-C, developed in the eighties, adds some of these features but maintains strict backward compatibility with C. Any valid C code is valid Objective-C. C lets programmers do things which really aren’t a good idea, either by accident or as a convenient-looking shortcut. So does Objective-C. The language is showing its age, almost as much as C.
Memory management is a big issue in iOS app development. Code constantly grabs chunks of memory, does something with them, then gives them back to the pool of available memory. If it sometimes forgets to give them back, the application will eventually run out of memory. If it gives back a chunk of memory and then keeps using it, it will misbehave or crash. Objective-C has a difficult, error-prone memory management scheme. Swift’s memory management is more consistent, which makes it easier to write code with fewer bugs.
Objective-C requires header files along with executable code files. Very roughly speaking, this means programmers have to describe their variables in one file and put the code that operates on them in another. This extra bookkeeping slows down development work and complicates revisions.
Eliminating the need for headers is just one of the ways that Swift is easier for programmers to read than Objective-C. It eliminates some odd syntax and provides more flexible ways to write code. Readable code is easier to fix, update, and reuse.
Apple’s iOS runtime environment allows mixing Swift and Objective-C in the same application. This lets developers reuse well-tested Objective-C code from previous work as part of a new application in Objective-C. It isn’t necessary to rewrite everything in Swift.
It’s likely that someday Apple will stop supporting Objective-C. This won’t break existing applications, but developers will have to rewrite code in Swift in order to update their apps. Applications that don’t move to Swift will be stuck with unfixed bugs, and they won’t be able to update to support new versions of iOS.
This doesn’t mean that developers need to rewrite existing applications, either now or later. As long as Apple maintains runtime compatibility, it should be possible to rewrite only the parts of the code that need changing. Still, it will be a messy job. Many developers have switched to solely writing in Swift to avoid this problem.
Swift and Objective-C aren’t the only languages for iOS app development, but they’re the only native ones, which means they can get closest to the operating system. Developers often use cross-platform environments so that they don’t have to write separate applications for iOS and Android. In this case, the same issues apply, but to the development environment rather than the application’s code. It ultimately generates Java code for Android and Objective-C or Swift for iOS. If it’s still generating Objective-C, developers should hope it will be updated to Swift soon.
For native development on iOS, Swift is becoming the language of the future. It helps to create applications that will be easier to maintain for years to come.
Developing custom mobile applications is our specialty at AppIt Ventures. To learn what we can create for you, please contact us.