Насколько интересно писать на Kotlin Multiplatform и участвовать в переписывании Android и iOS приложений

Что проверяют

Как iOS-разработчик отнесётся к тому, что часть логики уедет в общий Kotlin-модуль, и понимает ли он цену такого решения. Готовы ли вы читать и править Kotlin, а не только подключать готовый фреймворк и жаловаться на него.

Как отвечать

Скажите, что интересно, если понимаете границу общего кода. Разумная граница: сеть, модели, кэш, бизнес-правила общие, а UI остаётся нативным на SwiftUI или UIKit.

Покажите, что представляете, как это выглядит со стороны iOS. Общий модуль приезжает фреймворком с интерфейсом, совместимым с Objective-C, поэтому типы отображаются не один в один: sealed class превращается в набор классов без исчерпывающего switch, дженерики и suspend-функции доступны ограниченно, асинхронность приходит колбэком или через обёртку. Отладка общего кода из Xcode менее удобна, чем нативного, время сборки и размер фреймворка растут, а часть платформенных вещей всё равно пишется через expect и actual.

Закончите встречным вопросом: кто владеет общим модулем, могу ли я вносить в него правки сам и как устроено ревью для кода, который затрагивает обе платформы.

Где спотыкаются

Соглашаются с формулировкой про переписывание приложения целиком. На KMP переписывают логику, а не приложение: интерфейс остаётся нативным, и здоровая практика это постепенный вынос модулей, а не большой перезапуск.

Хвалят подход словами «пишем один раз», не называя ни одной цены. Интервьюер, который уже жил с interop, делает вывод, что реального опыта не было, и дальше спрашивает про мелочи отображения типов.

Называют экономию времени в процентах. Выигрыш зависит от доли общей логики, и на приложении, где основная сложность в интерфейсе и анимациях, он невелик. Честнее сказать, что экономия в поддержке правил, а не в скорости первого релиза.