[robertlagrant]

I always thought a really good use of KMP would be in writing shared non-visual code, e.g. a library that interacts with your API(s) and any non-visual like that. Then paint a dumbish, platform-specific frontend over the top and link together.

[seanalltogether]

As someone who has to manage native ios and android apps I thought this would be the perfect solution as well. I wanted to write all my data models, api calls, sql cache and business logic as a separate library written with kmp, but what i didn't like was that the ios framework that was generated was a black box with just objc headers. If it generated full swift code that i could inspect for correctness and tweak if needed, I would have jumped on using it right away.

[robertlagrant]

That's interesting - I can sort of see it both ways. Would applying unit tests to the exposed functions not have sufficed?

[andrekandre]

not the op, but had similar experience

kmp exposes everything as obj-c meaning c headers and not very good type annotations (enums are int only so you cant have full checking on each switch, everything is obj-c reference semantics meaning multi-threading gets tricky, kotlin exceptions are not catchable from swift) so there are a lot of edge cases to write unit tests for (on the client side) which negates a lot point of using kmp, and thats in addition to all of the kotlin-isms that leak out...

[robertlagrant]

Ah, right. Yeah, that is surprisingly bad! Why wouldn't they at least generate enums!

[andrekandre]

  > Why wouldn't they at least generate enums!

they do but its going through objective-c which inherits c enums (which are basically integers) so when you use it from swift its like switching over an unbounded set so you always have to handle "default" cases leading to bugs compared to usage from android