Using floating point literals with platform.CoreGraphics.CGFloat

I’m trying to use the CGRectMake API from platform.CoreGraphics within an actual class in my iosMain. It requires CGFloat instead of floating point literals(FPL). When I use FPLs I get the error: the floating-point literal does not conform to the expected type CGFloat.

The problem is that not only does there not seem to be a bridge between scalar types from Kotlin to ObjC, but also that there isn’t even a way to create a CGFloat value, since CGFloat (as defined in platform.CoreGraphics) does not have any constructors. Calling: val x = CGFloat(5.0) results in error: Expected class CGFloat does not have default constructor.

I’ve looked at sample code here, and I’m not sure how they’ve gotten it to work.

Is there something I’m missing in order to get Kotlin Float to play nice with CGFloat?

Hello, @MattMur!
Could you please share the code snippet? Also, how are you declaring the iOS target?

Sure! image attached as well.
val rect = CGRectMake(5.0, 14.0, 12.0, 23.1)

I am using kotlin.mpp.enableGranularSourceSetsMetadata=true, kotlin.native.enableDependencyPropagation=false and custom iOS targets since I need the arm32 architecture for my exported framework. I found that these settings allowed for this. I create the targets like this:

    val ios32 = iosArm32()
    val ios64 = iosArm64()
    val iosSim = iosX64()
    configure(listOf(ios32, ios64, iosSim)) {
        binaries.framework {
            baseName = "Core"
        }
    }

My iOS source set looks like this:

    val iosArm32Main by getting
    val iosArm64Main by getting
    val iosX64Main by getting
    val iosMain by creating {
        dependsOn(commonMain)
        iosArm32Main.dependsOn(this)
        iosArm64Main.dependsOn(this)
        iosX64Main.dependsOn(this)
        dependencies {
            implementation("io.ktor:ktor-client-ios:$ktorVersion")
        }
    }

@Artyom.Degtyarev Interestingly if I simply remove iosArm32Main.dependsOn(this) from my iosMain source set, everything works…

Obviously that shouldn’t be the solution, as I need this architecture slice. Is this a bug with KMM?

I’ve answered in the https://youtrack.jetbrains.com/issue/KT-49232, sorry for a long silence.
Just for the record: this is a Commonizer bug, as a workaround one should use separate source sets for 32- and 64-bit platforms. This does not affect the result frameworks(right now your Gradle script should generate several independent frameworks), and should not affect the ability to make an XCFramework or a far framework from them.

1 Like