Did you try doing native development with Xamarin? I do want to be clear that Xamarin.Forms is not Xamarin. It's a library that we built to help people quickly write very simple, data-entry style apps. That's why it's called "Forms." It's not intended to be highly performant or to replicate all the per-platform APIs in Xamarin.iOS and Xamarin.Android. For that, you should use the native APIs. We have a little more information about that here:

http://cdn1.xamarin.com/Architecture%20Selector.pdf

And the "What Xamarin approach is right for you?" section on the Xamarin.Forms page:

http://xamarin.com/forms

Before release, we had internally called Xamarin.Forms "duplo," to emphasize that it was for childishly-simple apps and screens, but we couldn't use that (trademarked) name for the release, unfortunately.

That said, of course we still want to address all the issues that you found with Forms. Would you mind dropping me an email - [email protected]?

From my experience, xamarin take wrong UI improvement strategy

Dont get me wrong, this is a good product, i love it, but just going to wrong direction

This is the big 2 mistakes:

1. You change the API class and method name to .net version

For first time user, this is good approach, but i must rename every sample snippet code from stackoverflow

You should save the resource for renaming API to something else more valueble ( hint : fixbug )

Are you rename the API because of patent and legal issue?

2. Xamarin form

This is the worst strategy.

Maybe this is good for B2B

And maybe B2B is good money

But for me, indie programmer, B2C product, i dont need xamarin form

I need best approach to use UI library

Stop xamarin form, there is other way to get 90 percent shared library

Support more on MVVM cross

Duplicate total of the xamarin component store

Improvement object sharpie to support UIKit.h

Object sharpie not working if using UI library

Android binding still design for eclipse project, not android studio

I'm wasting 1 week to bind ListViewAnimation android, and still not working

My point is, it really hard to bind UI library on xamarin

Conclusion,

Please please turn around and go back to your real core value.

We like native, improve native, do not recreate the UI component

You know what happend when you try recreate UI?

Go check java se and Qt

Changing the name is a necessity if you want to have a good looking program.

Consider an API like "drawString:" and "drawString:atPoint:" and "drawString:atPoint:withFont:". These are acceptable in the world of objective-c, because they are used with parameters, but they are not really suitable in this way in C#. So we map the API names to forms that are idiomatically correct in C#.

In the above case, we would like map those to a single "DrawString" method name with three different overloads. But this depends on the case. In general, we follow the .NET Framework Design Guidelines for our naming conventions.

As for forms, you are correct, we built it for a class of users that had different requirements than those that are building consumer applications.

Now, while I am the first one to tell developers to use our native APIs to create great consumer experiences, just last week I ran into a gorgeous looking app and only later I discovered that the gorgeous UI was actually built entirely with Forms, even the animations.

More importantly, the app was built on record time by a single developer. I could not believe it (need to ask the customer for permission to disclose that their product is built with our product).

So I walked away with a new insight: that good UIs require good taste and someone passionate enough to make the UIs happen and that even something that we intended for mostly business scenarios can create great UI experiences.

thx for responding my comment. after read your explanation, i agree with your argument about xamarin form. it just need more feature and more sample. Xamarin sample layout is not esthetic. You should look at telerik example. And last one, when feature listview drag and drop swap row available on android ?

thx

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 ;-)

Why do you say "cross-platform" isn't a real problem? It sure seems to me like mobile app developers need a way to share large chunks of their code, and possibly even some UI code, between platforms while still delivering native apps.