In 2014, Apple dropped a little bomb of an announcement at their annual World Wide Developer Conference.
They announced a brand new flagship software programming language called Swift, which would serve as their go forward language to create iOS, Mac OS, Apple Watch OS and Apple TV OS application.
It understandably rocked the Apple developer world. Up until the Swift announcement, Apple’s primary software programming language, Objective-C, served as Apple’s primary application programming language since the debut of Mac OS X in early 2001.
Objective-C, as a language, actually existed even earlier than that. When Steve Jobs was originally ousted from Apple Computer back in 1985, he decided to start up a new computer company called NeXT Computers, to compete against IBM and Apple.
The first thing Steve needed was an object oriented programming language. At the time, there weren’t that many choices around for OOP languages. Java and C# were still years away. C++ was released at about the time that Jobs began thinking about creating NeXT Computers, but for whatever reason, Jobs picked another competing language called Objective-C.
Objective-C was really a superset of the C programming language with extensions that modified C to become object oriented.
Jobs used the Objective-C programming language to create their NeXT operating system for their NeXT computer system hardware.
In the years after Apple ousted Jobs, Apple wanted to replace their aging operating system with something more modern, to compete with the rising dominance of Microsoft and their Windows operating system.
But their efforts weren’t getting them anywhere as they got stuck in a quagmire of delays and failures.
Ironically, when Apple decided to shop around for an operating system developed by other companies, it came down to a choice between two competing operating systems, the Be Operating system and the NeXT OS from Steve Jobs.
Apple decided to choose Steve Jobs and his NeXT operating system. The NeXT operating system, built with the Objective-C programming language, thus became the primary programming language behind Apple’s operating system OS X.
nd for the next 15 or so years, Apple leveraged the power of Objective-C to help create the software behind their runaway successes such as the iPod, iPhone, iPad, Apple watch and Apple TV, and CarPlay products.
But as with anything else in technology, nothing lasts forever, and technology, in particular ages incredibly fast.
I believe that Apple’s primary motivation for creating the Swift programming language, is to take advantage of a lot of modern programming conventions in the 21st century.
Anyone who develops applications with Objective-C, quickly learns about some fundamental attributes about the language that show its age.
For example, every Objective-C code file that you create must come with a corresponding header file.
For younger developers who aren’t familiar with header files, they are separate code files that describe the “intent” of an Objective-C class file.
Objective-C files either have a file extension of .h (the header file) or .m (the class file).
Every Objective-C header file contains information about what a corresponding Objective-C class file can do. That is essentially the purpose of the Objective-C .h header file.
For example, this is a simple Objective-C class file.
@implementation Person : NSObject
@property NSString *firstName;
@property NSString *lastName;
– (NSString *)displayFullName {
NSMutableString *fullName = [[NSMutableString alloc] init];
[fullName appendString:firstName]; [fullName appendString:@” “]; [fullName appendString:lastName];return fullName;
}
@end
This Objective-C class represents a Person. This Person class has two attributes, a first name and a last name. It also has a method called displayFullName, which concatenates the first name and last name together and outputs them together as a full name of the
In order to be able to actually use this Person class, you MUST create a corresponding header file that looks like this.
@interface Person
@property NSString *firstName;
@property NSString *
-(NSString)displayFullName;
@end
The header file describes what the corresponding class file can do. It really doesn’t serve any other purpose.
Multiply this by the number of class files you have, and you’ve effectively DOUBLED the number of Objective-C code files you must create in order to create a properly working Objective-C application.
For a small application, this may not seem like such a big deal.
But for large applications, you suddenly have a code maintenance nightmare. For example, what happens when you need to add more methods and properties to your class file?
Guess what, you have to ADD the same type of descriptive information to the corresponding header file.
Anytime you need to add or edit functionality in your application, you’re constantly updating TWO related code files. And if you forget, your compiler will definitely complain about it, until you find the error and update your header and class files.
The Swift programming language completely eliminates this concept of header files. Every Swift code file stands alone. This one single change basically shrinks your potential codebase by 50% without any intervention or effort on your part as a developer!
This single improvement coincides with one of the great truisms of software programming … the less code you have to write, the better. More code equals more code maintenance equals more opportunities for introducing new software defects and bugs in your application. So the less code, the better!
Other syntax differences between Swift and Objective-C quickly become evident as you start coding in Swift.
In Objective-C, anytime you reference an object, it must be surrounded by beginning and ending square
ie.
NSString *firstName = [[NSString alloc] init];
Car *myCar = [[Car alloc] init];
[myCar accerlerate];That’s a lot of square bracket symbols to indicate it’s an object! The Swift programming language completely eliminates the need for square brackets. Again, going back to the adage, the less code, the better, why use square brackets?
Most modern programming languages use objects in one form or another … it just seems redundant and wasteful to tell the compiler you are dealing with objects, when you’re programming with objects most of the time, anyways!
Speaking of redundant symbols, no more semicolons needed at the end of every code statement. Compilers are smart enough these days to tell when your code statement has ended. It doesn’t need puny mortal humans like us to tell them to do their job of parsing and compiling code … that’s what they’re there for!
Other modern day programming language niceties include concepts like TYPE INFERENCE.
Swift is a STRONGLY TYPED language. Meaning that every variable and class reference in your code must have a corresponding data type.
In Objective-C, you must explicitly declare this in your code. For example, if you want to declare a variable to be a String type to hold something like your full name, you would create code that would look something like this.
NSString *fullName = [[NSString alloc]
You are telling your compiler that the class variable reference, fullName, is a special kind of String data type.
But in the new Swift programming language, you can code something like this to accomplish the same thing.
var fullName = “John Kim”
The Swift language compiler automatically “knows” or “infers” that your declared variable, fullName, is a string data type, because on the other side of the equals sign, the actual fullName value, John Kim, is surrounded by double quotation marks, which is the Swift syntax convention data type for a String.
This is just scratching the surface of all the language and concept differences between Objective-C and Swift.
But the overall intent with Swift seems to revolve around the concept of SIMPLIFICATION … less code, less maintenance, less bugs.
The introduction of Swift in 2014 was only just the beginning. Apple dropped yet another surprise announcement bomb in late 2015, by declaring that Swift has been released as open source, and free for anyone to make modifications to.
The Github community has thoroughly embraced the open sourcing of Swift and is busy making new modifications and improvements to the language. Swift, as a language, is already evolving at a frantic pace … version 3.0 of Swift is just around the corner.
IBM has embraced the Swift programming language and developing new cloud based applications.
Programming languages from the 1970s and 1980s feel heavy and verbose.
Programming languages in the 21st century are lightweight and expressive. Swift seems to be an apt name for the language, when you begin to understand all the language and concept improvements baked directly into the language.
The SWIFTer your code, the more time you have to spend on more important things.
Like more time going outdoors and playing Pokemon Go.
And no, I don’t play. I just heard about it, I assure you.