
Some thoughts after (almost) a year of real Xamarin use - xngzng
http://www.estaun.net/blog/some-thoughts-after-almost-a-year-of-real-xamarin-use/
======
ParanoidShroom
I've been using Xamarin forms a lot now. They are miles from being as good as
native development. Soooo many bugs in xamarin itself. When using Xamarin
forms, you will not provide as good of product as you would native. There are
also very little controls. Xaml works, but is really slow. And the layout is
SOOO inefficient ! But the problem is even greater, you can't merge Android
and iOS layout passes. On one platform, measuring is really fast and the other
really slow ... Xamarin forms can't compensate and give native performance to
this. They don't even have listview recycling ... One developer even said
"RelativeLayout is probably best for you here and can do this" to the question
what the fastest layout is. For Android, this is the WORST layout possible.

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.

~~~
natfriedman
Hey, I'm the CEO of Xamarin. I'm really sorry that you had a bad experience
with Xamarin.Forms.

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](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](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 - nat@xamarin.com?

~~~
bernadus_edwin
I using xamarin in last 16 months

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

~~~
migueldeicaza
Hello,

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.

~~~
bernadus_edwin
hi miguel,

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

------
Avalaxy
My experience with Xamarin:

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.

~~~
JamesMontemagno
Hey there, I am James Montemagno a developer evangelist at Xamarin. I have
been developing native apps with Xamarin for nearly 4 years now across iOS,
Android, and of course Windows (I was a customer for 2 years before joining
Xamarin). I just wanted to clarify a bit about Xamarin and Xamarin.Forms. It
is important to know that Xamarin.Forms is a cross platform UI layer that sits
on top of the core Xamarin platform. Using native Xamarin you are still
sharing your backend C#/.NET code and then building out native user interfaces
for each platform.

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](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](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...](http://developer.xamarin.com/guides/cross-
platform/xamarin-forms/) 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...](http://developer.xamarin.com/guides/cross-
platform/xamarin-forms/creating-mobile-apps-xamarin-forms/)

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](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: james@xamarin.com.

~~~
seanmcdirmid
Hi James,

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 [1]). 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.

[1] [http://research.microsoft.com/en-
us/people/smcdirm/managedti...](http://research.microsoft.com/en-
us/people/smcdirm/managedtime.aspx)

------
mark9white
Having been building a decent size app (tens of thousands of lines) in Xamarin
this really reflects our experience. One particular point is that the memory
management is fairly complex under the covers with bridged objects and
multiple memory management mechanisms working in parallel, this occasionally
rears its head.

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.

~~~
mwcampbell
I wonder if RubyMotion is much better when it comes to memory management.
According to the website, RubyMotion objects are platform native objects (ObjC
objects for iOS/Mac, java objects for Android), so each platform's native
memory management scheme applies, rather than having two GC's or GC plus
reference counting.

I'd probably use RubyMotion for an upcoming project at work if it had a port
to WinRT for Windows universal apps.

~~~
badlogic
Judging by the docs [1], RubyMotion does indeed not seem to use a GC on iOS
but instead relies on ref counting, reusing auto-release pools. That means
cyclic refs are an issue. You have to explicitely use weak references
throughout your code.

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.

