To answer myself ☝️ , the issue is not sealed classes I believe but rather that

kotlinNothing

is not a sub-type of

NSString

. However, the situation above is an implementation of how this article suggests dealing with serializing nullable and optional properties which I think is overengineered. Instead of using the sealed class to represent the three states present-with-value, present-with-null-value, and not-present you can instead have a

data class OptionalProperty<T>(val value: T)

and use it as a nullable property type and still cover all the states. It works as before, but is now much more pleasant to use from swift. But please correct me if I’m wrong.

do you mean

data class OptionalProperty<T>(val value: T?)

? otherwise, I’m struggling a bit with understanding 🙂 but I think you’re right that you can distinguish the cases with that solution. As in,

val missing: OptionalProperty<String>? = null
val presentNull: OptionalProperty<String>? = OptionalProperty(null)
val present: OptionalProperty<String>? = OptionalProperty("foo")

I think you got it! 🙂 either

T

may be nullable or you can use it like

val presentNull: OptionalProperty<String?>? = OptionalProperty(null)

. Potato, tomato 🙂 Is anything else unclear? Also, a custom serializer is still needed as explained in the linked article (somewhat changed tho)

i think i prefer ‘potato’/`T?` 🙂 in the sense that the

OptionalProperty

wrapper doesn’t seem meaningful unless the wrapped property can be null. Also, I think I prefer this version to the sealed classes one. I have a feeling that I saw somewhere some Swift code that used double-optionality (

T??

), but that doesn’t seem to work in Kotlin. Also, not quite sure that I remember right.