
Your C# App on 66 Million Macs: Announcing Xamarin.Mac - evanw
http://blog.xamarin.com/2012/12/12/your-app-on-66-million-macs-c-sharp-on-mac/
======
georgemcbay
Looks nice, but as with MonoTouch the pricing kills it for me.

While I'm sure it pays for itself in overall value if you actually ship a
product with it, attaching a price that high to a development tool causes
(IMO) all sorts of secondary effects like balkanized user community, inability
to realistically use it for writing open source software that anyone will
collaborate on, etc.

If the product cost more like $99 it might be able to overcome the inertia a
bit better. I know I'd be willing to buy it for that even if I wasn't sure I'd
ship a product on it, but $399 is Real Money, so as hypothetically interested
as I've been in MonoTouch, etc, I've never really looked at it beyond the
press releases.

~~~
yawn
I used MonoTouch at work (where price was not an issue) to convert an existing
project to iOS. Aside from some minor complaints about the editor, the
experience was amazing. I had previously written a couple of iOS apps using
the "native" toolset, and I would not go back if I had the choice. While I
understand your pain (I would gladly fork over $100 as a lone
developer/hobbyist for personal development, but can't hand over $400), I
think the price tag is completely justified.

~~~
eropple
I've been playing with it on my own, and I tend to agree. MonoDevelop is still
pretty rough--I'm doing game stuff, so I'm kicking any actual OS X development
down the road as far as humanly possible--but once you get your code
deploying, it's a very nice setup.

I'd really like a way to build in VS (maybe against dummy assemblies or
something) and kick it over to my MBP for real compilation and deployment,
though. I respect their desire to funnel users through MonoDevelop, but it
doesn't step to VS+R#.

~~~
cdmckay
I don't think they're trying to funnel users to MonoDevelop, I think they're
using it because the iOS SDK is for Mac.

Take a look at Mono for Android, for example. It uses a VS plugin instead of
MonoDevelop.

~~~
shadowmint
I might be in the minority here, but I use MonoDevelop in preference to visual
studio.

It's got a couple of irritating issues (the plugin support is rubbish even
now, and it's ridiculously complicated to roll your own), but its just so
_fast_.

My morning at work is: git pull, go get coffee while VS spazzes out for 5
minutes and resharper reindexes everything.

~~~
eropple
IMO, that sounds like an issue with your hardware. I use a three-year-old
desktop with a Nehalem i7 and 16GB of RAM (or my rMBP with Parallels, which
may be faster) and VS/R# is pretty happen even with 50+ projects and about
1600 source files.

Older machine? Overactive anti-virus or something causing file I/O pain?

------
danabramov
My experience with MonoTouch has generally been very positive. Why I love
MonoTouch:

\- C# goodness, especially event handlers instead of overly verbose ObjC
delegates

\- It's fun to port ObjC loops to oneliners using LINQ and lambdas

\- I prefer somewhat ugly MonoDevelop to pretty-but-very-odd Xcode

\- I can reuse both C# and ObjC code, and ObjC code is straightforward to
port, if needed

\- Xamarin support is friendly and helpful

There are some things that annoyed me:

\- Some generic-heavy C# code will crash the device due to AOT
limitations—learned it the hard way

\- MonoDevelop hangs for a few seconds after you switch from Xcode, even if
you didn't change anything

\- You need to make sure you _understand_ how MonoTouch GC works together with
ObjC reference counting, or you'll get memory leaks

\- You'll need to learn to use Instruments to find those memory leaks

