Hi every, I give a new release of spmForKmp, the <...

# feed

[François]

Hi every, I give a new release of spmForKmp, the version 1.0.0-Beta01
• This version gives a new way to import Swift packages into your iOSMain code with a faster build by avoiding a double compilation of native dependencies.
• An updated and dedicated documentation for this new major version
• As a beta, feedbacks is welcome

[Pablichjenkov]

Hey Francois, in the docs I see the example uses NSObject in the return type of the function exportView. Does it have to be that way or I can pass any type that is defined in commonMain. Let's say an interface I declared in commonMain, could it be the return type of one bridge function. Or are they limited to Swift primitives and NSObject only?

[François]

not from the commonMain but iOSMain, yeah
https://spmforkmp.eu/1.0.0/section-help/tips/#working-with-objcnamesclasses-types

[François]

limited at what’s inside iOSMain 🙂

[Pablichjenkov]

Gotcha 👌, well I mean that. If I define a type in common that is seen in iosMain then it will see it too.
Great tool 🔥

[François]

For type casting; both must be present inside the iOS SDK and the bridge.
Also, it must come from the ObjC and not Swift.
you won’t be able to cast the type correctly if you declare your type inside the commonMain.

[François]

like a UIView both are present inside the bridge and iOSMain but not in commonMain

[Pablichjenkov]

Humm, I haven't tried but I assume it works for every framework exported type or not?
The exported framework types are all objective-c AFAIK. And the swift side doesn't know if it was defined in commonMain or iosMain I guess.
But well if you said it doesn't work I assume you check this scenario already. It is an unfortunate 😔 since it will be pretty handy to create wrappers in swift of interfaces defined in commonMain pretty quick.

[François]

You still need the expect/actual feature so you can’t just import native code inside the common main

[Pablichjenkov]

If I use interfaces do I still need expect/actual?
Right, commonMain needs to get these wrappers injected. But I can do that using DI. Installing a module in the root DI component that will serve as factory for all the wrappers.

[Pablichjenkov]

But yeah it defeats the purpose of the plugin, I see it now. Ideally no injection or injection setup would be needed.