8 ms·

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

192 points by evanw 14y ago

LaSombra 14y ago
This might be the final blow to Java on the desktop.
- snuze 14y ago
  As much as I loathe Java, this is just wishful thinking.
- jbigelow76 14y ago
  While I wouldn't shed any tears to see Java disappear from the desktop, it has a massive presence in the Enterprise and that is not due to large deployments of Macs.
- colkassad 14y ago
  At a $1,000 a license? I don't think so.
  - profquail 14y ago
    That's for an enterprise-level license -- the 'professional' license is $399: https://store.xamarin.com/ https://store.xamarin.com/
    - colkassad 14y ago
      Thanks, I didn't see that.
  - akmiller 14y ago
    $1,000 seems pretty meager to me. If I can share well over 50% of my code across multiple platforms then that is code that I don't have to rewrite in another language. If that 50% takes more than 10 hours to reproduce (allocating my time at $100.00/hr) then it is well worth the expense. That doesn't even factor in the time saved in maintaining the application going forward. Granted, if you are just building a small application that you don't plan to support multiple platforms then that price would seem steep.
    - lucian1900 14y ago
      I think it's more important that it's prohibitive to play around with it or produce open source software.
      - akmiller 14y ago
        But you can download it and play around with it for free.
        lucian1900 14y ago
        Only in the emulator. I think that's the problem.
- TheEskimo 14y ago
  Not at all. This offers a completely different solution than java. With java, you write once and run on everything. This lets you write C# on OS X, but it won't compile and run on Windows or Linux. Windows software can't be as easily ported to OS X either, the entire GUI, at the least, will have to be rewritten. I would argue that Python would make more sense as a java-killer. It has the write once, run everywhere thing down much better (though still not good enough) than this. Java is not going anywhere, sadly, and the linked product does not offer a compelling reason to believe that it will kill anything. All I see happening is that people who use mono now will potentially switch to this; honestly this isn't really ground breaking.
  - natfriedman 14y ago
    Yes, but write-once-run-anywhere solutions deliver mediocre user experiences on every platform. You don't want your Mac app to look anything like your Windows 8 app. With Xamarin you separate the presentation layer of your app from the rest of the app, and the only thing you're rewriting from platform to platform is the UI. Typically this is only about 25% of the code (though of course it can vary). This is how our customers do it on Android, iOS and Windows, and now they can extend their apps to Mac and still deliver an amazing Mac app.
    - edwinnathaniel 14y ago
      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.
      - migueldeicaza 14y ago
        Agreed, not every app has to be done in that way, and for that there are plenty of alternative solutions. From HTML to Java, to Gtk# and a dozen more. This is a set of tools for developers that need to take advantage of native APIs, either for the UI, accessing the advanced audio features in OSX, accessing Darwin features, integrating with StoreKit, iCloud, Apple's OpenGL extensions, SceneKit, Bluetooth and those sorts of things from C#.
- untog 14y ago
  It costs $399 for an individual license, so there is a cost barrier. I balked at the cost of MonoTouch, but since playing around with it, I've got to say- I think it'll be worth the money. I just wish it was a little more affordable to hobbyist developers like myself. EDIT: I just noticed that they had a 25% Black Friday offer. Damn.
  - natfriedman 14y ago
    Thanks for the feedback. We definitely have two classes of customers - businesses and professional developers who can't believe how cheap our products are relative to the value they're receiving, and hobbyists who are more price-sensitive. It's tricky to balance these two.
    - untog 14y ago
      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 :)
    - swalsh 14y ago
      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.
      - natfriedman 14y ago
        Some of our competitors have done this and we've received very negative feedback from their customers about per-app, per-user, and royalty-based pricing. Also not sure it makes sense to create a price incentive to bundle a bunch of functionality into a single app. We like having simple, fair, obvious pricing. Even if it means leaving some money on the table.
