Just gave an 1h 20m presentation to our head office advocating a K/MP strategy for the future of our product... 🤞fingers crossed!

I have to do the same. Any tips?

I can't tell if it was successful yet so I can't vouch for the tips 😉 But strong points I identified were... that much of the work we would do to transition our (large, mature, Java code-base) to Kotlin Multi-platform would have numerous added benefits due to the language safety; and the Unit Testability would increase due to moving from MVC to MVP (Passive View).

Why MVP and not MVVM?

Thanks, this is worth considering... The reason for MVP: It's familiar to our team, simple, supports Unit Testing very well (via test 'View' implementation) and also lends itself well to representing User Interactions as suspending functions in the View Contract.

But if you go the MVVM route you can actually reduce the code in the view much more and allow for even micro updates based on observers. Keeping your code incredibly clean in the view. all you will do is get a reference from your view model, then listen to observers from it. The other advantage is that you can use multiple VM’s based on components if you wish. Treating them like use cases for a view, but this isnt as popular, although it is possible. Testing of the VM is incredibly easy also. There is no real mocking of interfaces out of the VM. You can assert observers are being called when an action is performed on the VM. So, in essence. • With MVP you will create a View, Interface for View and Presenter, and Presenter. • With MVVM you will have a View and a View Model. MVVM is the current architectural approach of Android, so you will gain a massive advantage by using the components that they provide. We have a full system built on MVP, but turning those views into standalone components isn’t as clear cut as it is with the MVVM model. These are just a subset of reasons.

@Sean Keane Thanks for the info and inspiration to look into it more deeply.

representing User Interactions as suspending functions in the View Contract.

Kotlin suspend functions are not visible from Swift code. So keep in mind that suspend functions need to stay in the Kotlin part.

@Thomas Right, but we're intending to write iOS in 100% Kotlin - which is possible, right down to the

AppDelegate

and

main

functions.

That will work fine, too. The reason I went with Kotlin and Swift is so you can easily use (Apple's) Swift frameworks. For example the new SwiftUI can not be used from Kotlin, unfortunately.