завтра поустанавливаю ваши плагины с той линки, все руки не дошли еще

https://github.com/icerockdev/mobile-multiplatform-education/commit/24949ced80a8905e7bcfd2cee4c8b0617aaa519f
этот шаг получается должен быть в градле модуля? с этим не падает

А вы не коммуницировали с JB на тему контрибуции части ваших наработок в котлиновский гредл-плагин? Я понимаю конечно, что HR-бренд тоже развивать надо, но мало ли :)

https://github.com/icerockdev/moko-template тут пример с полной конфигурацией обоих приложений + модуля общего и многомодульностью...не успел пока только добавить прям функциональные фичи в приложение-пример...конфиги пока только все есть тут. можно на него ориентироваться...

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

я вот смотрел у вас реализацию mvvm либы для common, в android части класс имплементит в себя viewModel, а в ios части это просто класс, я вообще не шарю в swift и ios разработке, но интересно почему так

общались, они тоже задали нам вопрос "почему не реквестите в официальный плагин?" :) ответ пока простой - нам сильно сподручнее и быстрее проверить результат с своим плагином, чем в официальный делать патч и потом ждать пока выйдет новая версия/публиковать отдельно от официального себе куда-то на мавен...крч просто удобнее и быстрее для наших процессов

Звучит логично :)

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

Ну одно другому не мешает, можно держать форк плагина и пользоваться им

публиковать свой плагин попроще для себя, чем публиковать официальный :) с ним сначала надо разобраться еще понять что как устроено и как публикация проходит.
Изначально все что сейчас в плагин завернулось было вообще на проектах просто в градл конфигах, постепенно улучшалсоь из проекта в проект и потом уже в плагин отделилось, чтобы проще было цеплять к другим проектам и в опенсорс вылить уже.
Не исключаю что когда нибудь позже начнем патчи в официальный плагин кидать, но сейчас чуть иные приоритеты (публикация оставшихся moko библиотек, подготовка moko-template, оформление обучающих материалов/ридми/статей)

Ну у меня тоже свой плагин (без нейтива), но так как там почти ничего принципиально нового (а что было, я послал разработчикам), то смысла особого нет чего-то комиттить.

а что в плагин вынесено было?

https://github.com/mipt-npm/scientifik-gradle-tools
Зависимости, настройки компилятора, деплой и сборка дистрибутива для JS

интересненько, но в целом нового ничего нету да...пока не отметил что нам в проекты полезно было бы.
А почему решили через плагины зависимости цеплять неявно? совсем неочевидно же

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

Зависимости только котлиновские вроде корутин, io и сериализации.

мы сделали централизованное управление зависимостями с специальными контейнерами под мпп зависимости. вот пример:
https://github.com/icerockdev/moko-template/blob/09a117bff898add8a2338b09ed9bcfe736f38a37/buildSrc/src/main/kotlin/Deps.kt#L51

Ну это в приципе вариант того же. Может быть у вас более удачный. Правда тут есть разница. У меня зависимости наследуются в подпроекты. Кроме того, там еще разные зависимости из разных репозиториев. Каждый раз прописывать репозситории довольно утомительно. А таскать их без вшитых зависимостей - странно. Думаю, что оба варианта могут существовать. Зависит от специфики.

эт да, под каждую задачу инструмент может быть свой :)