The best way I've seen this work (inside Google Apps) is to write shared business-logic in a common layer (here it (often) gets written in Java, then transpiled to Obj->C and Javascript, other teams go from C++ -> Java & JS, and other other teams embed JS inside of everything.. and other other other teams write everything in a native language (there is no one single way at Google))

then use a data-definition-language (like protobuffers) to define a bridge from inside of transpiled code land to your native layer, and compile native language bindings for your UI to read & write data models.

then stack a mechanism like GRPC which takes the DDL to the next level and makes services a declarative, language agnostic definition... and compile your service stubs for each platform.

...then write the UI in a native layer for each platform, using the native service stubs and data models compiled from your DDL.

Once you start trying to abstract the UI models between iOS, Android, and web you are stuck with a shitty status quo solution that leads to terrible hacks or boring concessions that ignore platform differences.

However abstracting the common (non-ui) mechanisms like asynchronous data structures, sockets, and storage is a relatively solved problem.