Thanks Summers Pittman for the write up. Very valuable info. Some questions to help me understand some of the problems with this approach:

For starters, it means that we will have to maintain binding libraries of our SDKs. This means that our SDKs and the dependencies we choose to use will be limited to what we can support in Xamarin. For instance our push libraries will be limited to the supported version of push that Xamarin's binding supports, the Android support libraries will be limited to what Xamarin supports, etc.

So this means if our native library use a third-party lib A, in order to make it work for Xamarin, we will HAVE to make sure Xamarin actually supports lib A as well. Otherwise we might have to create another binding for lib A. In other words, if we go down this road, we HAVE to always think about what is supported by Xamarin when we make changes to our native SDK. Is that right?

Taking this further down the road it means that in order to make any change in Xamarin we will also need to move those changes into the iOS and Android code bases. This creates a situation where we need multiple PRs, synchronization across multiple projects, and multiple experts to write, test, review, etc. It is a VERY hard thing to do if we want our SDKs to be usable by the Native platforms outside of Xamarin.

Why do we need to make changes in Xamarin? Is there much code in the binding project? I thought all the changes just need to be made in the native libs, and then maybe update the binding project to reflect the changes?