- QuantumGuy 14y ago
  If Java is a terrible language and horribly designed then why do people still use it?
  - funnydeveloper 14y ago
    if you dont like itdont use, mother fucker
  - cgh 14y ago
    Speaking purely from the server-side of things, Java (the ecosystem) has great libraries and frameworks for webapps and middleware. It also has OSGi, which solves a unique set of problems that aren't addressed by any other language ecosystem that I know of. This is all in spite of Java the language, which is kind of a lame duck. Java 8 should improve things if it ever gets released.
    - deleted 14y ago
      [deleted]
  - pretoriusB 14y ago
    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 14y ago
      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.
- flogic 14y ago
  Personally, I think computing power has hit the point where Java desktop apps and applets aren't that big a deal. I've got one running on my desktop right now. It runs for day's on end without being a significant burden to the rest of the system.
  - pretoriusB 14y ago
    It's the quality of the experience, GUI, not just the resource-hoging of Java Desktop app. And even for that "It runs for day's on end without being a significant burden to the rest of the system" is hardly something to write home about.
    - edwinnathaniel 14y ago
      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.
    - pron 14y ago
      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.
      - pretoriusB 14y ago
        >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. Just as pretty as Keynote? I beg to differ. NetBeans (and Eclipse, IDEA) always hit the "uncanny valley" for me (and Eclipse is even using Cocoa!). Not looking right at all for the platform, and with BS divergent behaviour on lots of UI controls. On top of it, all three are quite laggy (gotten a little better with huge memory these days and SSDs, but still, if you need 4GB and solid state to get something to run fast, well...). In no way I would say NetBeans provides a better experience on a Mac than Keynote.
jbigelow76 14y ago
Xamarin does some impressive work. They are becoming to C# what PhoneGap is to Javascript/HTML (license fee not withstanding).
lucian1900 14y ago
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 14y ago
  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 14y ago
    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?
    - deleted 14y ago
      [deleted]
  - jevinskie 14y ago
    Yes we support Linux at our shop and testing/packaging is difficult. Doubly so for embedded customers that frequently want to use old/obscure distros (probably due to a cross tool chain requirement).
- untog 14y ago
  The other problem is the lack of linux support for their SDK. Seems rather odd, considering Mono's roots. I suspect that they make the vast majority of their profit on MonoTouch (Mono for Android is great, but Java and C# are similar enough that there is a lower barrier). With that in mind, there isn't much point in focusing on Linux- you can't develop for Mac or iOS on it.
  - natfriedman 14y ago
j_s 14y ago
So MonoMac is going pro? Glad to see it will be supported. http://www.mono-project.com/MonoMac 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.
Kluny 14y ago
I used Xamarin's Stripe library a few weeks ago. Super nice stuff.
- natfriedman 14y ago
  Cool! We were an early user of stripe, launching with it on our store in July of 2011. Stripe is great.
deleted 14y ago
[deleted]
georgemcbay 14y ago
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 14y ago
  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.
  - dested 14y ago
    Can you go into some issues with the editor?
    - Itaxpica 14y ago
      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).
    - eropple 14y ago
      -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.
mjs 14y ago
Does this use "native" OS X components?
- CodeCube 14y ago
  Yeah, they just bind to the existing libraries, so you end up using all of the native tools.
azakai 14y ago
Cool stuff. Now how about running C# apps on the web? :)
- CodeCube 14y ago
  Not sure if kidding, or serious :P http://asp.net/mvc http://asp.net/mvc
- account_taken 14y ago
  Used to be silverlight, moonlight? Didn't catch on.
