Kotlin vs. Swift: Android and iOS moving towards a universal language?





Friends, hello everyone. In touch Dmitry Kozhevin is a teacher of the basic course “Android Developer” at OTUS. Especially for readers of our blog, I have prepared a translation of such a partly provocative article. Your opinion is very interesting, therefore, after reading, I invite everyone to comment on this publication.






Once Kotlin got Google support, the sheer excitement of Kotlin fans was not the only reaction. Those unfamiliar with Kotlin were very concerned about its level of compatibility with Java, the average time needed to learn it, and the benefits of using Kotlin in general.



In their attempts to explain and present the language in the shortest and clearest way, many Kotlin developers referred to the three-year parallel between Kotlin and the second official iOS language, Swift. Calling Kotlin “Swift of Android”, everything simplified the task and helped create an image for the language. However, this image also caused controversy in the iOS community, as some iOS developers did not find the comparison flattering and saw Kotlin just a copycat.



At least it should be noted that although Swift appeared in 2013, Kotlin appeared back in 2011. Consequently, even if comparing Kotlin and Swift (in that exact order) may be convenient due to Swift's earlier exposure to a wider audience, any claim that Kotlin imitates is not justified.



However, is it worth comparing? If so, how much does the similarity extend? And does its existence hint at the fact that the release of applications for iOS and Android may initially become simpler and faster in the future? ScienceSoft's vast experience in mobile app development services allows speculation at this point. Let's take a look at that.



Syntax



Swift syntax is not just reminiscent of Kotlin syntax - in small pieces of code there can be up to 77% line similarity .



The main differences can be summarized in the table below:



Kotlin Swift
fun func
val let
null nil
trait protocol
constructor init
: ->
Any Anyobject
!! !


Fundamentals, classes, and functions have very similar ways of expressing. Unlike Objective-C, Swift method calls are similar to Java and Kotlin calls, with their namespace system and dot notation style. For example, here's what a function call looks like in two languages:



Kotlin Swift
fun forecast (day: String, weather: String): String { func forecast (_ day: String, _ weather: String) -> String {
return "Today is $ day, it's $ weather." return "Today is \ (day), it's \ (weather)."
} }
forecast ("Monday", "Raining") forecast ("Monday", "Raining")


And this is how the classes are declared in both:



Kotlin Swift
class Residence { class Residence {
var numberOfRooms = 0 var numberOfRooms = 0
fun Description () = func Description () -> String {
“A house with $ numberOfRooms.” return "A house with \ (numberOfRooms)."
} }
}


You can find many other examples in this article , and if they tell us something, then it is that both languages ​​have a common goal - to be as concise and transparent as possible, which makes the life of developers easier. The syntax systems of Kotlin and Swift are quite effective in this regard, since the development teams highly value their elegance.



Security



Although Swift and Kotlin are strong and static in terms of typing, they also allow you to work with dynamic types. In this way, languages ​​remain concise and flexible, allowing for the early elimination of errors and inconsistencies. Therefore, they are considered very safe and especially reliable for large projects.

In addition, these two languages ​​combine approaches to handling optional values ​​and null / nil security using the safe navigation operator "?" or types of options. Precautions marked with a "?" expressed almost identically in both Kotlin and Swift:



Kotlin Swift
val example: String? = null var example: String? = nil


Features



In addition to null (nil) security, functions and classes, Kotlin and Swift have many similar functions, including constants, variables, generics, protocols/traits



( trait replaced with interface , translator's note), enumerated types, any (anyobject)



, error handling and others. Some functions implemented in two languages ​​share the approach, but are called differently because of the original language to which these functions return.



For example, in Kotlin you can find Java lambda expressions. In Swift, these are blocks or closures, terms from Objective-C. The way both expressions are called into code is similar to how they work.

Kotlin Swift
{ {_in
println ("Lambda Expression") print ("Closure Expression")
} }


A function known as computed properties in Swift, which is a specific property declaration with a call to get, is also included in Kotlin:



Kotlin Swift
class Animal ( class Animal {
var Genus: String, var Genus: String
var Species: String) { var Species: String
val binomialName: String var binomialName: String {
get () = "$ Genus $ Species" get {
} return "\ (Genus) \ (Species)"
}
}
}


Name parameters (or named arguments) are also used in both languages:

Kotlin Swift
fun daysoff (vacation: Int, weekends: Int): Int = vacation + weekends func daysoff (vacation: Int, weekends: Int) -> Int {
return vacation + weekends
}
daysoff (5, weekends = 8) daysoff (vacation: 5, weekends: 8)


In fact, instead of listing the functions that exist in both languages, it would be easier to list those that do not. Namely, only Kotlin supports:





At the same time, unlike Kotlin, Swift has:





Similarity value



The two languages ​​clearly share ideology, since they solve the same problems that were created by the languages ​​of their ancestors: they are less verbose and limited in function, more readable and convenient to work with. At the same time, Kotlin and Swift remain compatible with Java and Objective-C, respectively, which allows them to be used both in new projects and in servicing old ones.



Moreover, the strong similarities between the two languages ​​can help in the development of native applications for iOS and Android. Of course, it cannot be said that applications on both platforms can share the same code, since languages ​​and libraries for specific operating systems are not identical. However, the approaches to the logic and functionality of the application can be very similar, thanks to the syntactic and functional similarities between Swift and Kotlin. This can make development, testing and maintenance faster and easier.



Universal language for iOS and Android?



Theoretically, Google could already accept Swift as an official language instead of Kotlin; even in 2016 there were rumors about this possibility. Such a step would probably not create a situation where any cross-platform development tools would become irrelevant, but the difference between the two platforms would undoubtedly become blurred.



However, such a step would also be unreasonable, and not only because of the competitiveness of the business. Although Swift and Kotlin are similar, most of all they are similar to their predecessors. In other words, Swift and Kotlin bridge the gap between Objective-C and Java. However, switching from Java to Kotlin is still more natural and smooth than switching from Java to Swift.



In general, not everyone likes the idea of ​​adapting to something new; some developers take the time to start using the new language, as was the case with the adoption of Swift . To make sure that the transition to a new language will not be such a difficult test means that the language eventually gains popularity, and for a new language this is important in the first place.



Farewell thought



As mobile development is constantly evolving, so are technologies. That is why in 5-10 years both Kotlin and Swift can become something completely different. It is not yet known whether languages ​​will continue to bridge the gap between themselves. However, since iOS and Android are looking for the most convenient, secure and fastest tool for mobile development, they will end up being able to speak the same language one day.



All Articles