Hey there! In our project, I noticed that classes ...

# multiplatform

[Marc Reichelt]

Hey there! In our project, I noticed that classes like com.foo.SomeClass will be exported in iOS with Swift names SomeClass . If our module exports a lot of those, and all the swift files import the module with import SharedCode , there might be some conflicting Swift classes or classes from other libraries.

Does anyone have a good solution for this? Something like a namespace, or exporting multiple swift packages, or other approaches?

[ade]

I don't think there's a good solution for this, as long as the ios compilation relies on objectivec. One approach, though not great (and I havent really tried it), could be to not set the export flag in the builscript for a module, lets call it moduleX. All classnames will then be prefixed like e.g. modulexSomeClass

But the best approach is probably to make as much stuff internal/private as possible and for potentially conflicting names use a short manual prefix in the class name e.g. XySomeClass

[ade]

The docs currently say

"Objective-C does not support packages in a framework. Thus, the Kotlin compiler renames Kotlin classes which have the same name but different package in the same framework. This algorithm is not stable yet and can change between Kotlin releases. As a workaround, you can rename the conflicting Kotlin classes in the framework."

[Marc Reichelt]

Oh, nice - I didn’t know that we can do that (with the moduleXSomeClass names)!
The other thing I did know already was that classes named foo.Yay and bar.Yay will have different names on iOS (I think the second one will become Yay_ as of now).

I think what I want is something like namespaces, which Roman Elizerov mentioned a while ago here:

https://youtu.be/0FF19HJDqMo?t=617▾

But since they are not available yet, I think what we should do right now is:
• be careful with public types in the multiplatform lib
◦ maybe even use the ‘Explicit API mode’ of Kotlin, to enforce developers to choose public/internal visibility
• reduce multiplatform API whenever possible
• prefix classes that have pretty common names with something
• maybe wrap some code in object SomeFeature { /* ... */ } if possible

[ade]

All good ideas, also relating to the last point, sealed classes subclasses appear to get concatenated names with their supertype, which is useful in this context