- eatsleepdrink 14y ago
  You can also do javascript with it. I can't speak to it personally but friends have used Script# (http://scriptsharp.com/ http://scriptsharp.com/) for client-side javascript with good results. Never heard of anyone attempting node.js with it... yet.
  - azakai 14y ago
    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.
  - danek 14y ago
    scriptsharp: I saw it used/had to help maintain for a rather big project...never again... :(
bronxbomber92 14y ago
Where does this leave MonoMac? http://www.mono-project.com/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 14y ago
  The plan is to continue to contribute to MonoMac and it will remain free/open source.
lubos 14y ago
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 https://github.com/picoe/eto
- natfriedman 14y ago
  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 http://docs.xamarin.com/mac/guides
  - eropple 14y ago
    MonoMac appears to be ASL/X11. MacCore too. https://github.com/mono/monomac 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 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 14y ago
      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.
chrisringrose 14y ago
C#'s okay and all... But what's wrong with Objective C?
- bratsche 14y ago
  Nothing's wrong with Objective-C. But if you're interested in sharing some code to do cross-platform apps Xamarin makes it easier to do so with C#. You might write a layer to do API and data management/storage and general business logic and then share that code between Mac, Windows, iPhone, Android, Windows Phone, and Linux. It would still be a lot of work because they don't try to abstract any of the UI or other things for you (and imo, they shouldn't). But if your app fits into this kind of design, and if you like C#, then it could be very valuable.
  - pjmlp 14y ago
    I'll just keep doing C++.
- migueldeicaza 14y ago
  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.
nanijoe 14y ago
Does this allow you to develop Windows Apps using a Mac? Or is this mobile app specific?
- bibinou 14y ago
  It allows you to build Mac OS X apps using the C# language.
sev 14y ago
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 14y ago
  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).
mapgrep 14y ago
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/ http://www.apple.com/hotnews/thoughts-on-flash/ FWIW, I've always thought this was an overly broad generalization.
- pudquick 14y ago
  You must have missed the part where Apple relented on that: http://news.cnet.com/8301-30685_3-20015954-264.html http://news.cnet.com/8301-30685_3-20015954-264.html http://www.apple.com/pr/library/2010/09/09Statement-by-Apple-on-App-Store-Review-Guidelines.html http://www.apple.com/pr/library/2010/09/09Statement-by-Apple... "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 14y ago
    There's still no flash on my iPad though.
    - eropple 14y ago
danabramov 14y ago
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 14y ago
  - 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 14y ago
    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-monotouch-gc http://stackoverflow.com/questions/13058521/is-this-a-bug-in... http://stackoverflow.com/questions/13064669/why-cant-monotouch-gc-kill-managed-objects-with-refcount-1 http://stackoverflow.com/questions/13064669/why-cant-monotou... This is a great screencast I wish I saw before I started coding in MonoTouch: http://forums.xamarin.com/discussion/33/finding-memory-leaks-in-your-apps http://forums.xamarin.com/discussion/33/finding-memory-leaks... 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 14y ago
By the way, our MonoTouch app just got approved by Apple an hour ago. Sweet.
kevin_rubyhouse 14y ago
How is something like this done?

192 points by evanw 14y ago

LaSombra 14y ago

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

snuze 14y ago
As much as I loathe Java, this is just wishful thinking.
jbigelow76 14y ago
While I wouldn't shed any tears to see Java disappear from the desktop, it has a massive presence in the Enterprise and that is not due to large deployments of Macs.
colkassad 14y ago
At a $1,000 a license? I don't think so.
- profquail 14y ago
  That's for an enterprise-level license -- the 'professional' license is $399: https://store.xamarin.com/ https://store.xamarin.com/
  - colkassad 14y ago
    Thanks, I didn't see that.
- akmiller 14y ago
  $1,000 seems pretty meager to me. If I can share well over 50% of my code across multiple platforms then that is code that I don't have to rewrite in another language. If that 50% takes more than 10 hours to reproduce (allocating my time at $100.00/hr) then it is well worth the expense. That doesn't even factor in the time saved in maintaining the application going forward. Granted, if you are just building a small application that you don't plan to support multiple platforms then that price would seem steep.
  - lucian1900 14y ago
    I think it's more important that it's prohibitive to play around with it or produce open source software.
    - akmiller 14y ago
      But you can download it and play around with it for free.
      - lucian1900 14y ago
        Only in the emulator. I think that's the problem.
