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?

Good question! I was looking for the answer to this question too. Have you found any examples of the point 3 (separate projects)?

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

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.

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.

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

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.

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

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

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

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!

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

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.

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

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