IceRock

Не будем спорить про преимущества KMM/Flutter/RN, это слишком холиварная тема. Для нас KMM стал основной технологией из-за нескольких факторов:
1. Низкий порог вхождения для android разработчиков, которых у нас много. iOS разработчиков мы достаточно быстро погрузили в необходимые технологии, и продолжаем всех обучать
2. KMM позволяет реализовать нативный UI на каждой платформе, что привычно пользователям, и не вызывает отторжения

Такие ситуации мы, на самом деле, действительно довольно часто ловили на первых проектах, когда ещё обкатывали технологию. Это работало в обе стороны - андроидщики ломали iOS, айосники ломали андроид.
Об этом говорили вот тут вот на докладе: https://www.youtube.com/watch?v=h9ioWnSlUJc (примерно с 6:40).
Поэтому мы вывели определённый набор правил и стандартов, которых придерживаемся у нас при разработке. Они помогают унифицировать подходы по взаимодействию нативных приложений с common-кодом без ущерба какой-либо из платформ. Так что сейчас вероятность таких поломок сведена к минимуму

Из нашего опыта, чтобы освоиться в проекте и в этих технологиях, андроид-программисту надо не больше 1-2 недель, айоснику - больше, может быть месяц, но всё сильно зависит от опыта и настроя специалиста :)

Здравствуйте! Да, но это не мешает нам уже 4.5 года использовать эту технологию. Вы правы, что пока это не станет релизом, каждый использует на свой страх и риск )
А для новичков мы прямо сейчас готовим обучающий курс по нативному айосу, андроиду и КММ, чтобы упростить вход в эти технологии.

Расул, мы лишь отражаем свой опыт работы и видим так эти технологии. Мы – независимый разработчик, нам нет профита восхвалять что-то определенное, мы – инженеры и выбираем тот инструмент, который лучше подходит под задачу.

Борис, вы правы, нативный стек точно продолжит развиваться, что нельзя сказать про различные кроссплатформенные фреймворки (Cordova и иже с ними).

Вход в программирование на Flutter действительно ниже, благодаря материалам от Google, можно собрать своё простенькое приложение довольно быстро, но это не избавит вас от знания мобильных операционных систем и от специфики мобильных платформ, это всё равно нужно знать при создании мобильных приложений.

Согласны с вами – мы уже 2.5 года делаем KMP и видим много плюсов от использования этой технологии – она ускоряют разработку, в результате получаются полностью нативные приложения (и нативный UI), нет промежуточных прокладок-мостов между операционной системой и приложением. 
При этом огромный плюс в том, что эту технологию безболезненно можно "заводить" в большой, существующий нативный проект постепенно получая преимущества использования этой технологии. Flutter конечно хорошая технология, но в уже существующих проектах его внедрить выглядит проблематично. 

Бекназар, это так Netflix приложения называют: Android and iOS studio apps :) 
А так, да, вы абсолютно правы, IDE называется Android Studio. 

Но ведь вы сами написали, что флаттер работает через бриджи? :) А теперь пишете, что в случае флатера тоже также, где правда? :) 

В том и суть, что KMP сильно отличается от других кроссплатформ, потому что:
- взаимодействует с OS напрямую
- реализует нативный UI.
- хочешь пишешь в общем модуле, не хочешь - уносишь пишешь на нативе.
Это для нас самое важное и ключевое. 

Но про "не дают использовать" — неправда же. Да, через бриджи или каналы, но возможность есть.

Да, вы корректнее и точнее сформулировали. 

Серьезно? А может лучше честно?)

Серьезно и честно. Когда у вас реализована общая логика в общем модуле, то изменения в этом модуле применяются сразу на двух платформах. 

Упс, ответили комментарием ниже :/

Не совсем так. Кроссплатформенные решения вида Flutter или React Native добавляют дополнительную абстракцию от платформ. Они усложняют работу с самой платформой и не дают использовать обширный набор библиотек от нативного iOS/Android-сообщества.
А Kotlin Multiplatform - решение лишено подобных недостатков, в связи с чем имеет заметные преимущества перед остальными т.к. платформозависимый код с kotlin multiplatform сильно проще реализуется, чем в Flutter и React Native - не надо никакие каналы и прокси строить, просто вызываешь функции напрямую, а UI приложения полностью нативный для Android и iOS, и развитие проекта наращивание функционала возможно без ограничений.
В итоге получается, что при отладке кода его нужно будет править лишь один раз, и исправления произойдут сразу на обеих платформах. Но вы правы, без платформенного кода никуда - UI используется полностью нативным (что мы считаем преимуществом).

В общем, экономия при разработке сильно зависит от проекта и его особенностей – где больше работы над интерфейсами (UI) в приложении - там экономии меньше, поскольку UI реализуется на платформенной стороне дважды. А если у проекта много бизнес-логики - тогда экономии больше, потому что она реализуется в общем коде один раз. 
В целом, мы на проектах видимо от 20% до 40% экономии трудозатрат по сравнению с использованием только нативных технологий, поэтому 30% будет где-то близко к нашему опыту :)

Полезно и структурированно, супер! 

Наше решение поддерживает и самовывоз также - это опция при оформлении заказа пользователем. Заказ формируется в кафе и забирается пользователем в удобное ему время. 

Спасибо за добрые слова! 

Да, конечно, это решение отлично подходит для дарк сторов - у них так же есть кухня, блюда, потребность доставлять продукты и организовать витрину для своих пользователей. 

👍🏻👍🏻

Да, в том и отличие, например, от UDS, что это не агрегатор, а свой продукт, который можно раскручивать и собирать свою пользовательскую базу, работать с ней, повышать ретеншен, средний чек и виральность данного продукта. А клиентов действительно хватит всем! 

От ресторана требуется только предоставить необходимые для подключения данные - данные по iiko, зарегистрировать эквайринг, произвести небольшую конфигурацию iiko (может помочь сервисная компания iiko)  и зарегистрировать аккаунты в аппсторах (тут мы помогаем). 
Сам процесс подключения с нашей стороны занимаем 2-3 рабочих дня, главное, чтобы все данные были предоставлены. 

Писали своё с нуля. Взаимодействие ресторана с пользователем происходит через наш сервер приложения, далее сервер обращается к конкретному терминалу iiko, с которым взаимодействует сотрудник ресторана. 

Карим, вы знаете, мы с Kotlin Multiplatform уже больше 2 лет, и мы очень довольны технологией. Да, моменты были, мы их все описали в блоге на Medium, но теперь всё круто - мы собрали все наработки и выложили в опен сорс moko.icerock.dev, собрали сообщество в Телеграмме @kotlinmpp (там уже 800+ программистов) и видим как технология растет и набирает обороты. Могу сказать, что мы с ней надолго :) 

Исправили! 

Да, вы правы, исправим неточность в статье. 

R-keeper в планах, если текущее решение будет пользоваться спросом. Пока что мы видим, что iiko пользуется довольно хорошим способом. Почему начали с неё? Так сложилось исторически :) 

Насколько мы знаем, алкоголь пока что не разрешен для дистанционной торговли, но мы знаем, что некоторые компании активно готовятся к будущему разрешению :) 

Даша, в чем именно вы видите риск?