hey all, I have a multiplatform project that is ma...

# multiplatform

[Jon Bailey]

hey all, I have a multiplatform project that is made up of multiple modules. There is one called "networking" and one called "shared", shared depends on networking. I have some functions in networking that are public so they can be accessed in shared. is there a way to make them non public for the resulting shared library so they can't be access from the android and ios apps?

[Adam S]

perhaps you’re looking for a custom OptIn annotation?

https://kotlinlang.org/docs/opt-in-requirements.html#require-opt-in-for-api

it won’t make elements private, but it’s the closest thing I can think of. It’s used in a lot of JetBrains libraries.

[mbonnin]

If you make network an implementation dependency of shared it shouldn't be visible from your iOS and Android apps

[Landry Norris]

The message above is good if there’s nothing in network that you want to expose to the app.

[Casey Brooks]

Alternatively, keep it as an api dependency, but mark everything internal in your :network module that you don’t want accessible in :shared or your app projects

[Landry Norris]

I don’t know if there’s a way to do this in Gradle, but the command line compiler has a ‘friend-module’ field.

[Jon Bailey]

@mbonnin the problem with that is there are some types in networking that need to be visible in the app, eg some types that are returned by the functions, that get passed through logic to the apps

[Casey Brooks]

ignore my comment, I ddn’t read the question closely enough 😅

[mbonnin]

@Jon Bailey Ah oh well sounds like you need more modules then 😅 networking-api and networking-impl (or so, don't trust me on naming)

[mbonnin]

Or else the @OptIn annotation from @Adam S would work too if you enable it module wide on shared , it's just more work to maintain these annotations

[Jon Bailey]

ah I was hoping to avoid that because then it gets chaotic as I have more modules, would the OptIn work hiding things to ObjC?

[Landry Norris]

If the netwprk/shared modules are in the same repo, I’m almost certain that internal things are accessible to anything in the same project, even across modules.

[Jon Bailey]

@Landry Norris do you have a link to more info on the friend-module thing?

[mbonnin]

If the netwprk/shared modules are in the same repo, I’m almost certain that internal things are accessible to anything in the same project, even across modules.

Nope, internal is "accessible in the same module only"

[Landry Norris]

Just marked a class in foo module as internal in a project I have open, and it’s accessible in bar module.

Edit: AS as usual takes forever to process changes

[Casey Brooks]

internal acts like public within a single gradle module, but is private to others that depend on it

[mbonnin]

doc is quite clear about it:

If you mark it as internal, it will be visible everywhere in the same module.

[mbonnin]

Unless you're dealing with some Java interop stuff/reflection

[Landry Norris]

Looks like I was wrong. Just took a minute for AS to recognize the change.

[mbonnin]

ah I was hoping to avoid that because then it gets chaotic as I have more modules, would the OptIn work hiding things to ObjC?

Not sure about ObjC. @OptIn is read by the Kotlin compiler so the Swift compiler might very well ignore it

[Jon Bailey]

Also with OptIn it would still be visible to the Android app, you'd just have to explicitly opt in to use it?

[mbonnin]

Yea you can't prevent users to opt-in

[Landry Norris]

Can’t find any real docs on the friend module. Looks like it’s K/N only. Found this in the kotlinc-native compiler help output, but I haven’t done any testing with it.

-friend-modules <path>     Paths to friend modules

[mbonnin]

But same with modules, you can't prevent anyone to add implementation(project("network-impl")) to your android App (saying this to play the devil's advocate, I'm still pretty convinced multiple modules is the good solution for you)

[Jon Bailey]

I think that more modules looks like the best way (or move everything into one module 😞), but that would still be difficult for internal functions on public types

[mkrussel]

OptIn is not enforced from Objective-C. Kotlin 1.8 added HiddenFromObjC that you can also use.

[mbonnin]

internal functions on public types

This way is "easy". You can have public types in internal functions signatures. The other way is not possible (public functions exposing internal types)