Anyway, you will spend a LOT of time fixing Xamarin bugs and developer their controls.
However, I LOVED .net functions, especially LINQ !
Anyway, development was really slow and performance is no were near to native.
So if you want to deliver a simple app to a client and be cross platform, then sure. But don't try to maintain that app, you will regret it.
I'm afraid the whole Xamarin thing won't solve "cross-platform" which isn't a real problem but sure.
Its just another horse that Microsoft is betting on.
Oh and for the people that will have to do it anyway.
Use Resharper ! Xaml IntelliSense !!! It will help you a lot.
I'm sorry I'm so negative, but it was genuinely the worst development I had.
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:
And the "What Xamarin approach is right for you?" section on the Xamarin.Forms page:
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 - firstname.lastname@example.org?
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
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 ?
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.
I've been working for half a year with Xamarin Forms. I Think using Xamarin is the way to go, there is no need to re-code something for 3 different platforms when you can just have a shared codebase. Tools like Cordova and Phonegap don't work. They produce a very crappy experience that doesn't use the native OS functions, doesn't look and feel native, feels slow and has many bugs (for example they can't use the hardware back button).
So Xamarin can create real native apps, which is a HUGE advantage over Cordova/Phonegap/others, but there are also serious downsides:
1) It's BUGGY. Many components have bugs, and the code often behaves in very very weird ways (I had exceptions not being caught by catch blocks for example), many debugger functions don't work properly with mono (like locals) and very, very often exceptions are thrown without ANY indication what caused them or where they occurred exactly.
2) You a limited in the features you can use because it's a wrapper (as mentioned in OPs post).
3) Documentation sucks and is very limited. It's getting better (mostly because of StackOverflow), but it's still not sufficient.
4) It has XAML which is very nice combined with MVVM, but the XAML implementation sucks. It doesn't have intellisense and it's just generally very awkward.
I don't think the 'big cost' is a valid argument against Xamarin. If you can develop 1 app for $40k where you would normally have to develop 2 or 3 apps for $30k each, that's a BIG win and Xamarin's costs are negligible.
1) We aren't aware of any debugger issues like this. Is it possible you were debugging optimized code which had the local variables optimized away? Similarly, when an uncaught exception is thrown, it comes with a stack trace with line numbers. Were you not getting these?
2) Xamarin does map the entire set of iOS and Android APIs into C#, so yes it is a "wrapper," but you should NOT be limited in what native features you can use. We literally cover almost 100% of the entire set of native APIs. What limitations were you running into?
3) We have a ton of docs at http://developer.xamarin.com including nearly 300 sample apps and a lot of very detailed guides: http://developer.xamarin.com/guides/ Which part of the docs did you find inadequate?
4) We do include XAML intellisense in Xamarin Studio. To get it in Visual Studio you have to install an extension: http://www.cazzulino.com/mobileessentials.html This will be included by default in a future version of Xamarin.
I'm sorry about the trouble you had, and I'd like to get to the bottom of those issues. Please feel free to contact me at email@example.com.
There's also the fact that the bar is a bit lower to get an app finished and released with something like Ionic. So you might see more apps that aren't quite up to par, but that doesn't mean that it isn't possible to create something beautiful with them.
> They produce a very crappy experience that doesn't use the native OS functions, doesn't look and feel native, feels slow and has many bugs (for example they can't use the hardware back button)
Can you elaborate on what you mean here?
Sure, the apps never feel completely native but you can still invoke native features including the back button on Android, reuse the same code to make a web app and while bugs happen it isn't any worse than trying to create a cross-browser web app (which is essentially what you're writing).
Pretty much every software development choice is a trade off and PhoneGap is a good one sometimes.
> If you want an iOS, Android and web app as soon as possible with a decent UI on a limited budget,
Your chances of business/users/engagement success quickly dwindle if that's the rationale.
Your comment does bring up a good point however, I've struggled to prove any of this with any scientific manner. I wish there was, because it would selling native solutions so much easier. The only proof really is the fact that the most downloaded apps in the world all use native, and many (FB and LI come to my mind) tried the hybrid solution and it failed miserably.
 - http://www.nngroup.com/articles/response-times-3-important-l...
 - http://www.theverge.com/2012/8/23/3262782/facebook-for-ios-n...
 - http://venturebeat.com/2013/04/17/linkedin-mobile-web-breaku...
