Excellent Points, this is where the answer is "it depends".

> What do you put in the common core? Android does HTTP requests one way. iOS does them another way. You go for the lowest common denominator an implement a third way, using libcurl or something?

If it's really functionality that cannot reasonable be shared don't share it.

It's probably more work to maintain bindings to a single API client in the core and fiddle with all the details of not using the native HTTP client implementations that it is to implement the API client twice.

Writing the API client twice is boring, but that's a good thing.

> Or do you just put business logic in the common core? Is there really that much business logic that doesn't issue requests or access a database?

The shared core is optional. You might have the need for it, then it's a good solution.

For an app like snapchat you'd probably share the video effects and have that in your core library.

That's perfectly reasonable but, at that point, the argument becomes: build 95% natively and maybe there's a 5% "core" that warrants extracting into a common lib. Technically? That's excellent architecture. In terms of saving development time — which is where stuff like React Native comes in? Not so much.