Да тут нечего продумывать, если есть ресурсы, требующие явного закрытия, от этого никуда не деться. У вас под рукой арены и memScoped есть, либо джавовый Closeable, вот это и есть идеоматичная работа с закрываемыми ресурсами.

Господа, создали multiplatform проект, засинтеропил libtommath, собрали под androidNative, все прекрасно собралось, подлжили полученный so в андроид JVM проект, упаковали в apk, но при запуске на устройстве, при вызове loadLibrary получаем java.lang.UnsatisfiedLinkError: dlopen failed: cant locate symbol "mp_init_multi" referenced by "/data/....../mylib.so" где mp_init_multi - функция из libtommath

Как бы это пофиксить?

И собственно причина не совсем понятна

И есть ещё момент, в libapi.h генерятся пустые структуры если в пакедже все классы internal. Честно говоря ожидали что в libapi.h будут только common функции, а по факту оказались все пакейджи с "внутренностями". Возможно как-то управлять генерацией .h файла?

Айосеры здесь?

Тутачки

Ну и зачем это всё?

Что конкретное вы хотите узнать?

Можно на ты?
Использует ли кто-нибудь фреймворки на Kotlin/Native в продакшене в контексте iOS разработки.
Есть ли средства дебага такого сетапа кроме как разработки touchlab?

Субъективно на первый взгляд кажется что этот подход довольно сырой.
Но есть подозрение что провайдер/разработчик фреймворка забыл держать в голове что разработка ведётся для нескольких платформ.
Хочется услышать что я не прав и это комбо имеет право на существование уже сегодня и для production систем.

думаю, тут больше помогут с вопросом
https://t.me/kotlinmppchats

При первом рассмотрении вещи типа:

// TODO: revise debug information handling.
if (debug) {

> -Xg0 experimental compiler flag

Так же добавляют сомнений.

Благодарю.

Потихоньку завозим KM на ios android. В прод может пойти через месяц другой. Для отладки ios проваливаться в kotlin framework без вариантов. Много проблем с multiplatform, что нужно завозить самому такие стандартные решения как работу с временем.

> Субъективно на первый взгляд кажется что этот подход довольно сырой.
Kotlin/Native в бете, multiplatform в experimental, я не знаю, с чего вы решили, громких историй успеха нет, есть только несколько больших компаний, которые отметили позитивный опыт с этим делом. Я не знаю, с чего вы взяли, что этот подход НЕ сырой.

> нужно завозить самому такие стандартные решения
Я бы не называл это проблемой ¯\_(ツ)_/¯

Сообщество стругает мультиплатформенные либы, команда активно работает над краеугольными вещами, через некоторое время это, я думаю, можно будет брать, не сомневаясь. Щас, конечно, больше похоже на то, что брать можно, только если есть силы и желание заниматься неготовыми вещами — к примеру, дофига энтузиазма у команды, либо профит от переиспользования действительно овер-огромный, либо если в прод покатится продукт через какой-нибудь абстрактный год, когда уже всё хорошо будет.