TheEskimo 14y ago
Not at all. This offers a completely different solution than java. With java, you write once and run on everything. This lets you write C# on OS X, but it won't compile and run on Windows or Linux. Windows software can't be as easily ported to OS X either, the entire GUI, at the least, will have to be rewritten. I would argue that Python would make more sense as a java-killer. It has the write once, run everywhere thing down much better (though still not good enough) than this. Java is not going anywhere, sadly, and the linked product does not offer a compelling reason to believe that it will kill anything. All I see happening is that people who use mono now will potentially switch to this; honestly this isn't really ground breaking.
- natfriedman 14y ago
  Yes, but write-once-run-anywhere solutions deliver mediocre user experiences on every platform. You don't want your Mac app to look anything like your Windows 8 app. With Xamarin you separate the presentation layer of your app from the rest of the app, and the only thing you're rewriting from platform to platform is the UI. Typically this is only about 25% of the code (though of course it can vary). This is how our customers do it on Android, iOS and Windows, and now they can extend their apps to Mac and still deliver an amazing Mac app.
  - edwinnathaniel 14y ago
    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.
    - migueldeicaza 14y ago
      Agreed, not every app has to be done in that way, and for that there are plenty of alternative solutions. From HTML to Java, to Gtk# and a dozen more. This is a set of tools for developers that need to take advantage of native APIs, either for the UI, accessing the advanced audio features in OSX, accessing Darwin features, integrating with StoreKit, iCloud, Apple's OpenGL extensions, SceneKit, Bluetooth and those sorts of things from C#.
untog 14y ago
It costs $399 for an individual license, so there is a cost barrier. I balked at the cost of MonoTouch, but since playing around with it, I've got to say- I think it'll be worth the money. I just wish it was a little more affordable to hobbyist developers like myself. EDIT: I just noticed that they had a 25% Black Friday offer. Damn.
- natfriedman 14y ago
  Thanks for the feedback. We definitely have two classes of customers - businesses and professional developers who can't believe how cheap our products are relative to the value they're receiving, and hobbyists who are more price-sensitive. It's tricky to balance these two.
  - untog 14y ago
    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 :)
  - swalsh 14y ago
    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.
    - natfriedman 14y ago
      Some of our competitors have done this and we've received very negative feedback from their customers about per-app, per-user, and royalty-based pricing. Also not sure it makes sense to create a price incentive to bundle a bunch of functionality into a single app. We like having simple, fair, obvious pricing. Even if it means leaving some money on the table.
QuantumGuy 14y ago
If Java is a terrible language and horribly designed then why do people still use it?
- funnydeveloper 14y ago
  if you dont like itdont use, mother fucker
- cgh 14y ago
  Speaking purely from the server-side of things, Java (the ecosystem) has great libraries and frameworks for webapps and middleware. It also has OSGi, which solves a unique set of problems that aren't addressed by any other language ecosystem that I know of. This is all in spite of Java the language, which is kind of a lame duck. Java 8 should improve things if it ever gets released.
  - deleted 14y ago
    [deleted]
- pretoriusB 14y ago
  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 14y ago
    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.
flogic 14y ago
Personally, I think computing power has hit the point where Java desktop apps and applets aren't that big a deal. I've got one running on my desktop right now. It runs for day's on end without being a significant burden to the rest of the system.
- pretoriusB 14y ago
  It's the quality of the experience, GUI, not just the resource-hoging of Java Desktop app. And even for that "It runs for day's on end without being a significant burden to the rest of the system" is hardly something to write home about.
  - edwinnathaniel 14y ago
    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.
  - pron 14y ago
    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.
    - pretoriusB 14y ago
      >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. Just as pretty as Keynote? I beg to differ. NetBeans (and Eclipse, IDEA) always hit the "uncanny valley" for me (and Eclipse is even using Cocoa!). Not looking right at all for the platform, and with BS divergent behaviour on lots of UI controls. On top of it, all three are quite laggy (gotten a little better with huge memory these days and SSDs, but still, if you need 4GB and solid state to get something to run fast, well...). In no way I would say NetBeans provides a better experience on a Mac than Keynote.

jbigelow76 14y ago

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

lucian1900 14y ago

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 14y ago
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 14y ago
  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?
  - deleted 14y ago
    [deleted]
