Hi, everyone! I want to discuss how the multiplatf...

# multiplatform

[dambakk]

Hi, everyone! I want to discuss how the multiplatform project relates to the native (in my case; android and ios) projects. As I see it there are three approaches:
• Keep everything in the same repo. Pros: everything in the same place. Cons: Messy git history or use of git submodules.
• Keep the android and common project in the same project. Pros: Easy android integration and debugging. Easy to pack and inject an ios framework. Cons: Debugging from ios? Common project “owned” by the android project (higher threshold for ios devs to contribute to the project)
• Three separate projects. Pros: Clean separation, non-android driven. Cons: Debugging? 
Tl;dr: What is the recommended way of structuring such a multiplatform project? The code labs and examples I’ve seen choose different approaches. And while we’re at it, what is the best way for ios devs to debug the common code?

[rsetkus]

Good question! I was looking for the answer to this question too.

Have you found any examples of the point 3 (separate projects)?

[Kris Wong]

IMHO separate projects is the only scalable structure. but you can evolve to that if one of the others is easier to get started.

[Kris Wong]

as for debugging from iOS, there's a plugin for Xcode to assist, and an upcoming AS version will support running iOS apps

[dambakk]

Thanks!
Not that I can remember right now, but my feeling is that it is the cleanest and most scalable approach, but probably the one with the most hassle and hardest to debug.
I agree, Kris, and I think we will go for that to begin with.

[dambakk]

Ok, my ios devs were sceptic to use a plugin for xcode (apple has removed support or something?), but we’ll wait for the AS version i guess

[dambakk]

Anyone who uses MP in production that can share their approach and experiences with that?

[Sam]

It isn't really a plugin in the classical Xcode definition of a plugin. It's more like a set of config files that allow Xcode to know more about Kotlin.

[dambakk]

Ok, I see, I will run it by him again tomorrow. Thanks!

[Sam]

My 2 cents on the repo layout. I went with a mono repo because I wanted less friction for making code changes. If a developer has to make two PRs for one feature change, it creates friction. You'll want the iOS developers invested in the shared module. Otherwise the Android devs will go off and write something that looks and works well on Android but will not be comfortable for the iOS developers to use.

[Kris Wong]

I would also say that each library project that you have needs to have a clear and concise purpose

[dambakk]

That sounds reasonable. It is very important for us that the ios devs are equally invested in the common code as the android devs. And, as you say, one PR per feature decreases friction and welcomes the ios devs. I am, however, worried that the version control will be messy. How did you solve this? Do you use git submodules, or do you simply use git as in any other repo? @Sam

[Sam]

Its just a single repo with the basic git flow layout.

[Sam]

Any release is tagged with the platform name and version so that the platforms don't have to always release at the same time.

[dambakk]

Ok, thanks for sharing, it is very useful for us! And if anyone else reads this I would also like to hear about your experiences and choices!

[russhwolf]

There was some discussion about this at KotlinConf from Ben Asher and Alec Strong:

https://youtu.be/je8aqW48JiA?t=1865▾

[spierce7]

it seems like the solution with the least friction is clearly the mono-repo approach. I think the real goal is one team building the app in one repo, and having it build for multiple platforms. When you have a separation of teams where one team is responsible for all of the shared logic, I don’t think that’s a recipe for long-term success.

[Kris Wong]

we have that structure at vmware - only it's multiple SDK teams and multiple app teams

[Kris Wong]

however, our apps group is probably much larger than most companies

[dambakk]

We will also go for the mono repo approach, least friction 👍

[dambakk]

And thanks for all the feedback, guys! Very helpful!