\- Debugger often freezes (should've reported this)

\- Binaries can get heavy, but not too heavy

\- Compilation is impossibly slow on Air, barely tolerable on Pro

\- Lack of tooling for binding ObjC code—I wish I could just drop ObjC files
and headers into a MonoTouch binding project instead of compiling it to fat
binary first

But still, I'm glad we went with MonoTouch.

~~~
jbigelow76

        - You need to make sure you _understand_ how MonoTouch GC works together with ObjC reference counting, or you'll get memory leaks
        - You'll need to learn to use Instruments to find those memory leaks
    

Interesting, reading that makes it sound like a C# developer that wants to
work with MonoTouch will have to verge off to learning at least some Objective
C if they want to have shippable code. The coder side of me is always up for
learning a new language but if shipping was my utmost concern I'd want to get
right to coding in C# and let MonoTouch take care of the rest. That doesn't
appear possible.

How much time do you think a C# developer with several years of experience
would need to put into learning the ins and outs of ObjC memory management
before their code could be considered close to production level?

~~~
danabramov

        Interesting, reading that makes it sound like a C# developer that wants to work with MonoTouch will have to verge off to learning at least some Objective C if they want to have shippable code.
    

Yes, you'll definitely need to learn some things about Objective C. This isn't
really about learning the language itself though. It's more about
understanding iOS and ObjC runtime.

The closest analogy to C# develop would be COM and P/Invoke. C# provides tools
to interface with COM and native libraries, but you still need to learn some
marshalling fundamentals so you can ensure GC doesn't collect objects while
they are being used by native code, you need to implement IDisposable and not
forget to free unmanaged resources, etc.

It's similar with MonoTouch: you need to understand that MonoTouch classes
“wrap” native objects, that disposing of wrappers doesn't necessarily kill
native objects because other native objects may still link to it, and that
sometimes GC can't know for sure if an object is eligible for killing, and
will never collect it.

In general, this comes down to: don't rely on .NET GC to kill native objects,
do it yourself. My life got so much better after I started doing so.

Things that confused me most (and which are all you really need to know about
ObjC memory management):

[http://stackoverflow.com/questions/13058521/is-this-a-bug-
in...](http://stackoverflow.com/questions/13058521/is-this-a-bug-in-monotouch-
gc)

[http://stackoverflow.com/questions/13064669/why-cant-
monotou...](http://stackoverflow.com/questions/13064669/why-cant-monotouch-gc-
kill-managed-objects-with-refcount-1)

This is a great screencast I wish I saw _before_ I started coding in
MonoTouch:

[http://forums.xamarin.com/discussion/33/finding-memory-
leaks...](http://forums.xamarin.com/discussion/33/finding-memory-leaks-in-
your-apps)

It explains how to find native memory leaks.

How much time does it take to learn this? No more than a week. But it takes
more to find memory leaks in existing app so it's better to get some
understanding and learn to profile early. For me, “fixing” a two-month-old
codebase took about week and a half.

~~~
danabramov
If I could give advice to myself when I started writing production code in
MonoTouch without any experience with it, it would be: “Don't Guess. Profile.”

For example, I spent a lot of time making sure I don't load heavy .NET
objects, but most memory crashes went away when I started using JPG instead of
PNG pictures in a picture-heavy app.

Then it got a _lot_ better when I took time to learn about best iOS practices
such as keeping a pool of about ten reusable views and re-filling them with
new content as they go offscreen when the user is scrolling, instead of
creating hundreds of views at once. What is really nice, iOS6 UICollectionView
class enforces this memory usage pattern by providing a neat API with view
pool. Use it instead of rolling out your own collection view.

Another hard lesson was to never block UI thread and do _any_ computational
intensive stuff such as parsing JSON in .NET Tasks on another thread. This is
obvious in retrospect, but I thought parsing JSON wasn't intensive. It was.

Finally, _if your app crashes randomly, it's most probably your fault_! I
really need to stress it because I fell into this trap, thinking MonoTouch is
buggy when my app crashed every minute. Turned out, it had insane memory leaks
and aggressively allocated large amounts of memory at once—but I didn't bother
to learn about “right” techniques until it was too late. Learn to profile
early so you don't panic later.

~~~
jbigelow76
Thank you for taking the time to provide these tips and links. Lots of good
info here that I'm sure I'll be referring back to in the not too distant
future.

~~~
danabramov
Sure—if you have any questions feel free to ping me at dan@stampsy.com

------
lucian1900
Xamarin's stuff looks really nice, but I really wish they had a non-profit
free tier. I can't even make opensource Android apps without paying a lot.

The other problem is the lack of linux support for their SDK. Seems rather
odd, considering Mono's roots.

~~~
natfriedman
It personally pains me not to support Linux, but we get such a tiny fraction
of our customer base coming from Linux that it isn't worth it. Not to mention
that there is effectively no "Linux" platform and you have to select a subset
of distro versions.

~~~
lucian1900
I'm sure most people would be ok with an Ubuntu version.

Perhaps more of your customers would use Linux for Xamarin stuff if it was
available?

------
bronxbomber92
Where does this leave MonoMac? <http://www.mono-project.com/MonoMac> states
that Xamarin.Mac has broader API coverage; does this mean MonoMac will
continue to be developed, but just remain as a (free) subset with LGPL
portions?

~~~
jstedfast
The plan is to continue to contribute to MonoMac and it will remain free/open
source.

------
jbigelow76
Xamarin does some impressive work. They are becoming to C# what PhoneGap is to
Javascript/HTML (license fee not withstanding).

------
lubos
I'm huge fan of Xamarin but somehow missing how is this different from
MonoMac?

For anyone who is thinking to start development of cross-platform GUI app in
.NET, I encourage to check Eto project - <https://github.com/picoe/eto>

~~~
natfriedman
A few diferences:

1\. Xamarin.Mac comes with a commercial license, so you can ship to the Mac
App Store (not allowed under MonoMac's LGPL license).

2\. Xamarin.Mac comes with commercial support.

3\. Xamarin.Mac includes bindings for several new APIs, including
CoreBluetooth, GameKit, StoreKit, SceneKit, and the new Mountain Lion AppKit
classes.

You can see a full list of differences here:
<http://docs.xamarin.com/mac/guides>

~~~
eropple
MonoMac appears to be ASL/X11. MacCore too. <https://github.com/mono/monomac>

_The code is licensed under the terms of the open source Apache License
version 2 or the MIT X11 license, at your own choice._

Also, the Mono wiki indicates you can already deploy to the App Store (which
I've been looking at doing for a project): <http://www.mono-
project.com/MonoMacPackager>

_With the new release of the MonoMac add-in for MonoDevelop, you can easily
turn your Mono application into a full Mac bundle, and you can also get a Mac
installer for your application with all of the Mono dependencies bundled with
it as well as creating Mac applications for distribution on the Apple Mac
AppStore._

Is there something I'm missing?

~~~
migueldeicaza
The MonoMacPackager no longer exists, and has not existed for a few months. We
basically granted a license for appstore distribution to anyone that requested
the license for AppStore distribution, since we did not originally have plans
to build a product.

Now that we are launching a product, we offer the license as part of
Xamarin.Mac.

I will update the page accordingly.

~~~
eropple
OK, that makes sense. I mean, for an independent developer, that _sucks_ ,
because it's honestly not worth $399 to me (I'd be happy to pay for it in a
corporate setting like we do for MonoTouch, because of the support stuff, but
for personal-project stuff I just can't rationalize it), but I get the
reasoning.

Is the licensing for MonoMac/MacCore remaining as-is?

~~~
migueldeicaza
Yes, MonoMac/MacCore will continue to be MIT X11.

We will also continue to maintain it, as it shares most of the code for
Xamarin.Mac

~~~
eropple
Awesome, so there's an upgrade path. Thanks for the clarification!

------
mapgrep
Interesting that Apple allows this, not just on Macs but on iOS devices. When
Adobe wanted to cross-compile Flash for iOS, here is what Steve Jobs wrote:

"We know from painful experience that letting a third party layer of software
come between the platform and the developer ultimately results in sub-standard
apps and hinders the enhancement and progress of the platform. If developers
grow dependent on third party development libraries and tools, they can only
take advantage of platform enhancements if and when the third party chooses to
adopt the new features. We cannot be at the mercy of a third party deciding if
and when they will make our enhancements available to our developers.

"This becomes even worse if the third party is supplying a cross platform
development tool. The third party may not adopt enhancements from one platform
unless they are available on all of their supported platforms. Hence
developers only have access to the lowest common denominator set of features.
Again, we cannot accept an outcome where developers are blocked from using our
innovations and enhancements because they are not available on our
competitor’s platforms."

<http://www.apple.com/hotnews/thoughts-on-flash/>

FWIW, I've always thought this was an overly broad generalization.

~~~
pudquick
You must have missed the part where Apple relented on that:

<http://news.cnet.com/8301-30685_3-20015954-264.html>

[http://www.apple.com/pr/library/2010/09/09Statement-by-
Apple...](http://www.apple.com/pr/library/2010/09/09Statement-by-Apple-on-App-
Store-Review-Guidelines.html)

"In particular, we are relaxing all restrictions on the development tools used
to create iOS apps, as long as the resulting apps do not download any code.
This should give developers the flexibility they want, while preserving the
security we need."

(which is why I see so many Unity games on the App Store these days)

~~~
lwat
There's still no flash on my iPad though.

~~~
eropple
But you can use Flash to build iOS applications, though. (Or, rather,
ActionScript; there are a number of different tools that allow this.)

------
LaSombra
This might be the final blow to Java on the desktop.

~~~
QuantumGuy
If Java is a terrible language and horribly designed then why do people still
use it?

~~~
pretoriusB
1) Great built-in library

2) great third party libraries,

3) decent documentation and tons of books and instructional material,

