Hi Everyone, I have a question about sharing viewm...

# multiplatform

[Bohdan]

Hi Everyone,
I have a question about sharing viewmodels. We have quite big project - around 60-70 screens and a lot of features (offline mode, using camera, recording audio, billing, synchronization between server and other devices etc).In general I would say that it is typical client but quite massive. In some point we decided to rewrite it fully using kmm(Android + iOS). So after some research we rewrote one module with kmm and it worked fine - we even shared viewmodels in our prototype. But it is a small module for 5 screens.My question is rather a search for advice.
Has anyone had experience writing a large project with kmm and shared viewmodels? Maybe someone has faced some specific issues while sharing viewmodels. On what put more attention?
Probably viewmodels are not yet ready to be shared or it not worth it. In general possibility to share viewmodels looks quite appealing. But as this is our first project with kmm and quite big we would like to be sure that it is good idea.
Thanks in advance for the reply.

[darkmoon_uk]

Hi Bodhan. I have released a commercial App in which we shared ViewModels between Android and iOS. Technically, the use of KMM was successful 🎉 (happy to answer any questions about this) but from a human perspective, there are things I would do differently next time.

In particular; iOS developers did not like being told they had to write logic in Kotlin rather than Swift, and that almost certainly contributed to one of them leaving the company. Consider all your developers' individual appetites to up-skill or adopt KMM. My learned advice would be let such tech adoptions be a team decision, make your best case for KMM be open to the possibility that's it's not the right tool to use.

If going ahead; identify mini 'quality gate' PoC's that can be built to prove to the team that the KMM tech stack will support your intended use cases, then (this is most important) let the team implement those PoC's to feel the feasibility for themselves.

At the end of the day if you're coercing a team to adopt something they don't want to; you will become the go-to guy for all problems, and ultimately the target of 'blame' if things don't go as expected. You don't want to be in that position, trust me.

This may not the case in your scenario; since it sounds like your team already have comfort with Kotlin.

[matej]

@darkmoon_uk I second the notion of getting the team on-board with the idea, before making any sweeping changes to their development process. We've also had friction on the iOS side around writing all of the logic in Kotlin, but thankfully it has resolved itself over time. You certainly don't want to have half or more (ideally none) of your iOS developers be pissed off at you for making them write Kotlin, but I think isolated disagreements on the topic shouldn't prevent you from implementing it as a team. At the end of the day, a great developer has to be open minded enough to try new things in my opinion, and KMM is not a giant leap like Xamarin or ReactNative. The software that we write, for most of us, is going to outlive our tenures at whatever company we're working at. I would argue for using "the best tool for the job", and if there's a radical mismatch between "best tool for the job" and an individual's "favorite tool for the job", it's a natural thing if they decide they'd rather work someplace else, on something else - that's OK. This depends on your recruiting pool and job market of course, so take this with a grain of salt.

[darkmoon_uk]

@matej Agreed; there are many variations on the scenario. In my case the project started with just me and one other developer; who were both satisfied and enthusiastic to use KMM, but the project quickly grew in size and scope with the demand that we take on more developers.

Without a ready supply of KMM experts in our local market (is there in any market?); we of course hoped that native developers from both platforms would adapt, which they did - albeit to varying degrees.

This could have been better with more care to those devs experience of on-boarding - they weren't informed well enough about the learning curve they would face until it was too late (for the unwilling); but at that moment we were already in full build phase on a limited budget; no time to pause to design and lead a whole new on-boarding process.

Still there is more I/we could have done - you live and learn. The KMM-based Apps were launched successfully and continue to be developed; but the team chose to go full native for the second App, which will lead to some missed opportunities in my view.