- jevinskie 14y ago
  Yes we support Linux at our shop and testing/packaging is difficult. Doubly so for embedded customers that frequently want to use old/obscure distros (probably due to a cross tool chain requirement).
untog 14y ago
The other problem is the lack of linux support for their SDK. Seems rather odd, considering Mono's roots. I suspect that they make the vast majority of their profit on MonoTouch (Mono for Android is great, but Java and C# are similar enough that there is a lower barrier). With that in mind, there isn't much point in focusing on Linux- you can't develop for Mac or iOS on it.
- natfriedman 14y ago

j_s 14y ago

So MonoMac is going pro? Glad to see it will be supported. http://www.mono-project.com/MonoMac 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.

Kluny 14y ago

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

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

deleted 14y ago

[deleted]

georgemcbay 14y ago

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 14y ago
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.
- dested 14y ago
  Can you go into some issues with the editor?
  - Itaxpica 14y ago
    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).
  - eropple 14y ago
    -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.

mjs 14y ago

Does this use "native" OS X components?

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

azakai 14y ago

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

CodeCube 14y ago
Not sure if kidding, or serious :P http://asp.net/mvc http://asp.net/mvc
account_taken 14y ago
Used to be silverlight, moonlight? Didn't catch on.
eatsleepdrink 14y ago
You can also do javascript with it. I can't speak to it personally but friends have used Script# (http://scriptsharp.com/ http://scriptsharp.com/) for client-side javascript with good results. Never heard of anyone attempting node.js with it... yet.
- azakai 14y ago
  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.
- danek 14y ago
  scriptsharp: I saw it used/had to help maintain for a rather big project...never again... :(

bronxbomber92 14y ago

Where does this leave MonoMac? http://www.mono-project.com/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 14y ago
The plan is to continue to contribute to MonoMac and it will remain free/open source.

lubos 14y ago

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 https://github.com/picoe/eto

natfriedman 14y ago
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 http://docs.xamarin.com/mac/guides
- eropple 14y ago
  MonoMac appears to be ASL/X11. MacCore too. https://github.com/mono/monomac 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 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 14y ago
    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.

chrisringrose 14y ago

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

bratsche 14y ago
Nothing's wrong with Objective-C. But if you're interested in sharing some code to do cross-platform apps Xamarin makes it easier to do so with C#. You might write a layer to do API and data management/storage and general business logic and then share that code between Mac, Windows, iPhone, Android, Windows Phone, and Linux. It would still be a lot of work because they don't try to abstract any of the UI or other things for you (and imo, they shouldn't). But if your app fits into this kind of design, and if you like C#, then it could be very valuable.
- pjmlp 14y ago
  I'll just keep doing C++.
migueldeicaza 14y ago
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.

nanijoe 14y ago

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

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

sev 14y ago

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 14y ago
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).

mapgrep 14y ago

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/ http://www.apple.com/hotnews/thoughts-on-flash/ FWIW, I've always thought this was an overly broad generalization.

pudquick 14y ago
You must have missed the part where Apple relented on that: http://news.cnet.com/8301-30685_3-20015954-264.html http://news.cnet.com/8301-30685_3-20015954-264.html http://www.apple.com/pr/library/2010/09/09Statement-by-Apple-on-App-Store-Review-Guidelines.html http://www.apple.com/pr/library/2010/09/09Statement-by-Apple... "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 14y ago
  There's still no flash on my iPad though.
  - eropple 14y ago

danabramov 14y ago

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 14y ago
- 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 14y ago
  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-monotouch-gc http://stackoverflow.com/questions/13058521/is-this-a-bug-in... http://stackoverflow.com/questions/13064669/why-cant-monotouch-gc-kill-managed-objects-with-refcount-1 http://stackoverflow.com/questions/13064669/why-cant-monotou... This is a great screencast I wish I saw before I started coding in MonoTouch: http://forums.xamarin.com/discussion/33/finding-memory-leaks-in-your-apps http://forums.xamarin.com/discussion/33/finding-memory-leaks... 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 14y ago

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

kevin_rubyhouse 14y ago

How is something like this done?