Swift and Kotlin are the development languages for iOS and Android respectively. Both have certainly given the mobile development world a more functional feel. Their predecessors, Objective-C and Java, are very object-oriented, but Swift and Kotlin give us mobile developers an Object-oriented paradigm combined with some functional features. Swift and Kotlin were both designed to interop with Objective-C and Java, which allows for newer updates in apps to potentially be written in these languages. Both languages are foundational to the current mobile development world.
In college, my Compilers course was using Scala as its language. Even though I learned a great deal about the design of a compiler, I feel like the biggest reward long term was having to force myself to do functional programming. I didn’t have lots of experience with a functional programming language, but I did have lots of Java, C++, and C# experience. This made it easier for me when learning Swift and Kotlin because I had experience with both Object-oriented and functional programming. Being at WillowTree has allowed me to sink my teeth into both languages.
We have to remember that we aren’t comparing iOS and Android, or XCode and Android Studio: we are comparing the languages that are used to build apps on these platforms. With that being said, I have enjoyed writing code in both of these languages. This is a side-by-side comparison of some important concepts in programming within these two languages.
Kotlin has something called a data class, which is a class that when compiled, will get methods such as hashCode(), toString(), and copy() etc. It can be defined like this:
Swift does not have a data class or any equivalent.
Kotlin has a Pair and a Triple utility class for tuples of 2 and 3 components and it has the data class that can be used to emulate a custom tuple. Swift has tuple capabilities as well and can leverage the typealias for a tuple:
The difference between Swift Structs and Swift Classes is that Structs are actually value types, while Classes are reference types. Value types are copied when they are assigned to a new variable or when passed as a parameter. Think of a Tuple as an implicitly defined Struct:
Kotlin doesn’t have a Struct type. However, we can instead use a copy function to create a new reference:
Even though one is a reference type and the other is a value type, Kotlin Data Class and Swift Structs are used to hold data. Based on my experience, I would consider them to be equivalent to each other.
Both Swift and Kotlin have enums. Swift’s enums are algebraic data types, which are data types defined by two constructions, products, and sums. Kotlin’s definition of an enum uses that of Java, which is a predetermined set of constants for a type. Swift can use associated values. In these examples, you’ll also notice the differences between mapping values to defined cases (switch statements vs. when statements):
In order to take advantage of algebraic data types, Kotlin has Sealed Classes. The only difference between Kotlin’s Sealed Class and Swift’s Enums is that sealed class is a reference type, while Swift’s Enums are value types:
Swift and Kotlin both allow for optional types. While you can still make mistakes, Swift and Kotlin are considered safer languages than others. This makes null checking much more trivial and allows you to have a clear structure and well-defined parameters on what can null/nil and what can’t. Here are some examples of what can be done with optionals.
The philosophies on null/nil checking are different because of the way optionals/nullables are implemented in each language. Swift’s Optional is actually an enum that has two values, some(value) and none. This allows for the optional type to always have a value to its pointer. Kotlin uses the Java Virtual Machine’s way of having null values. For Kotlin nullables, there is still use of the null pointer, but with its type system, you can determine if a variable should be allowed to contain a null pointer. The goal of Kotlin nullables is to help with the issue of the NullPointerException and add more tools for type checking.
Swift also has implicit unwrapping, which defines an optional, but tells the compiler that it can unwrap it because it will have a value when ready. Kotlin can also do the same thing through the lateinit keyword. As developers, we try to avoid these as much as possible because of the dangers associated with using them, but they are useful for dependency injection (setting values in a type after initialization):
Both Swift and Kotlin have extension capabilities. Extensions add functionality to an already existing type. You can extend say the Int type, for example, but the syntax for both is totally different.
Protocols and Interfaces are the same thing, just using different terminology. They define a set of functions/variables that a class must conform to if it implements the interface. A couple of differences between Swift and Kotlin is that Kotlin allows you to provide default functionality for a method, while Swift requires an extension of the protocol in order to give an implementation. Another is for generics. Kotlin allows for generics to go in the definition of the interface and Swift allows you to define an associatedType to go along with conformance.
Higher Order Functions are essentially functions that accept closures or functions as parameters and return either a new value or another function. With higher order functions, we are able to transform, filter, and iterate through values such as arrays.
If we look at just the languages themselves, it’s obvious that they are very similar when it comes to syntax. Even if one of the languages may lack a feature of another, we can still accomplish the goal by doing something a little different. On their respective paths, Swift and Kotlin are only going to get better.
2019 has seen some huge advancements that have greatly changed the mobile development landscape. Starting at Google I/O, Jetpack Compose was introduced as a new declarative UI framework to follow a reactive programming paradigm for Android. Then at WWDC, Apple introduced SwiftUI, which is another declarative UI framework for iOS. Both were created to simplify UI development. With these new declarative UI frameworks, and the similarities we see between Swift and Kotlin, I predict that the learning curve for developers who are interested in learning about the other platform will decrease, and that we may see more developers eager to learn both platforms.