# Publishing Kotlin Multiplatform Swift Packages Using Google Cloud Storage and Cloud Run

DevFeed: [Publishing Kotlin Multiplatform Swift Packages Using Google Cloud Storage and Cloud Run](<https://devfeed.tech/articles/publishing-kotlin-multiplatform-swift-packages-using-google-cloud-storage-and-cloud-run-23879.md>)

Original publisher: [Read original article](<https://engineering.premise.com/publishing-kotlin-multiplatform-swift-packages-to-google-cloud-storage-be5c6987e5d?source=rss----c5fada0a103d---4>)

Author: Nate Ebel

Published: 2023-10-18T05:28:28Z

Content type: tutorial

Language: en

Sources: [Engineering at Premise - Medium](<https://devfeed.tech/sources/engineering-at-premise-medium.md>)

Topics: [Kotlin Multiplatform](<https://devfeed.tech/topics/kotlin-multiplatform.md>), [Cloud Run](<https://devfeed.tech/topics/cloud-run.md>), [Gradle](<https://devfeed.tech/topics/gradle.md>), [iOS](<https://devfeed.tech/topics/ios.md>), [kotlin-multiplatform-libraries](<https://devfeed.tech/topics/kotlin-multiplatform-libraries.md>), [Swift](<https://devfeed.tech/topics/swift.md>), [Cloud](<https://devfeed.tech/topics/cloud.md>)

Tags: [cloud](<https://devfeed.tech/tags/cloud.md>), [cloud-run](<https://devfeed.tech/tags/cloud-run.md>), [github](<https://devfeed.tech/tags/github.md>), [google-cloud-platform](<https://devfeed.tech/tags/google-cloud-platform.md>), [google-cloud-run](<https://devfeed.tech/tags/google-cloud-run.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [ios](<https://devfeed.tech/tags/ios.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [kotlin-multiplatform](<https://devfeed.tech/tags/kotlin-multiplatform.md>), [kotlin-multiplatform-libraries](<https://devfeed.tech/tags/kotlin-multiplatform-libraries.md>), [mobile-app-development](<https://devfeed.tech/tags/mobile-app-development.md>), [multiplatform](<https://devfeed.tech/tags/multiplatform.md>), [swift](<https://devfeed.tech/tags/swift.md>)

## AI overview

This tutorial describes Premise's approach to publishing and consuming Kotlin Multiplatform Swift Packages. It uses a custom Gradle plugin to publish XCFrameworks to Google Cloud Storage and a Cloud Run service to download the Swift Package binaries requested by Xcode, reducing the need to store large binaries in GitHub.

## Source excerpt

By Nate Ebel, Android developer In this post, we'll detail our solution for publishing, and consuming, Kotlin Multiplatform Swift Packages. Our solution leverages a custom Gradle plugin publishing XCFrameworks to Google Cloud Storage and a Google Cloud Run service to download Swift Package binaries requested by XCode. With this solution in place, we've been able to more efficiently serve multiple Kotlin Multiplatform libraries to our iOS application. This is a part of an ongoing series on our usage of Kotlin Multiplatform at Premise: Part 1: Kotlin Multiplatform at Premise Part 2: Kotlin Multiplatform Project Structure for Integrating with Brownfield Applications Part 3: Building a CI Pipeline for Kotlin Multiplatform Mobile Using GitHub Actions Part 4: Publishing Kotlin Multiplatform Swift Packages Using Google Cloud Storage and Cloud Run -- This Post Part 5: Generating BuildConfig Files for a Kotlin Multiplatform Library -- Coming Soon Part 6: Optimizing Local Build Times for Kotlin Multiplatform Mobile Projects -- Coming Soon Premise and Kotlin Multiplatform Swift Packages We've been using Kotlin Multiplatform in production since early 2021 in the form of our mobile-shared project. During that time, we've consumed our shared code as a Swift Package within our iOS application. The integration of that Swift Package has gone through several iterations. v1: Use the multiplatform-swiftpackage plugin to build the Swift Package and store the XCFramework binary in GitHub v2: Use our own custom Gradle plugin to build the Swift Package and store the XCFramework binary in GitHub These two solutions were very similar. Build the XCFramework. Generate the Package.swiftfile. Check both into git with the desired version tag. These approaches worked fine for a while, but eventually we started to pay the price for our simple initial solution. An XCFramework binary can be pretty large. Ours were in the ballpark of 100MB. So checking 2-3 of these into each commit (1 for each iOS archit