iOS + Kotlin. What can be done now
An example of uikit appeared in the master branch of the Kotlin Native project . This is a simple iOS application that displays the line entered in the input field, and yes, 100% of the code is written in Kotlin. It looks like this:
Yes, but only if:
0). You really need a common code base of mobile applications.
one). The application is not tied to the platform.
2). You have time to write a certain amount of code on Kotlin, which in the future should be rewritten in Objective-C or Swift.
')
ViewController, AppDelegate and even the main function in the example are written in Kotlin. Those files that are written in Objective-C are needed only so that Xcode does not give an error and are not included in the final assembly (I did not find a way to fix the situation). Those. full-fledged interop as with Java, apparently, is not yet available. This does not mean that the situation will not change to release (now the project is at the stage of alpha preview, and there was not even a blog post about this example). But the range of options currently available is rather limited.
The idiomatic approach to writing a multiplatform application on Kotlin is to write the general part separately, separately the part for each platform. At the same time, on each platform, as planned, all the libraries written for it should be easily accessible. In the case of Java, it works well. In the case of iOS, the situation is as follows:
That is quite good. We add @ExportObjCClass annotation to each external class, @ObjCOutlet and @ObjCAction for each action graphic to each graphic element from the storyboard. Classes in Objective-C are available by their original names.
This article describes how to do this. After a number of layers, with manual type conversion 2 times, but you can call Swift from Kotlin and Kotlin from Swift.
In theory, the application weight should increase by about 100 kb ( from here ).
Instead of GC, ARC will be used, so there should not be much difference in performance with Swift.
Judging by the reports of the team members developing the language, backward compatibility is one of their main priorities. How good it is to judge you. Personally, I think that it is much better than Swift and, in general, the language is good and most of the puzzlers look far-fetched. But there is 1 thing that, in my opinion, can be a “time bomb” and cannot be fixed with respect to backward compatibility.
To implement coroutines that make synchronous and asynchronous code look almost the same, only one new keyword suspend was entered into the language, which the developers deserve to be proud of . But in order for extension methods ( forEach , map ...) to work as fast as normal for (and for outputting common types during program execution), as many as 3 ( inline, crossinline, noinline ) were introduced. They obviously do not make the code more readable. JIT loses some of the possibilities for optimization (a podcast about it ), and C experience shows that developers are not able to correctly use such features of the language. In general, I do not understand why the same thing could not be done annotation. For me, inline looks like a bad solution to a decent problem.
Should I think about the port of your application now?
Yes, but only if:
0). You really need a common code base of mobile applications.
one). The application is not tied to the platform.
2). You have time to write a certain amount of code on Kotlin, which in the future should be rewritten in Objective-C or Swift.
')
Reasons not to port yet
ViewController, AppDelegate and even the main function in the example are written in Kotlin. Those files that are written in Objective-C are needed only so that Xcode does not give an error and are not included in the final assembly (I did not find a way to fix the situation). Those. full-fledged interop as with Java, apparently, is not yet available. This does not mean that the situation will not change to release (now the project is at the stage of alpha preview, and there was not even a blog post about this example). But the range of options currently available is rather limited.
Interop
The idiomatic approach to writing a multiplatform application on Kotlin is to write the general part separately, separately the part for each platform. At the same time, on each platform, as planned, all the libraries written for it should be easily accessible. In the case of Java, it works well. In the case of iOS, the situation is as follows:
@ExportObjCClass class KotlinViewController : UIViewController { constructor(aDecoder: NSCoder) : super(aDecoder) override fun initWithCoder(aDecoder: NSCoder) = initBy(KotlinViewController(aDecoder)) @ObjCOutlet lateinit var label: UILabel @ObjCOutlet lateinit var textField: UITextField @ObjCOutlet lateinit var button: UIButton @ObjCAction fun buttonPressed() { label.text = "Konan says: 'Hello, ${textField.text}!'" } } That is quite good. We add @ExportObjCClass annotation to each external class, @ObjCOutlet and @ObjCAction for each action graphic to each graphic element from the storyboard. Classes in Objective-C are available by their original names.
If you need to call Kotlin from Objective-C / Swift
This article describes how to do this. After a number of layers, with manual type conversion 2 times, but you can call Swift from Kotlin and Kotlin from Swift.
Overhead
In theory, the application weight should increase by about 100 kb ( from here ).
Instead of GC, ARC will be used, so there should not be much difference in performance with Swift.
backward compatibility
Judging by the reports of the team members developing the language, backward compatibility is one of their main priorities. How good it is to judge you. Personally, I think that it is much better than Swift and, in general, the language is good and most of the puzzlers look far-fetched. But there is 1 thing that, in my opinion, can be a “time bomb” and cannot be fixed with respect to backward compatibility.
inline
To implement coroutines that make synchronous and asynchronous code look almost the same, only one new keyword suspend was entered into the language, which the developers deserve to be proud of . But in order for extension methods ( forEach , map ...) to work as fast as normal for (and for outputting common types during program execution), as many as 3 ( inline, crossinline, noinline ) were introduced. They obviously do not make the code more readable. JIT loses some of the possibilities for optimization (a podcast about it ), and C experience shows that developers are not able to correctly use such features of the language. In general, I do not understand why the same thing could not be done annotation. For me, inline looks like a bad solution to a decent problem.
Conclusion
- Kotlin will soon be able to write for all 3 major platforms (Android, iOS, Web).
- Most likely, there will be good compatibility with Objective-C and Swift. Perhaps better than the one that exists between these languages. Given the experience of JetBrains in the development of compilers and IDE, you can believe this.
- Kotlin has a lightweight Runtime language for Android and Web. Under iOS, apparently, will also not be difficult.
- Already, you can write something.
Source: https://habr.com/ru/post/337958/
All Articles