[1]
[http://www.rubymotion.com/developers/guides/manuals/cocoa/ru...](http://www.rubymotion.com/developers/guides/manuals/cocoa/runtime/)

~~~
mwcampbell
Doesn't seem like a problem to me. The occasional weak reference to break
cycles wouldn't hurt anything on Android, would it?

~~~
badlogic
I guess not. But it's going to be tough to use normal Ruby gems on iOs that
aren't aware of the ref counting.

------
forcer
Great article, we have a similar story but only used Xamarin for 1 iOS app. If
I had option to go back I would not chose Xa marin, we would have used native.
Main reason being that we now need to add 3 SDKs to our app and none of them
are supported in Xamarin, it seems it will be cheaper and more predictable to
rewrite to native than implementing SDKs. Porting libraries to Xamarin is
possible in theory but in practice major effort and hard to do without access
to library code.

~~~
natfriedman
Hi there, I'm the CEO of Xamarin. I'm really sorry to hear that you had issues
with consuming third-party libraries. This is actually something we've been
recently very focused on improving.

First of all, in December we released a new tool called Objective Sharpie that
can automatically bind Objective-C libraries into C#:

[http://forums.xamarin.com/categories/ObjectiveSharpie](http://forums.xamarin.com/categories/ObjectiveSharpie)

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/](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
support@xamarin.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: nat@xamarin.com.

~~~
saosebastiao
ObjectiveSharpie is awesome! No problems so far.

But when are you gonna let us use Xamarin Studio on Linux?

~~~
mwcampbell
What would be the point of developing with the Xamarin Platform on Linux?
You'd only be able to target Android, not iOS, Mac, or Windows. In that case,
one might as well not use Xamarin at all.

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.

~~~
saosebastiao
The point would be to develop on a platform that I like developing on. Either
way, there isn't a single platform that you can use that will give you 100% of
the available platforms...if you want cross-platform across Android, iOS, Mac,
AND Windows, you are going to need a minimum of two computers. Why not develop
as much as possible on the one you like?

------
tluyben2
We tried mostly anything (and not only tried; we used for production work
because clients wanted us to) and, outside native, Xamarin really is the best
thing we worked with so far. For it's downsides, the upsides are too good to
not take advantage off. Some cons I recognize but the case everyone keeps
mentioning that you get into issue when you really want to do complex native
platform stuff with animations etc I haven't encountered. Nor is integrating
SDK's an issue. It's just something you plan in your project; it's a one-off.
We integrated very large SDKs for hardware products and the hardware vendors,
when something goes wrong, always blame the wrapper and it has 0 times been
the wrapper; most of the times a bug or undocumented feature by the SDK
creator. The wrapper is so thin and the mapping is so clear that it's actually
never an issue.

~~~
fnayr
Have you tried Cocos2d/Spritebuilder? If you don't ever make games for clients
it wouldn't really make sense. But if so could you explain what you didn't
like about it?

~~~
seanwilson
I've used Cocos2d with JavaScript binding a few times and really like it. You
can develop primarily in a browser then package a web (without requiring
plugins), Android, iOS, Mac and Windows app from your code with minor
modifications.

------
miguelrochefort
Most people don't realize how convenient it is to build and maintain your
entire codebase (iOS, Android, Windows Phone, Windows 8, web client, web
server) all in one place (Visual Studio), mostly using C# and Typescript. Just
have a Windows VM on your Mac. It truly is the best of both worlds.

~~~
omegavesko
Yeah, a huge part of why I still (mainly) run Windows at home is easy access
to Visual Studio. With third party extensions (e.g. ReSharper), and even
without them, it's probably the best single IDE I've ever used.

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

~~~
bkjelden
I haven't used WebStorm, but using VS for typescript was way better than using
it for javascript.

Developing typescript in VS is about as easy as developing C# in VS.
Everything "just works".

~~~
the_rosentotter
The .Net/Visual Studio ecosystem has been looking increasingly compelling
these last few years. But, I am old enough to remember evil Microsoft, so I
will almost certainly never go there.

------
alimoeeny
Now that we are at it, if you have experience / recommendations on developing
for multiple mobile platforms please share it here.

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.

Right?

~~~
ccvannorman
I use Unity3D to develop for multiple platforms and can't recommend it enough
-- it is a 3D game engine so it may be too heavy for some applications, but it
can do anything you want it to. Everything is written in C#/.net on your end,
Unity cross-compiles to other platforms.

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.

~~~
alok-g
How useful is it to develop non-gaming applications (including 2D UIs)? And
how much overheads it results in in terms of application performance and size?
Thanks.

~~~
strangecasts
Not very: it fundamentally assumes you're making a game, so it draws 3D scenes
and uses a continuous update loop, which taxes the battery on mobile devices.
The UI tools are also just finicky enough to make non-game app development a
pain.

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.

~~~
dangero
Have you actually seen a performance comparison when idle? I ask because I
have been curious about trying to build a full application inside Unity.

Update() on Unity doesn't strike me as being all that different than a normal
GUI app's message loop.

------
michah
I have worked with various cross platform tools for a few years now and in the
end all of them came to the same conclusion:

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.

------
lordnacho
I built the same app using Android and iOS, but considered Xamarin at one
point. I'm still considering it.

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.

~~~
rhodysurf
I completely agree.. I just feel that native is worth the extra time, at least
for me. Its really not hard to reimplement OO logic in objective C or Java if
you have already written it for one of the two.

------
declan
Has anyone had the opportunity to compare Xamarin with Corona SDK?

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.

~~~
Michielvv
I've been on projects with both: For business like apps, Xamarin (Forms in my
case) is miles ahead. Although Xamarin.Forms isn't really stable (We
experienced quite a lot of regressions with each new version) neither is
Corona.

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)

