В ветке master проекта Kotlin Native появился пример uikit. Это простое приложение под iOS, которое выводит на экран строку, введённую в поле ввода, и да, 100% кода написано на Kotlin. Выглядит оно так:

Стоит ли думать о порте своего приложения уже сейчас?

Да, но только если:

0). Вам действительно нужна общая кодовая база мобильных приложений.
1). Приложение мало завязано на платформу.
2). У Вас есть время на написание некоторого количества кода на Kotlin, который в будущем стоит переписать на Objective-C или Swift.

Причины пока не портировать

ViewController, AppDelegate и даже main-функция в примере написаны на Kotlin. Те файлы, которые написаны на Objective-C нужны только чтобы XCode не выдавал ошибку и не включаются в конечную сборку (я не нашёл способов исправить положение). Т.е. полноценный interop как с Java, видимо, пока что, недоступен. Это совсем не значит, что положение дел не изменится к релизу (сейчас проект на стадии alpha preview, а об этом примере даже поста в блоге не было). Но спектр доступных сейчас возможностей довольно ограничен.

Interop

Идиоматический подход к написанию мультиплатформенного приложения на Kotlin — отдельно написать общую часть, отдельно — часть для каждой платформы. При этом на каждой платформе, по задумке, должны быть легко доступны все библиотеки, под неё написанные. В случае с Java работает хорошо. В случае с iOS дела сейчас обстоят следующим образом:

@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}!'"
    }
}

То есть вполне неплохо. К каждому внешнему классу добавляем аннотацию @ExportObjCClass, к каждому графическому элементу из storyboard — @ObjCOutlet и @ObjCAction для каждого action. Классы на Objective-C доступны по их оригинальным именам.

Если нужно вызвать Kotlin из Objective-C/Swift

В этой статье описано, как это можно сделать. Через некоторое количество прослоек, с ручным преобразованием типов 2 раза, но зато можно звать Swift из Kotlin и Kotlin из Swift.

Overhead

В теории, вес приложения должен увеличиться примерно на 100 кб (отсюда).
Вместо GC будет использоваться ARC, так что особой разницы в производительности со Swift быть не должно.

Обратная совместимость

Судя по докладам участников команды разрабатывающей язык, обратная совместимость — один из их основных приоритетов. Насколько это хорошо — судить вам. Лично я считаю, что это намного лучше, чем у Swift и, в целом, язык хорош и большинство паззлеров выглядят надуманными. Но есть 1 вещь, которая, по моему мнению, может быть «бомбой замедленного действия», при этом не может быть исправлена с соблюдением обратной совместимости.

inline

Для реализации сопрограмм, которые делают так, чтобы синхронный и асинхронный код выглядели почти одинаково в язык было введено всего одно новое ключевое слово suspend, чем разработчики заслуженно гордятся. Но для того чтобы методы-расширения (forEach, map...) работали так же быстро, как и обычный for (и для вывода общих типов во время исполнения программы), было введено целых 3 (inline, crossinline, noinline). Они явно не делают код читаемее. JIT теряет часть возможностей для оптимизации (подкаст об этом), а опыт C показывает, что разработчики не умеют правильно пользоваться такими возможностями языка. В целом, не понимаю, почему то же самое нельзя было сделать аннотацией. Для меня inline выглядит как плохое решение достойной проблемы.

Заключение

• На Kotlin скоро можно будет писать под все 3 основные платформы (Android, iOS, Web).
  
• Скорее всего, будет хорошая совместимость с Objective-C и Swift. Возможно лучше, чем та, что есть между этими языками. Учитывая опыт JetBrains в разработке компиляторов и IDE, в это можно поверить.
  
• У Kotlin легковесный Runtime языка под Android и Web. Под iOS, судя по всему, тоже будет не тяжёлым.
  
• Уже сейчас можно что-нибудь написать.