I was looking to develop a crossplatform sdk in Ko...

# multiplatform

[Ayush Upadhyay]

I was looking to develop a crossplatform sdk in Kotlin MultiPlatform such that buisness logic is written in kotlin but Ui is implemented separately for every that is swift, android , flutter , react native. Can any one guide me about its feasibility and any other projects which already exists doing this

[hfhbd]

You don’t need a sdk, just split your project into multiple Gradle modules.

[Skaldebane]

@hfhbd I think he meant that his goal is building an SDK lib with UI components for all major UI toolkits, but he wanted to benefit from KMP's code sharing for the business logic of that SDK.

[Ayush Upadhyay]

yes that's what I meant

[Skaldebane]

I'm not sure if there's any projects doing this, but I'd see that you'll face hurdles to setup Gradle properly, and then with exporting (and publishing) the SDK for each platform. On the Swift side, this looks very doable, probably well supported by KMP out-of-the-box.
As for React Native, maybe you could target Kotlin/JS (or Wasm) for that? (no clue)
For Flutter, you'll probably want to wrap the Android/Swift libraries under-the-hood (and also the Wasm library if targeting web too).

[Skaldebane]

I'm just taking some wild guesses, "technically" and "theoretically" speaking this should be possible, but in practice... I'm not quite sure.

[Ayush Upadhyay]

project-name-sdk-project/
├── project-name-core/
│ ├── src/
│ │ ├── commonMain/
│ │ │ └── kotlin/
│ │ │ └── com/project-name/core/
│ │ │ ├── ProjectName.kt
│ │ │ └── ProjectNamePlatform.kt
│ │ ├── androidMain/
│ │ │ └── kotlin/
│ │ │ └── com/project-name/core/
│ │ │ └── ProjectNamePlatform.kt
│ │ └── iosMain/
│ │ └── kotlin/
│ │ └── com/project-name/core/
│ │ └── ProjectNamePlatform.kt
│ └── build.gradle.kts
│
├── project-name-android/
│ ├── src/
│ │ └── main/
│ │ ├── kotlin/
│ │ │ └── com/project-name/android/
│ │ │ └── ProjectNameAndroid.kt
│ │ └── res/
│ └── build.gradle
│
├── project-name-android-ui/
│ ├── src/
│ │ └── main/
│ │ ├── kotlin/
│ │ │ └── com/project-name/android/ui/
│ │ │ ├── ProjectNameErrorDialog.kt
│ │ │ └── ProjectNamePerformanceView.kt
│ │ └── res/
│ └── build.gradle
│
├── project-name-ios/
│ ├── ProjectNameiOS/
│ │ ├── ProjectNameiOS.h
│ │ └── ProjectNameiOS.swift
│ └── ProjectNameiOS.xcodeproj
│
├── project-name-flutter/
│ ├── android/
│ │ └── src/
│ │ └── main/
│ │ └── kotlin/
│ │ └── com/project-name/flutter/
│ │ └── ProjectNameFlutterPlugin.kt
│ ├── ios/
│ │ └── Classes/
│ │ └── ProjectNameFlutterPlugin.swift
│ ├── lib/
│ │ └── project_name_flutter.dart
│ └── pubspec.yaml
│
├── project-name-react-native/
│ ├── android/
│ │ └── src/
│ │ └── main/
│ │ └── java/
│ │ └── com/project-name/reactnative/
│ │ └── ProjectNameReactNativeModule.kt
│ ├── ios/
│ │ └── ProjectNameReactNative.swift
│ ├── src/
│ │ └── index.ts
│ └── package.json
│
├── samples/
│ ├── android-sample/
│ ├── ios-sample/
│ ├── flutter-sample/
│ └── react-native-sample/
│
├── docs/
│ ├── getting-started.md
│ ├── android-guide.md
│ ├── ios-guide.md
│ ├── flutter-guide.md
│ └── react-native-guide.md
│
├── scripts/
│ ├── build.sh
│ └── test.sh
│
├── .gitignore
├── README.md
└── settings.gradle.kts

[Ayush Upadhyay]

this is what I am thinking to strucutre project as

[Skaldebane]

Ah, this seems to make sense if your target audience is Android and iOS apps.
I forgot that React Native is just like Flutter, and so you can simply depend on the Android/iOS libraries!

[Skaldebane]

I notice you have project-name-android and project-name-android-ui , if the non-UI one is just for logic, you don't need a separate subproject for it, just include it in the Android side of the shared KMP module.

[Skaldebane]

One extra note about React Native is that it also supports Web, and so you might want to add a jsMain target to the shared module to support that too.
Same for Flutter, but I think there it's primarily through WebAssembly, so you'll probably need to add wasmJsMain if you want to support web. Flutter also supports desktop, in that case a jvmMain (without Android specifics) would be useful (and since androidMain depends on jvmMain , you could share the same code).

[hfhbd]

Just curios, why do you want to support all these frameworks? Do you want to reuse your code for your own application or do you want to write such library for others? If it’s for your own application, did you take a look at Compose multiplatform?

[Ayush Upadhyay]

So how overall do you think it is , is there any better way to do it other than this that you know of

[Ayush Upadhyay]

@hfhbd yes I am writting it provide as sdk so that people writing application in thier specific framework can use it

[Ayush Upadhyay]

@hfhbd its ios part is still in beta, so I was told not to use it, also we cannot render native ui elements in flutter

[Ayush Upadhyay]

as it draws its own implementations of ui elements on a blank canvas

[Skaldebane]

@Ayush Upadhyay This looks alright to me, but again, I'm not sure what practical implications would it have (e.g. SDK size, build times, etc...).

[Skaldebane]

Yeah Compose Multiplatform is a bad idea for an SDK, using KMP already makes me concerned about size, adding Compose will blow up the size of the library.

[Skaldebane]

(and is simply an unnecessary huge dependency added for a single SDK)

[Ayush Upadhyay]

@Skaldebane but I will be publishing individual part of package as sdk for different libraries so size problem is only for me not for users right?

[Skaldebane]

I'm concerned about size because writing in KMP means there will be a good amount of Kotlin-specific stuff (parts of stdlib and other libraries) that will take up more space than the equivalent native code, but I'm not sure how bad that would be (could be acceptable!).

[Skaldebane]

But yeah, if you have very complicated business logic, it might be totally worth it as a start, will save you lots of time and can take you quite far.

[Jokubas Trinkunas]

We had something similar, I suggest to create a KMP library with all the shared business logic, publish it, and add it as a dependency in Android / Xcode / etc. target projects, this way you have the logic shared across platforms, but the UI lives in separate projects

[Jokubas Trinkunas]

You can then either have a core SDK with only business logic and one with UI + logic

[Ayush Upadhyay]

@Jokubas Trinkunas out of these 3 which one did you use
• XCFramework: Kotlin Multiplatform framework is built as a XCFramework.
• CocoaPods Dependency Manager: Kotlin Multiplatform framework is built as a Framework with CocoaPods
spec file.
• Regular framework: Kotlin Multiplatform framework is built as a regular Apple framework for specified native
target.

[Jokubas Trinkunas]

XCFramework