4) best-in-class virtual machine, good GC, as speedy as you get with managed
code,

5) tons of profilers and development tools

6) several industry leading tools written in it (Hadoop, Lucene/Solr, Hbase,
etc) and for it (IDEA, Eclipse),

7) Enterprise support from big companies (Sun, now Oracle) and IBM, and
several smaller ones

8) Keeps improving (closures added in current 8 beta for example)

9) A large ecosystem of interoperating JVM languages, from Ruby/Python like
(Groovy) to Haskell like (Scala), to Lisps (Clojure)

10) 15 year history, and at some point it fixed a lot of C++ pain points for
enterprise programers

~~~
elteto
With all of these pluses, it can't be that terrible right? ;)

Java is not anymore terrible than anything else when you remember to use the
right tool for the right job. I have developed in Java, libraries (JDK's and
third party) are just _incredibly_ good, you will not find the same variety
and quality anywhere else, period. The language is verbose and also /insert
favorite Java complaints here/. So what? Get over it and _use the right tool
for the right job_. We are programmers, not damsels.

------
Kluny
I used Xamarin's Stripe library a few weeks ago. Super nice stuff.

~~~
natfriedman
Cool! We were an early user of stripe, launching with it on our store in July
of 2011. Stripe is great.

------
sev
I downloaded the trial and tried to create a Xmarin.Mac.Project and I got an
error that I need to buy the software.