Finally, I really started to appreciate C# after doing Lua, PHP and JavaScript
for years. Especially on a complex app, the static typing really helps making
changes to code you did not write yourself.

------
themothaship
[http://forums.xamarin.com/discussion/comment/30355](http://forums.xamarin.com/discussion/comment/30355)

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...

------
insaneirish
> but 1000$ developer/year is not exactly cheap.

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?

~~~
balabaster
Er, that's on top of your Windows license, your Visual Studio license, your
Apple Developer License, your Apple Macbook because you can only compile and
deploy to the app store with a Macbook... oh and Xamarin university if you
want to become certified... _and_ if I understand the terms correctly, it's
not $1000 per developer, it's $1000 per developer per platform, so if you want
iOS _and_ Android, it's $2000 per developer on top of all that previous
licensing. So to say it's incredibly cheap at $1000 isn't the whole story.

~~~
cwyers
You don't need a MacBook. You can develop on Windows (which means you don't
have to pay for that Windows license) and use a Mac Mini on the network for
the OS X build requirements.

------
BuckRogers
I've been using Kivy. But decided if I did native, I'd only support iOS.
Mostly because I don't want to go down the rabbit hole of having to support
some random Android device.

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.

~~~
jjude
What is your experience with Kivy? Have you submitted to AppStore? I'm
evaluating between Kivy & Ionic. Hearing your experience will help.

------
DenisM
Can anyone comment on Xamarin learning curve? If I have experience in both iOS
and c#, how much time does it take to get up to speed with Xamarin?

~~~
natfriedman
We launched an online training program called Xamarin University, and so we
have a fair amount of data on how long it takes people to get to the point
where they are proficient enough to write a production app. As you might
expect it's highly varied. But the median is about 45 days to pass our
certification.

~~~
skwirl
I have been starting to learn how to write mobile applications with Xamarin to
contribute to a friend's project and had not heard of Xamarin University until
I saw this comment. Now that I have looked at it, I'm a little confused. I can
understand charging for 1-on-1 help, interactive classes, and certification
exams, but why wouldn't "recorded class videos, class labs and materials" be
free? Don't you _want_ it to be easy for people to use your software so that
people _will?_ Charging $1995/year for learning materials seems pretty steep.

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.

~~~
natfriedman
Right now we have a huge amount of content available on
[http://developer.xamarin.com](http://developer.xamarin.com)

This includes hundreds of samples: [http://developer.xamarin.com/samples-
all/](http://developer.xamarin.com/samples-all/)

And lots of detailed guides:
[http://developer.xamarin.com/guides/](http://developer.xamarin.com/guides/)

And dozens of videos too:
[http://developer.xamarin.com/videos/](http://developer.xamarin.com/videos/)

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.

------
aliakhtar
If anyone here has tried out Titanium by Appcelerator, I'd very much like to
know how your experience was. I've heard conflicting reports on how native it
actually is. This article says it uses HTML5 / web views, but I've heard that
it uses native widgets, and is pretty close to native. Any ideas?

And, do most of the things listed here apply to it as well?

~~~
dottrap
Titanium for iOS and Android use native widgets, not web views. They have a
target called mobile web which might use web views.

------
golergka
Is it possible to do logic code in Xamarin and develop UI natively for each
platform?

~~~
JamesMontemagno
The approach with Xamarin is that you are able to build out a shared C#/.NET
business logic layer. All of your platform independent code such as Models,
ViewModels, Database code, Restful Service calls, etc. You get to use the
power of C# and .NET to build this out. Then you build out user interfaces for
iOS, Android, and Windows and tie this logic all together. Xamarin apps are
native so you follow the same paradigms for building the UIs out such as
Android XML and iOS Storyboard or XIB files, but you can build these out in
the Xamarin Designers for both iOS and Android inside of Visual Studio or
Xamarin Studio.

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.

------
curiously
can you develop iOS apps in a windows environment without any mac machine? is
there a cloud build service for mac that you can integrate?

~~~
moljac
No.

Xamarin stuff obeys others: Apple says no dev w/o Apple hardware

~~~
moljac
macincloud?

~~~
curiously
it would be nice if xamarin implemented it.

~~~
bernadus_edwin
Macincloud is enough.

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

