Your C# App on 66 Million Macs: Announcing Xamarin.Mac

Not the original commenter, but as someone who's done a lot of work with it: it lacks a lot of the features that I've come to expect from basically any modern IDE, but yet manages to crash twice as much as any other IDE I've ever used (and that includes Xcode).

-As mentioned in the sibling comment, stability is a problem.

-Refactoring support isn't great. It's about on par with stock Visual Studio, but stock Visual Studio isn't good compared to VS+R# or IntelliJ. If you're writing "just" an iOS application, I can see this not being a huge deal, but my own use case is bringing over projects for OS X and iOS where I tend to have a lot of code and I'm very used to being able to do massive, contextual refactorings when needed. Can't do that in MonoDevelop.

-It's GTK#, so you have to accept that some stuff just doesn't feel native on a Mac. My mental map of keyboard behaviors no longer properly applies and it's jarring going between it and XCode or IDEA. It's gotten a lot better since I started using it on a Mac, to be sure, but it's not there yet. I compare it here to IDEA, which is also not Mac-native, but manages to feel a lot closer.

Now, one huge, huge plus, that I have to give them a ton of credit for: unlike Visual Studio, MonoDevelop is non-destructive toward project files. This is a power-user beef but a really important one once you get there; if you've hand-edited a csproj, Visual Studio will happily destroy all of your changes (it loads the csproj into an in-memory object model and writes it back out on save). This is infuriating when you have custom stuff in it - something as simple as a wildcard path in a file reference (which is totally fine as per MSBuild rules) will be mashed into a static list of all files at time of invocation. It is super bad, and if MonoDevelop improves some more I might switch to it, even on Windows, solely because of that lack of misfeature.

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.

I'd personally love for JetBrains to do a C# variant of IDEA (+ R#) for us OSX/*nix folk. I have serious doubts such a beast would be commercially viable, though.

(Maybe R# for MonoDevelop? One can dream...)

Consider the possibility that

a) Miguel De Icaza doesn't set the pricing on the product

b) Even if he did, that indie developers who are unable to fork over the $500-$2000 for a license are not part of their target demographic.

Monotouch seems to be popular enough with their existing pricing that they don't need to address anything smaller (and FWIW, their products are too expensive for me too, as much as I would love to be writing Mac/iOS apps in C#, I'm not forking over that money for it)

And what about on the android and windows app stores?

No, the GPL does not allow for further restrictions. The App Store doesn't care.

You can distribute your own GPL code through the App Store. You just can't include other people's GPL code.

That would be enough for a useful "free for free software, pay for commercial development" model.

Nobody's forcing anyone to distribute their GPL'd apps though the App Store.

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.

Interesting. I'll admit, my draw to the platform is a 50/50 split between disliking Objective C (/XCode) and the possibility of sharing code between Android and iOS versions of an app. I guess more people are with you for the latter than the former these days.

I have to say it definitely feels like you guys are paying more attention to the MonoDroid things these days. Great work on the recent release BTW~

Besides the "Mono wave" on Gnome seems gone. Now there are some guys pushing Vala, and it reminds me the time when Mono was the future of Gnome.

https://live.gnome.org/Vala

Several Gnome applications have been rewritten in Vala and, having contributed a patch to Déjà Dup, I find it's a language easy to hack coming from a C/Java/C# background.

I always found interesting that Mono could have been a good thing for Gnome and because of the Microsoft influence in the language (or .NET platform, I'm no expert) it never happened.

EDIT: ate a word

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.

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

Thanks, I didn't see that.

I think it's more important that it's prohibitive to play around with it or produce open source software.

Not every app has to be beautiful and super-usable though (most business/productivity apps).

If an app can achieve 80% of the usability cross-platform without doing much tweak, I'd say that's a good investment from the publisher perspective.

Well, if you really want to have a native looking experience (even though it seems like apps look more and more different from one another, and increasingly less consistent), you can do that in Java, too, and with probably less work, and for free with world-class tools. I run NetBeans on my mac and it looks and behaves quite natively. Far from mediocre, I'd say.

I agree with you, but for native development, I think I'd rather use a native language---something compiled like Go or D. I do love C# and Python for my own home projects, but for apps that I distribute to others, I don't want to have to ship half of my computer with my app. I'd like to separate logic from UI, write the shared logic, add a platform-specific UI (calling native OS APIs), add a few platform-specific features (provided by the native OS) so no platform-exclusive competitor has any advantage over me, compile and statically-link (only what I need, not a massive runtime) and ship. Like language localization, this process would be repeated for each attractive platform---small, fast, fully native on each platform but with most of the code shared across platforms.

You can do this today with C, but I'd sure rather work in something more modern but which didn't require dragging around half an OS worth of runtime infrastructure. Something more like Go or D, I imagine, if they ever get any traction as client ("desktop") languages.

We've been surprised to discover some customers running Java code on iOS devices uses iKVM and Xamarin. So it seems to work.

Embedded Chromium may work for simple stuff but I questioned it for a more complex desktop app (e.g.: http://almworks.com/jiraclient/) from development, feature-rich, and maintainability perspective.

Oh, I understand entirely. To a large company a $999 license is practically a rounding error given expenditures on other products out there.

I don't have any great suggestions on how you can fix it, just a lament :)

That makes sense, here's another idea. At my day job the price of your product is perfect. Its an enterprise app that we want to support on all 3 mobile platforms, which we sell for $5k a pop (and another $200k * N in hardware). $600 is actually cheap (though so is my company, so we probably wouldn't pay more than $1k).

On the other hand, at home I couldn't afford more then $200. When I make an app at home, its for my own fun.

Instead of trying to satisfy both situations in one model, have you considered licensing per app? Every computer I develop on has an internet connection, so i'd be okay having to connect to your server to compile. I'd even be okay with having subsets of the framework licensed separately if it means I can get it cheaper at home.

I'd love to see Xamarin grow enough to offer the dev-tools for free. Obviously that'd mean making money off of something other than dev-tool sales. I can think of lots of ways you could use Mono to break out of that market. Any plans to move in this direction?

What about a pricing model similar to what [ncunch](http://www.ncrunch.net/) is doing?

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.

11) A huge supply of cheap, replaceable programmers.

Should be...

9) A large ecosystem of interoperating JVM languages, from Java-like (Kotlin, Ceylon, Fantom), Ruby/Python like (JRuby, Jython, Groovy), to Haskell like (Scala), to Lisps (Clojure).

That depends on the app-developer experience building GUI. Maybe most Java developers aren't that sensitive when it comes to GUI (or maybe it's a culture thing).

Having said that, not all apps have to be excellent 100% in terms of usability and beautiful-UI. Once I step out from the HN-bubble a bit I'm starting to see people using ugly but usable and solved business problems type of app written in anything from Tcl/TK, Java, Qt, Pascal, etc.

I don't know. I spend most of my time working with NetBeans on a mac, and it's just as pretty as Keynote, while more responsive and stable. So, yeah, NetBeans, a huge Java Swing application, provides a better experience on a mac than Keynote.

In this case the experience looks slightly different but works pretty much as expected. In other terms, the Java apps tend not to be the ones that piss me off on a regular basis.

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.