Почему наши клиенты приходят за разработкой на Kotlin Multiplatform Mobile: нативный UI и возможности развития
В предыдущих статьях серии мы уже рассказали о том, как снизить риски в iOS-разработке в условиях санкций с помощью Kotlin Multiplatform Mobile. Сегодня перейдем от теории к практике: расскажем, как создали на KMM приложение для поиска автомоек «Мойка-мойка» для Ucar и что это дало нашему клиенту.
Спасибо за статью, не так давно слежу за КММ, но всё же назрел вопрос. Забабахали вы сторону андроида и мультиплатформенную логику, ios пока остался в стороне, затем придет клиент и скажет - пилим ios!
Собственно сам вопрос в том, а не будет ли потом этот самый ios разраб страдать из-за того, что в прошлом нативный разраб, а ныне мультиплатформенный котлинист, прикрутил мультиплатформу так, что её использование будет удобно только андроиду? Есть же согласованность между разработчиками как в описанном вами случае, что например, так делаем, а так не делаем, по тому что.... на стороне ios?
Такие ситуации мы, на самом деле, действительно довольно часто ловили на первых проектах, когда ещё обкатывали технологию. Это работало в обе стороны - андроидщики ломали iOS, айосники ломали андроид.
Об этом говорили вот тут вот на докладе: https://www.youtube.com/watch?v=h9ioWnSlUJc (примерно с 6:40).
Поэтому мы вывели определённый набор правил и стандартов, которых придерживаемся у нас при разработке. Они помогают унифицировать подходы по взаимодействию нативных приложений с common-кодом без ущерба какой-либо из платформ. Так что сейчас вероятность таких поломок сведена к минимуму