Did I choose the wrong option? If so, which one should I be testing? Why can't
I test out all features of the tool?

Also, I agree with everyone else that the price point being $399 is way too
high for personal development. Would it be possible to get something cheaper
for personal development to see if it's actually useful for my needs?

~~~
picklefish
What did you try in? MonoDevelop? I downloaded MonoDevelop and the trail for
ANDROID this weekend and was able to make an android app with no issues for
free. The limit basically being that I could only use the emulator and not
test on a real device. I'm not sure how they limit the mac version though. If
you want to check it out maybe try out the iOS or android trial which
definitely lets you build.

Also you could try MonoMac which is almost the same thing, and is OpenSource.
The Xamarin version is supposed to have Wider API coverage and do a bit more
(for the cost).

------
j_s
So MonoMac is going pro? Glad to see it will be supported.

<http://www.mono-project.com/MonoMac>

    
    
      > the result of weekend hacking as our day to day work 
      > revolves around Mono's efforts on Linux servers, Linux 
      > desktops, Visual Studio integration and our mobile 
      > efforts. Luckily, it shares some components with MonoTouch.

------
nanijoe
Does this allow you to develop Windows Apps using a Mac? Or is this mobile app
specific?

~~~
bibinou
It allows you to build Mac OS X apps using the C# language.

------
danabramov
By the way, our MonoTouch app just got approved by Apple an hour ago. Sweet.

------
azakai
Cool stuff. Now how about running C# apps on the web? :)

~~~
eatsleepdrink
You can also do javascript with it. I can't speak to it personally but friends
have used Script# (<http://scriptsharp.com/>) for client-side javascript with
good results. Never heard of anyone attempting node.js with it... yet.

~~~
azakai
There are some C# to JS compilers, script# and JSIL for example, yeah. But
none are officially supported by Xamarin. I was just curious why they focus on
all possible platforms but the web.

------
chrisringrose
C#'s okay and all... But what's wrong with Objective C?

~~~
migueldeicaza
Managed languages are designed with a different set of goals than unmanaged
languages. C#'s design goals were in general to reduce the number of bugs,
help developers write better code, and maintain the code over the long term.

It has evolved over the years to also adopt new programming techniques that
have proved to be useful (generics, iterators, functional constructs, delayed-
execution frameworks, Async programming features and dynamic features).

But the idea is that you start with a safe environment that is relatively
fast, close to C, but where the goal is not maximum speed, but increased
productivity, fewer bugs.

Then you try to optimize things to get closer to the performance of a native C
compiler. For some things, you can get there, for some others you can not do
it.

So it leads to a different style of programming, you spend less time thinking
about book-keeping, about making sure that you did not free the same buffer
twice, ownership rules and so on, and you can focus more on the problem at
hand. In day-to-day life, you spend less time tracking down production bugs.

It is not a silver bullet, and wont fix every problem, and you still need to
do careful bookkeeping of other things (like, did you load too many images?)
but at least you can ignore the grueling minutiae and focus on what matters
most.

It is a little bit like the difference between using raw OpenGL and loading
your vertices manually every time or using a toolkit that loads meshes and
textures for you.

~~~
danabramov
Can't wait to use C# 5 async in MonoTouch. I heard it's coming soon.

~~~
migueldeicaza
It is!

We are hard at work in upgrading both MonoTouch and MonoDroid to use Mono
3.0's compilers and class libraries. That is why you have seen a flurry of
commits to Mono's master tree.

We are hoping to have a preview in late January.

------
mjs
Does this use "native" OS X components?

~~~
CodeCube
Yeah, they just bind to the existing libraries, so you end up using all of the
native tools.

------
kevin_rubyhouse
How is something like this done?

