ну у вас "кроссплатформенное" приложение, а апи на разных нативных платформах разное. в итоге вам надо писать бридж, что геморрой. например airbnb съехали с react native потому что разработчики писали в основном бридж к системе вместо бизнес логики

в зависимости от того, насколько это геморройно на котлине - взлетит не взлетит. ну и перфоманс как всегда

огонь

Потому KMM подход специально сделан отличным от Flutter/RN - шарить логику, сетевой код и т.п., а платформо-зависимые вещи (UI и системные API) писать под платформу. expect/actual механизм позволяет многие вещи даже обернуть в единый фасад-интерфейс.

Не знакомились с последним Online Event?

Что меня очень смутило, конечно, потому что блин, ну это же долбаный маркетплейс, там кроме карт нет никаких платформо-специфичных вещей!

не вижу противоречия тому, что я написал. вы все равно под каждую платформу сами будете писать код, который заворачивает нативные апи. чем это отличается от всех остальных кроссплатформ? ссылка на доки https://kotlinlang.org/docs/reference/mpp-connect-to-apis.html

У RN были проблемы с перфомансом и багами, которые висят в трекере годами. :)

Другие подходы (RN/Flutter/Cordova) диктуют свой подход - нужно переделывать приложение, UI. KMM можно начинать использовать прямо на живом нативном приложении, например.

то есть можно взять приложение на objective c и завернуть в котлин?

Можно начать в нативном приложении использовать флаттер:D

ксамарин, кстати, немного по-другому ведь делает - они все нативные апи сами завернули изначально. с очевидным изьяном - отставание на пару версий от последних апи платформы

Можно взять приложение на Objective C и часть его вынести в общий код на Kotlin, да.

Как и у Флаттера сейчас, и это объснимо. Но OP пишет, что проблема была в объёме трудозатрат на коммуникацию с нативными API на платформах.

пока не понял, в чем преимущество. то же самое, если вы решите мигрировать на любую другую кроссплатформу. мне кажется, только новые проекты имеет смысл так готовить. ну или переписывать заново, иначе "поменять Х в приложении" все равно будет зависеть от нативных разработчиков, которые знают, как работает iOS

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

Есть у вас бизнес-логика в приложении, которая та же на iOS и на Android. Её пишут две разные команды. Это можно вынести в JS/C++/Kotlin код и писать один раз.

Дальше, эндпоинты на сервере тоже, скорее всего, используются одни и те же. И сериализация в модельки. Это тоже можно вынести.

UI и работу с платформенными API можно оставить писать каждой команде. Иногда (если нет сильных платформенных различий) их тоже можно скрыть за единым интерфейсом.

обычно такие приложения пишут там, где не нужно много платформенных API

и все новые модные фичи типа дарк модов виджетов итд