Hi Everyone. I can see some people have already ra...
# kotlin-native
p
Hi Everyone. I can see some people have already raised the issue about the UIWebView, and it has been 3 years since the first one was posted, but I just want an answer. What the specific reason why UIWebView gets referenced in the generated framework? Since some mentioned it still passes Apple's validation, I still need a specific reason why this occurs. My guess is that the UIKit is being compiled along with the project, but I'm not sure how accurate is that. Thanks to whoever is going to answer.
l
It’s possible that it’s due to the UIKit generated interop. I believe that cinterop generates its wrappers eagerly, so using UIKit should be enough.
I see the exact same thing from your message in the ios channel in our app that uses UIKit from Kotlin.
It looks like it’s just delegates, though. It doesn’t call into it at all, so Apple probably won’t care. The second column would say ‘U’ if it was used, I believe.
p
I understand that it’s just UIWebViewDelegates, and I think it’s not a big thing to worry about. But also, I just wanted to understand why it gets included on the generated framework as well. But I can see that no one else probably know the real answer. Probably even the KMM developers themselves. All we can do are mild speculations of why, but at the very least we have the same speculation as well. It could really be the UIKit that includes it.
l
If you check the Kotlin compiler, they automatically apply a def file for UIKit. If you look at
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/System/Library/Frameworks/UIKit.framework/Headers
on your mac, you’ll find a header for UIWebView.h. Since the def file doesn’t exclude it, cinterop generates the delegates.
cinterop doesn’t seem to check what your code uses right now. It just generates bindings for whatever is valid and not excluded in the provided headers.
p
Do you think it’s possible to “exclude” it? I don’t think any UIKit stuff is being used on our code right now, so it would be great if I could exclude it. I think the Foundation.h is enough.
l
I’m not sure. I think those are applied automatically. You could try manually creating a def for UIKit and exclude it there, but I don’t know if that will override what the compiler creates.
p
I see. I’m looking at some documentations, but I don’t understand it yet. If you could guide me on how to “customize” definitions, I’d be happy. Otherwise, it’s okay. You’ve been a great help so far.
l
Inside your module, create a folder src/nativeInterop/cinterop (nativeInterop should be next to commonMain). Inside of this folder, create a file called uikit.def and add the following content
Copy code
package=uikit
language=Objective-C
module=UIKit
headerFilter= {not entirely sure what to put here to exclude everything. Try experimenting with a few things}

compilerOpts = -framework UIKit
linkerOpts = -framework UIKit
p
How about the gradle file?
l
It may get mad that UIKit is already applied. I’ve never used this to override another def file. Only to add libraries for myself.
p
I’ve been trying to find a way to “exclude” a library; or in this case, I’d want to “exclude” the UIKit.def, but I’m not sure if that’s possible at all
Copy code
listOf(
        iosX64(),
        iosArm64(),
        iosSimulatorArm64()
    ).forEach {
        it.binaries.framework {
            baseName = "shared"
            xcf.add(this)
        }
        it.compilations.getByName("main") {
            val customInterop by cinterops.creating {
                defFile(project.file("custom.def"))
                
            }
        }

    }
l
You have it right. I’d recommend not setting defFile and letting it get it from nativeInterop/cinterop.
If you get it from the default place, the name has to match. For example, val uikit by cinterops.creating matches with uikit.def
If you’re using the delegates, I’d make it consistent and write val main by compilations.getting