Though it's somewhat dated and C# oriented, the really, really fantastic Framework Design Guidelines by Brad Abrams and Krzysztof Cwalina is a thoughtful treatise on designing usable APIs. A lot of the things I read in there still resonate with me almost a decade later.

https://www.amazon.co.uk/Framework-Design-Guidelines-Convent...

Hi, I am not affiliated with Xamarin but I have been using Xamarin in production for the last two years on many applications and could not imagine doing native development in any other way.

Two weeks ago a enterprise company that previously was "iPhone/iPad only" from the top-down by a board level mandate has started seriously considering moving over to Android for purely handset cost reasons. I knew this would eventually happen and deliberately designed/developed the application using the Xamarin platform as a way to reduce risk/hedge bets.

If the application was not developed using Xamarin then the enterprise company would be facing a complete rewrite of the application in another language whereby the engineering costs to achieve this outcome would outweigh the savings and re-implementing the functionality would introduce substantial product quality/project risks.

Now "all that is required" is to start work on a Android user experience, implement it and then sew it up against the core library. It also means that developers can concurrently patch bugs + ship features to both platforms during the migration phase.

Anyway there seems to be a quite of bit of confusion that Xamarin.Forms == Xamarin and this is not the case.

Xamarin.Forms is a package that runs on top of the Xamarin platform that provides a DSL to rapidly create CRUD enterprise applications that spits out the equivalent native user interface implementation depending on which platform you run on. It is extendable and becoming highly customizable. Can't wait until they drop the "sealed" modifiers - hint, hint, nudge, nudge @natfriedman!

Xamarin itself is a way to use either F# or C# on Android and iOS. All of the native platform specific API's you're used are available to you to use in any way you see fit. Admitely the there has been some minor naming changes to be in accordance with the http://www.amazon.com/Framework-Design-Guidelines-Convention... but if your coming from a .NET background then it makes complete sense.

That said if you're coming directly from .NET, thinking that you can ship iOS or Android without learning the domain knowledge of each platform then you're in for a royally rude awakening. Xamarin does not abstract away the differences between the platforms - ie. push notifications, application suspension or any of that jazz.

With the correct software architecture you can write your business logic, data transport, caching and persistence layer once and share it between every non-web platform in existence - Android, iOS, Windows Phone and desktop applications on Linux, Mac & Windows/WPF/Store.

Step one in decent architecture is to divide your application up into a Core library and use interfaces to bait and switch in a different concrete implementation depending on what platform is running your application. For more info see: http://log.paulbetts.org/the-bait-and-switch-pcl-trick/

Step two is to use a solid MVVM framework such as http://reactiveui.net which is a functional reactive programming framework that uses the Reactive Extensions for .NET to create elegant, testable User Interfaces that run on any mobile or desktop platform. Supports Xamarin.iOS, Xamarin.Android, Xamarin.Mac, WPF, Windows Forms, Windows Phone 8 and Windows Store apps. It is the framework that powers GitHub for Windows and various other undisclosed projects ;-)

Step three is to architect your network services and data persistence exactly as detailed here: http://arteksoftware.com/resilient-network-services-with-xam...

For more information on the above see https://www.youtube.com/watch?v=voa44OHBKME - "Writing Mobile Apps the Github Way by Paul Betts"

(disclaimer: contributor to the ReactiveUI project ;-)

Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (2nd Edition) http://www.amazon.com/Framework-Design-Guidelines-Convention... is an interesting read and contains the result of actual work on building a large and successful framework. Has information on exceptions, naming, extensibility, and common patterns.