Your C# App on 66 Million Macs: Announcing Xamarin.Mac(blog.xamarin.com) |
Your C# App on 66 Million Macs: Announcing Xamarin.Mac(blog.xamarin.com) |
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.
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#.
Miguel is a very smart man and completely clueless at the same time.
Try downloading the evaluation version. It allows you to test with the simulator, and at least gives you a clue as to whether you might want to spend $399 on it. Of course, if there's no chance of that ever being the case it won't be a productive use of time.
- 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.
The other problem is the lack of linux support for their SDK. Seems rather odd, considering Mono's roots.
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
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
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?
How do you feel about Mono Xwt? - https://github.com/mono/xwt
"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.
http://news.cnet.com/8301-30685_3-20015954-264.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)
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?
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).
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.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.
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.
- 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
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?
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 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/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...
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.
Perhaps more of your customers would use Linux for Xamarin stuff if it was available?
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.
Didn't Mono get a lot of hate and vitriol from the Linux crowd over their support for C# and .NET on Linux and then was pulled from Ubuntu's default install because of it? I can understand why they would be shy about support if all they got were brickbats and hate mail.
http://np237.livejournal.com/24065.html
http://techrights.org/2008/03/24/mono-danger-to-linux/
http://techrights.org/2011/11/04/uds-on-mono/
http://www.itworld.com/it-managementstrategy/222227/bansheeg...
http://linux.slashdot.org/story/09/06/15/1251228/Mono-Squeez...
The first link is a very entertaining read.
EDIT: I just noticed that they had a 25% Black Friday offer. Damn.
Well, being free never made Java on the Desktop go anywhere, anyway.
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.
Granted, if you are just building a small application that you don't plan to support multiple platforms then that price would seem steep.
Many still write code without thinking one second about performance.
Java isn't C, but if you code thinking about performance it is possible to write quite usable applications for many use cases.
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.
It's a lowest common denominator.
It has a couple of very good free cross-platform ide's.
It's write once -run everywhere to a certain extent. While java gui's may be a bit ugly they let you run self contained apps with no dependencies except for the jvm(installed on more the 1/2 of all pcs).
The vm (at least the main sun/oracle hotspot / openjdk) has a world class jit and gc.
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.
1) Tons of experienced and battle-tested people in the ecosystems
2) Standards that keep improving
It's a dual-edge sword thingie, on one hand standards are good for stability but bad because sometimes it slow innovation down. Having said that, the Java ecosystems typically have one strong alternative outside the standard so your choices, in most cases, come down to 2: use what comes from SUN/Oracle or use the leading open source alternative solution. Simple.
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
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)
-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.
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.
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
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.
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).
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.
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.
I don't have any great suggestions on how you can fix it, just a lament :)
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.
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.
Now that we are launching a product, we offer the license as part of Xamarin.Mac.
I will update the page accordingly.
Is the licensing for MonoMac/MacCore remaining as-is?
We will also continue to maintain it, as it shares most of the code for Xamarin.Mac
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.
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.
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#.
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.
The dynamic library runtimes for other languages can also be relatively big. Just my PC has around 10 versions of the C++ runtime.
Maybe you are more looking into distribution of statically compiled code?
That would be enough for a useful "free for free software, pay for commercial development" model.
(Maybe R# for MonoDevelop? One can dream...)
Take a look at Mono for Android, for example. It uses a VS plugin instead of MonoDevelop.
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.
Older machine? Overactive anti-virus or something causing file I/O pain?
I'd pay for MonoTouch like-right-now, even though the project I really want it for isn't near ready for it, if I could write in VS, press a button, and have it build and deploy on my Mac.