Obviously I'm not going to advocate apps that have 200ms delays no matter what framework you use. It's also possible to write laggy and bad native UIs as well.
Was the Facebook app really a failure that made the difference between 5000 and 1 million users? I think Facebook is an example of a company that has unlimited resources to throw at app development and can afford to spend a lot for even a little better anyways.
My only point is that writing native apps for multiple platforms does not come for free. While usually better than hybrid apps, the development costs need to be considered.
One well done app on a big platform may be much better than three decent/acceptable apps on three big platforms.
You need to consider that developing two native apps is probably twice the cost of developing one cross-platform app for two platforms.
I think developers are overly aware of the differences between native and non-native apps, and overestimate how much a casual app user cares about a native experience to be honest. I'd love to implement native experiences for all apps I write but I have to take budgets into account.
I would expect the opposite. They may not be able to put a name to the issues or even describe them, but I'd expect average people to show a clear preference for native apps basically every time in a side by side test.
I think developers tend to underestimate how important good UI responsiveness and feel is.
The Xamarin.Forms library adds an abstraction over common controls available on iOS, Android, and Windows Phone. Xamarin.Forms is extremely extensible, but it is not for every app, especially if you need a lot of custom UI or API access. For data entry, proofs-of-concept, or other simple apps it is great and we have a guide to help you select: http://cdn1.xamarin.com/Architecture%20Selector.pdf. The nice thing here is that either approach can use a shared-code backend.
I think I can address some of your concerns below:
1.) I would love to know which components you were having issues with and I can work with the team. There are a lot of settings in Visual Studio and Xamarin Studio as far as when to break on exceptions so I would love to help out here.
2.) If you are exclusive to using Xamarin.Forms then yes you will have a limited set of controls, since Xamarin.Forms is a subset of common controls. It is extensible via “CustomRenderers”, but that require some work and if you need a lot of them then it might be worth looking into the native approach without Xamarin.Forms as this approach will automatically give you access to every control on each platform you are creating.
3.) We are always looking to expand our documentation across all of our products and highly recommend checking out our updated developer portal: http://developer.xamarin.com there is a plethora of Xamarin.Forms related documentation as well as http://developer.xamarin.com/guides/cross-platform/xamarin-f... It is pretty extensive, but if there is something missing please please please let us know and we will work with the documentation team to add it. In addition to this documentation we do have a book that has been written by Charles Petzold on Xamarin.Forms that is freely available: http://developer.xamarin.com/guides/cross-platform/xamarin-f...
4.) For XAML intellisense it is built right into Xamarin Studio, for Visual Studio there is an extension that you can install: http://www.cazzulino.com/mobileessentials.html This will be integrated automatically in the future. I apologize that this is tricky to find.
Hopefully this helps out a bit with some of the issues that you have run into, but again please please feel free to email me with any questions, encounter any problems please reach out to us so we know and can fix them. You have my direct line: firstname.lastname@example.org.
What would be the best way to do 2D graphics using Mono? I have an editor project written in WPF, but mostly uses 2D APIs (since...I'm building my own editor, some videos here ). Anyways, my only Windows platform dependency is WPF (most of the magic is platform independent), and I'm wondering how to make my app cross platform. The most appropriate I can find is mono.cario, but it doesn't seem to be very active.
I'm following your blog.
In last month, you try to prove UI xamarin form capable do all layout
Here is the idea, if you dont mind, would you convert ListViewAnimation android to xamarin component
(Warning: this is not a light library)
At the moment, there is no listview xamarin component support drag and drop swap row.
Need that to move and reorder and row sequence
I'm sure every project need powerfull listview
Love your work
Have you taken a look at Facebook's new framework, React Native?
The end user is not touching HTML and CSS. They touch native components with native performance.
I've used Phonegap, and was able to use the back button without any issues.
Another important point is they do provide a single automation test framework that targets both platforms.
If I was starting the app again I'd be very conflicted whether to use Xamarin vs native, though ReactNative looks very interesting too and doesn't have the complexity of running the full .net stack.
I'd probably use RubyMotion for an upcoming project at work if it had a port to WinRT for Windows universal apps.
They are not on Android, where RubyMotion uses the Dalivk/ART GC.
So, your cross-platform Ruby code has to deal with two different types of memory management systems. I'm not sure this qualifies as a better option to what Xamarin provides.
First of all, in December we released a new tool called Objective Sharpie that can automatically bind Objective-C libraries into C#:
If you're skilled enough to build the Objective-C library, then you'll be able to use Objective Sharpie to create a C# binding. We also have docs on doing this for Java on developer.xamarin.com.
Some of our customers don't have the time or skill to do this themselves, and so we've recently created a bindings team that wraps third-party native libraries for our customers. Many of these end up published on http://components.xamarin.com/ (there are over 300 components now). But some of them we can't immediately publish because we need to get permission from the original library author to redistribute their library. This is especially true for commercial SDKs. But if you contact us directly, we might be able to give you something.
We also do custom bindings through our support team. This is something that unfortunately we haven't made very obvious. But you can just email email@example.com and we can create a binding for you.
Like I said, this is an area we're pretty focused on. If you have any feedback, please feel free to let me know directly: firstname.lastname@example.org.
But when are you gonna let us use Xamarin Studio on Linux?
To target the full range of mobile devices, one has to have Windows, a Mac, or both anyway. So there doesn't seem to be much advantage to supporting development on Linux.
I don't see any options that come close to solving this. Xamarin is not native to either iOS or Android. RoboVM (the one i work on) can cheat, as we only need to solve it for iOS, Android comes for free. React Native has no clear path for accessing 3rd party libs at all yet. Whatever they can come up with will be further complicated by the fact that the JS engine is single threaded.
I've often been surprised at how easy it is to create bindings to libraries written in Obj-C even if no one else has before. Usually it requires extracting the compiled library from the framework, and then translating each declaration from the library's header into the C# binding definition. In many cases it's a couple of hours work (or less).
That said, libraries that are provided as source files, with the instructions "just copy them into your project," can be incredibly frustrating. Our designer would love to use github.com/MengTo/Spring but I have yet to find a way to use it in Xamarin easily.
Cocos2d is nice to work with as well as with Unity; we had most issues with Monogame (and that uses Xamarin) but once we got over those issues I believe we would be effective equally with Cocos2d & Monogame and slightly more so with Unity (because of the community mostly).
I still use WebStorm + JS for frontend Web work, though. Would you say it's worth the switch to VS and TypeScript (though WebStorm supports TypeScript, too)?
Developing typescript in VS is about as easy as developing C# in VS. Everything "just works".
As far as I understand it, if you are big and have the resources, your best bet is still to develop separate native apps for each platform.
As far as "recommendations on developing for multiple mobile platforms", I'd be happy to answer slightly more specific questions.
> As far as I understand it, if you are big and have the resources, your best bet is still to develop separate native apps for each platform.
If you have different teams for each platform, it makes sense to go native and duplicate the effort. As soon as you want to share code or resources (including employees) between more than one platform, Xamarin starts making sense. If you have a small mobile development team (1-2 people), you'll probably need to either pick a single platform, or go with Xamarin. If you plan to have a Windows app, Xamarin makes sense. If the business is already using Microsoft technologies (Windows, .NET, C#, Visual Studio, TFS, or even Typescript), then Xamarin makes a lot of sense.
However, Xamarin is not a silver bullet. It does comes with some trade-offs (in addition to those mentionned in the article).
- You still need a Mac (either as your main machine, or on the network).
- Compile time is a bit slower.
- You don't get access to the latest Android SDK on day one (you do with iOS, though).
- You can't use any existing iOS/Android libraries out of the box. Someone (which could be you) need to manually "bind" the Java/Objective-C library interface to C# first.
- Application startup time might be a bit longer on iOS.
Did a project at work with Cordova, it works, but it is only usable for CRUD type of applications.
As for hobby projects, a few multimedia ones with SDL, which was ok since nothing more was being used besides OpenGL and touch input.
Tried to use Qt/C++, only to discover it kind of works, but even with all these years of talking about mobile support, Qt is pretty raw. Lots of native API wrapping is required or only available in the commercial version.
Xamarin is quite appealing, and even with the usual HN complaints about their prices, they are actually not much different from other commercial solutions for the mobile market.
Personally, I am using C++ for portable logic, together with the native UIs in Java, C#, C++/CX. However due to the pain it is to use the NDK, specially now that Google dropped the ball, I am thinking about focusing on just one platform.
If I would be doing this at work, maybe Xamarin would be the solution to go.
Xamarin provides a managed runtime environment (Mono) and a way to call native iOS and Android APIs from that environment. Xamarin Forms builds on top of those things to provide a cross-platform UI toolkit that uses the native controls on each platform.
Qt is a cross-platform GUI toolkit that draws its own controls using each platform's low-level graphics facilities. As such, the controls in a Qt-based application aren't fully native to each platform. Qt tries to mimic the native controls, but the emulation isn't completely faithful. A particular problem is accessibility for users with disabilities, e.g. blind users who need to use a screen reader. Last time I checked (several months ago), Qt didn't implement the accessibility APIs for iOS or Android at all.
Because of the non-native nature of Qt, I would strongly recommend avoiding it in favor of something like Xamarin or RubyMotion.
On my case, I wanted to make use of the native file pickers, which only became available in Qt 5.4 via QML (not C++) for Android, with iOS and WP8 support still coming.
Granted, on Android's case the pickers are only available as of version 4.4, but they are available and it is also possible to use intents for lower versions and vender specific pickers.
On my specific case, I came to the conclusion that writing my own JNI layer would be less trouble than debugging Qt. However note that for me this is just hobby development, whenever I feel like coding for it.
Compared to Xamarin, The Qt Company seems to still be searching on what platform integration to sell to companies and how.
If I was starting from scratch today, I'd take a good look at Titanium, React, Xamarin and Ruby Motion (in that order). In general, I think cross platform will save you time and money if you do it properly.
Titanium has been a timesaver for me. My current backend (stocklight.com) is written in Rails. For iOS and Android clients, Titanium gives me about 90% code reuse on the front-end.
ie. It allows you to implement cross platform GUI's using the same view code and you just make platform specific adjustments (eg. Action Bar versus NavigationWindow) where neccessary.
There's no way I would have had time to develop both backend and android/iOS by myself if I had to write everything natively.
Having a single model/controller layer with Titanium has been good also but I recently made the effort to upgrade this part of the project to use Alloy and that has felt very Rails-ish which has been a big improvement.
This week, Appcelerator have announced their new pricing structure ($39 per month) and are pushing a new service called Arrow for managing your back end. Personally, I don't think i'll be using Arrow (Rails seems like a better choice) but it will be great to get LiveView 'instant updates' with their new SDK.
Also, re. speeding up Android development, you should definitely check out Genymotion.
Unfortunately, the built-in IDE for Unity is MonoDevelop, which has all the problems Xamarin does, You don't have to use Mono though, you can use any editor.
In fact, Visual Studio has first-class support for Unity now, since MS bought the company that made UnityVS and released it as a free VS extension.
I really don't think I could recommend using Unity for a non-game app, though, at least in most cases. It would be a subpar experience for both the developer and the user.
In addition, it does have a little size overhead - the smallest possible build on iOS (a blank screen) is 12 MB with all the optimizations on, and double that if you need to invoke System functions or libraries that need them.
Update() on Unity doesn't strike me as being all that different than a normal GUI app's message loop.
That said, when all the work is done and the critical bugs are squashed, and a cross-platform app works as intended, it's a thing of beauty -- and especially wonderful when it comes time to roll out new features every week.
As a side note, it's very game-focused, but we've put together a matrix with all of the pros and cons of using various cross-platform frameworks. Maybe helpful: http://blog.doublecoconut.com/crossing-the-mobile-platform-w...
Its faster and easier to get a prototype or very simple (non-polished) app working that does not rely on specific api's to the mobile too much.
So basically you will manage to get 80% done more quickly with the cross platform tool.
However the last 20% are the very tricky part. There might be some strange bugs appearing from the cross platform tool that are hard to solve or just simply wanting to achieve a very polished app with smooth transition and the latest 'native' UI components and UI paradigms (e.g. Android Lollipop).
I also had a few major bugs coming from the interface between the native SDK and the cross platform framework. One example was that suddenly the phone fonts for some Asian languages were not displayed anymore. These problems often happened when there were some SDK changes on Android or iOS and the cross platform framework had to catch up with these changes.
Compared to native developments its also way harder to find good libraries and solve bugs (e.g. via stack overflow) because there are just way less people developing with these cross platform tools.
Since last year I stopped all cross platform developments and are now developing for iOS and Android natively and I realised that I am actually developing IN SUM faster natively then before with the cross platform tools. Main reason for this is that I have a huge focus on polished and high performing UI's and in the past I wasted a huge amount of hours just to fight the weaknesses of the cross platform tools.
So my recommendation for all who want to develop polished and professional iOS and Android Apps is now to go the native route from the beginning. Its better to try and save time by shifting some code to the server side (if you have a mobile app that extends a web app) and by developing a great abstract documentation/specification that can then be quickly implemented in the respective native language.
When I was deciding, I had a look at the Xamarin docs, and it seemed to reference the underlying native idioms quite often. I figured that I'd end up spending the same amount of time learning Xamarin as iOS, so what's the point?
In the end, I found the backend logic was pretty easy to write in Android or iOS. They're both OO languages, and once you've figured out the model it's not going to be hard to port. After all the phones all have similar hardware, and there's got to be some way to do the same thing.
The problem is the UI. I found it was a massive pain to learn two ways to lay out stuff. Android seems to encourage you to layout things in group containers (horizontal/vertical) that have an internal logic of their own. iOS seems to have a thing for constraints. Neither is very obvious, and they are not that easy to port from one to the other. They also each have somewhat different aesthetics (this friggin changes every time there's an update), which means you need slightly different designs (no hardware back button? no built in check box?). After grappling with this for ages, I ended up doing webviews with responsive pages. Makes the thing look like a web page, but a simple one that works like an app and can also be tested on a desktop browser.
Corona SDK is free and builds to Android/Windows/iOS with cross-platform wrappers available for what Corona has chosen to wrap, which can be different for each platform.
You don't get access to native UI elements. Instead, Corona offers OpenGL-based replacements (which may or may not be sufficient). You can also pay for Corona Enterprise and write your own platform-specific wrappers around native objects.
Corona is nice if you have a lot of custom graphics, but if you are going for pretty standard user interaction, you will spend a lot of time recreating what exists on other platforms.
For both Xamarin.Forms and Corona you will run into the limitations, but with Forms it is much easier to adjust those with native code.
I think the main issue with Corona is that they are more focussed on the game case (for which it works)
This to me sums up my experience with Xamarin. It has A LOT of potential, and I did generally enjoy working with it. However, the amount of small issues I dealt with that were never solved (and still haven't been solved 2 years later) are what drove me away. That and the cost...
That is incredibly cheap. It's the sort of cheap that's so cheap you wonder what the catch is.
Assuming a perfectly spherical developer, you're at $100,000/year. You're using Xamarin because it makes that developer more efficient because (1) you've determined C# is an easier language to maintain and/or (2) cross compatibility is worth something. If this developer is just 1% more efficient, you've paid for your Xamarin license. If he's not 1% more efficient, why are you even using Xamarin in the first place?
So I'm looking at learning more about Swift and that ecosystem someday. I don't know C# but I certainly see Xamarin as an upgraded version of Kivy.. obviously going from a free platform to a paid one. It's something I've keeping my eye on for quite some time.
If I ever find Kivy and the native iOS development combo to not meet my needs, Xamarin is the next stop for me.
The learning investment is what makes me most hesitant to use Xamarin. It was supposed to be less of a learning investment because we all have C#/.NET experience, but now I'm not so sure. It now seems like we're going to have to dive deep into learning iOS and Android specific UI concepts anyway, and on top of that learn Xamarin concepts and quirks, and if we want to continue using Visual Studio when the trial is up we'll have to pay $1000/year. Maybe we're just not the target market.
This includes hundreds of samples:
And lots of detailed guides:
And dozens of videos too:
As for Xamarin University, the vast majority of that experience is live, interactive learning with a teacher. That's why it costs money. The recorded versions of those interactive classes aren't that useful on their own. But, we're working on developing some good standalone e-learning content and when we do it will be widely available.
It is 1:1
And, do most of the things listed here apply to it as well?
On the code behind side of iOS/Android (UIViewController or Activity) you write all of this in C# with C# features like LINQ, events, delegates, etc. and you have access to 100% of the iOS and Android APIs of the platform as well.
Now we do have the Xamarin.Forms library which adds on top of this to build on a shared UI layer for iOS, Android, and Windows Phone as well. However it is not for every app and we have guidance at www.xamarin.com/forms. Hopefully this is a nice overview of the platform.
Xain is native...
if you are picky enough "subnative"
Apple is much trickier. You can still open iOS projects, modify code, and compile without a Mac connected. However, to actually do design in the storyboard designer in VS or build the package to deploy on a simulator or device you need to be connected to a Mac somewhere on your network. This is apple restrictions and also for the fact that all of the simulators and tooling only exists on the Mac.
You don't have to have a power house machine to do this though, something like a Mac Mini would work fine. There are some cloud solutions out there as well.
Xamarin stuff obeys others: Apple says no dev w/o Apple hardware
If you dont have mac, and belive in xamarin,
My sugestion is try build on android first,
If have good respond from customer, then buy mac and porting to iOS
Porting xamarin android to iOS is very easy if you have mvvm knowledge