Hey gang ... not really a touchlab specific questi...

# touchlab-tools

[Bradleycorn]

Hey gang ... not really a touchlab specific question, but ...
Has anyone run into an issue where Xcode's intellisense stops being able find/show methods from the Kotlin framework?

[François]

try to reduce the content of the generated header by using explicitAPI in the shared Gradle, you will filter out unneeded content.
A file that contains thousands of lines of declaration is not good for xcode.

[kpgalligan]

Reducing the api surface is good practice. explicit api helps considerably, although you'll obviously need to clean up the API with that on. In addition, look at the output. The Kotlin compiler will include anything your public api references, so it's very easy to pull in dependencies that Swift doesn't need. For example, if you have something from ktor as a param or return value from a method, the Kotlin compiler will then export that and anything that ktor thing references. You can wind up with a lot of stuff in the exported api that you don't need.
That, in turn, will not just clutter the header, but each exported Kotlin structure has binary added to support talking to Swift/Objc, which can add considerably to the binary size.

[François]

Yes, same thing for the coroutine, but these are kind of unavoidable.

[François]

I made a thread about it https://kotlinlang.slack.com/archives/C3PQML5NU/p1734628374467079
I think people need to be more aware of that issue.

[kpgalligan]

i've probably had 20 threads on this stretching back to 2019 or so. I do find the lack of practical best-practice in a lot of the "getting started" content to be frustrating. Slack in particular is not a great choice for support chats, because important points just kind of "disappear" as they get old. They don't actually go away, but finding anything is brutal.

[kpgalligan]

We did some binary tests a few years back, and the binary size impact alone can be very significant.

[kpgalligan]

For things like sqldelight, I'd always recommend having the db in a module and not exporting that module explicitly, because the generated code includes sqldelight dependencies, and probably a lot of stuff you don't need from swift. The scope of the binary size issue first came up when a fairly prominent app team was investigating KMP and reached out about how bad the binary size was. They had like 100+ tables in the db. After deep-diving on their binary issue, it turned out that probably most of that binary was just the Objc adapter code added by the compiler, and none of that code was directly referenced by Swift.

[François]

Great to hear that. I guess we can’t control the visibility of the generated class? (lol)

[Bradleycorn]

I'd always recommend having the db in a module and not exporting that module explicitly,

Yeah, i always put database (and other long term storage) stuff and network stuff into their own modules, and don't export those. They remain internal to the kotlin library.
You mentioned Ktor stuff getting "leaked" into the exported api ... I have run into that before as well.

[François]

The public by default of Kotlin is a big issue and, indeed, some workaround need to be done.

[kpgalligan]

Great to hear that. I guess we can’t control the visibility of the generated class?

It's been discussed. I'm all for it, in theory, but it's never been a huge priority for me, simply because we use the structural approach of hiding those with modules.

[Jacob Ras]

Would https://github.com/Kotlin/binary-compatibility-validator have shown the issue of those tables being unintentionally exposed? If so, would you recommend using the validator or expliticApi, or both?

[François]

The issue is mainly about on the OBJC/iOS performance side not the JVM side

[Jacob Ras]

I understand @François, I so my question is if the JVM validator would also expose these issues (as it shows what's public, and that's what goes into the Obj-C/iOS mapper, right?)

[Bradleycorn]

@kpgalligan @François - Circling back to my original post yesterday ... I found a thread in #C3PQML5NU from back in March where someone else had the exact same problem, and found a workaround to fix it.

Basically, when doing direct integration (a build phase script to run the embedAndSignAppleFrameworkForXcode gradle task), something doesn't work right and some files that xcode uses for indexing don't wind up in the right place. The work around is to add some additional code to that build phase script to "manually" copy the appropriate files to the right place. It looks like this:

cd "$SRCROOT/.."
./gradlew :shared:embedAndSignAppleFrameworkForXcode

DERIVED_DATA_DIR=$(echo "${TARGET_BUILD_DIR}" | awk -F'/Build/' '{print $1}')

INDEXER_DATA_DIR=${DERIVED_DATA_DIR}/Index.noindex/Build/Products/Debug-$PLATFORM_NAME
mkdir -p $INDEXER_DATA_DIR
cp -R shared/build/xcode-frameworks/$CONFIGURATION/$SDK_NAME/* ${INDEXER_DATA_DIR}

Here's a link to the old thread:
https://kotlinlang.slack.com/archives/C3PQML5NU/p1709811731499599