Would you have to write it all in C, as that's the lowest common denominator for stuff that can be used in both swift and kotlin? Or are there other alternatives?
Doing some MVVM-style solution where you share the model and view-model layers is probably the type of architecture you would want to go with, having both view layers merely subscribing to an abstract description of the view state living in the view-model and sending up commands to manipulate the view state.
As for being viable - it's certainly doable, but the technology is still a bit rough around the edges, and it's not at all certain that it's going to be worth the effort.
I’ll speak from the swift side, it’s improving a lot, but we’re still in a bit of a transitional phase.
With a swift package, you can include cpp libraries but still need an obj-c bridging layer, but afaik swift is becoming better at interoperability, but we maintain a few versions behind swift bleeding edge.
Android are also able to add their own stuff to the repos to make it work. So we basically have a mobile repo that can work for ios and android, pulling in cpp binaries as submodules
Frontend web dev essentially had no concept of architecture, it was all code behind IME.
No, though i’ll admit it can be easy to get sucked into, bit that’s true for any platform, there are plenty of strategies to avoid this, mvc with uikit and swiftui further improves.
Just setting up test targets can mitigate this kind of thinking
Kotlin Native is another option that still allows native UI on the iOS side.
Certainly more difficult than Flutter or RN, but if truly native UI is a goal I think it, along with Kotlin Multiplatform, are the best options
https://github.com/ankidroid/Anki-Android-Backend => https://github.com/ankidroid/anki/tree/9f2920a063e9177cce082...
Again - not a mobile dev - but my spidey senses tingle when I see "cross platform UI". Feels like it won't go well, that different platforms have different conventions, that the abstraction layer will leak like a sieve, etc.