Обновить
4
0

Пользователь

Отправить сообщение
Тащить в наши готовые нативные приложения flutter было не очень разумно. Kotlin multiplatform оказался достаточно легковесным решением в нашем случае.
В идеале — да, очень удобно было бы писать mpp, iOS и Android код одному человеку. На практике в 99% случаев так не выйдет, из-за отсутствия экспертизы по «не своей» платформе. Поэтому mpp-часть идет отдельной задачей, выступающей блокером для платформенных. Писать ее могут как iOS, так и Android разработчики.
Добрый день,
1. Полностью отказываться от стандартной библиотеки для всего приложения будет очень больно. А вот написать пару каких-то сервисов, нагруженных логикой — с этим ок.
2. Идет с kotlin multiplatform из коробки
3. idea для multiplatform проекта, xcode для iOS приложения, android studio для android
Для нас это было обязательным условием. Если же приложения разрабатываются с нуля, возможно этот подход не для вас. К основным плюсам такого подхода я бы отнес производительность и безболезненную интеграцию в существующие нативные приложения. Если эти пункты для вас не критичны, возможно стоит посмотреть в сторону react native или чего-нибудь подобного.
Спасибо за комментарий, в статье эта тулза не упомянута.
Не рассматривали. Но думаю что использовать бы не стали, опять же, по историческим причинам. Мы имели 2 готовых приложения, в которые нужно было вставить большой кусок логики.
Выбор нативной реализации UI был для нас легким решением по историческим причинам. Т.е. приложения были написаны на момент выбора инструментов реализации данной задачи.
Ядро на C++ отвечает только за логику. Работа с базой данных, сетевые запросы и UI реализованы нативно.

Информация

В рейтинге
Не участвует
Работает в
Зарегистрирован
Активность