I've been using Xamarin forms a lot now.
They are miles from being as good as native development.
Soooo many bugs in xamarin itself.
When using Xamarin forms, you will not provide as good of product as you would native.
There are also very little controls.
Xaml works, but is really slow. And the layout is SOOO inefficient !
But the problem is even greater, you can't merge Android and iOS layout passes.
On one platform, measuring is really fast and the other really slow ...
Xamarin forms can't compensate and give native performance to this.
They don't even have listview recycling ...
One developer even said "RelativeLayout is probably best for you here and can do this" to the question what the fastest layout is.
For Android, this is the WORST layout possible.
Anyway, you will spend a LOT of time fixing Xamarin bugs and developer their controls.
However, I LOVED .net functions, especially LINQ !
Anyway, development was really slow and performance is no were near to native.
So if you want to deliver a simple app to a client and be cross platform, then sure. But don't try to maintain that app, you will regret it.
I'm afraid the whole Xamarin thing won't solve "cross-platform" which isn't a real problem but sure.
Its just another horse that Microsoft is betting on.
Oh and for the people that will have to do it anyway.
Use Resharper ! Xaml IntelliSense !!! It will help you a lot.
I'm sorry I'm so negative, but it was genuinely the worst development I had.
Hey, I'm the CEO of Xamarin. I'm really sorry that you had a bad experience with Xamarin.Forms.
Did you try doing native development with Xamarin? I do want to be clear that Xamarin.Forms is not Xamarin. It's a library that we built to help people quickly write very simple, data-entry style apps. That's why it's called "Forms." It's not intended to be highly performant or to replicate all the per-platform APIs in Xamarin.iOS and Xamarin.Android. For that, you should use the native APIs. We have a little more information about that here:
Before release, we had internally called Xamarin.Forms "duplo," to emphasize that it was for childishly-simple apps and screens, but we couldn't use that (trademarked) name for the release, unfortunately.
That said, of course we still want to address all the issues that you found with Forms. Would you mind dropping me an email - nat@xamarin.com?
Changing the name is a necessity if you want to have a good looking program.
Consider an API like "drawString:" and "drawString:atPoint:" and "drawString:atPoint:withFont:". These are acceptable in the world of objective-c, because they are used with parameters, but they are not really suitable in this way in C#. So we map the API names to forms that are idiomatically correct in C#.
In the above case, we would like map those to a single "DrawString" method name with three different overloads. But this depends on the case. In general, we follow the .NET Framework Design Guidelines for our naming conventions.
As for forms, you are correct, we built it for a class of users that had different requirements than those that are building consumer applications.
Now, while I am the first one to tell developers to use our native APIs to create great consumer experiences, just last week I ran into a gorgeous looking app and only later I discovered that the gorgeous UI was actually built entirely with Forms, even the animations.
More importantly, the app was built on record time by a single developer. I could not believe it (need to ask the customer for permission to disclose that their product is built with our product).
So I walked away with a new insight: that good UIs require good taste and someone passionate enough to make the UIs happen and that even something that we intended for mostly business scenarios can create great UI experiences.
thx for responding my comment. after read your explanation, i agree with your argument about xamarin form. it just need more feature and more sample. Xamarin sample layout is not esthetic. You should look at telerik example. And last one, when feature listview drag and drop swap row available on android ?
Hi, I am not affiliated with Xamarin but I have been using Xamarin in production for the last two years on many applications and could not imagine doing native development in any other way.
Two weeks ago a enterprise company that previously was "iPhone/iPad only" from the top-down by a board level mandate has started seriously considering moving over to Android for purely handset cost reasons. I knew this would eventually happen and deliberately designed/developed the application using the Xamarin platform as a way to reduce risk/hedge bets.
If the application was not developed using Xamarin then the enterprise company would be facing a complete rewrite of the application in another language whereby the engineering costs to achieve this outcome would outweigh the savings and re-implementing the functionality would introduce substantial product quality/project risks.
Now "all that is required" is to start work on a Android user experience, implement it and then sew it up against the core library. It also means that developers can concurrently patch bugs + ship features to both platforms during the migration phase.
Anyway there seems to be a quite of bit of confusion that Xamarin.Forms == Xamarin and this is not the case.
Xamarin.Forms is a package that runs on top of the Xamarin platform that provides a DSL to rapidly create CRUD enterprise applications that spits out the equivalent native user interface implementation depending on which platform you run on. It is extendable and becoming highly customizable. Can't wait until they drop the "sealed" modifiers - hint, hint, nudge, nudge @natfriedman!
Xamarin itself is a way to use either F# or C# on Android and iOS. All of the native platform specific API's you're used are available to you to use in any way you see fit. Admitely the there has been some minor naming changes to be in accordance with the http://www.amazon.com/Framework-Design-Guidelines-Convention... but if your coming from a .NET background then it makes complete sense.
That said if you're coming directly from .NET, thinking that you can ship iOS or Android without learning the domain knowledge of each platform then you're in for a royally rude awakening. Xamarin does not abstract away the differences between the platforms - ie. push notifications, application suspension or any of that jazz.
With the correct software architecture you can write your business logic, data transport, caching and persistence layer once and share it between every non-web platform in existence - Android, iOS, Windows Phone and desktop applications on Linux, Mac & Windows/WPF/Store.
Step one in decent architecture is to divide your application up into a Core library and use interfaces to bait and switch in a different concrete implementation depending on what platform is running your application. For more info see: http://log.paulbetts.org/the-bait-and-switch-pcl-trick/
Step two is to use a solid MVVM framework such as http://reactiveui.net which is a functional reactive programming framework that uses the Reactive Extensions for .NET to create elegant, testable User Interfaces that run on any mobile or desktop platform. Supports Xamarin.iOS, Xamarin.Android, Xamarin.Mac, WPF, Windows Forms, Windows Phone 8 and Windows Store apps. It is the framework that powers GitHub for Windows and various other undisclosed projects ;-)
Whilst it may require more work than Xamarin Forms, MvvmCross is a way of creating cross-platform applications using Xamarin without any of the issues you've documented above.
MvvmCross is pretty legit. I felt that it really made Xamarin worthwhile. I found it quite a bit easier to keep the platform specific code to a minimum and when I needed to write it it was abstracted out as much as possible.
> I'm afraid the whole Xamarin thing won't solve "cross-platform" which isn't a real problem but sure. Its just another horse that Microsoft is betting on.
Why do you say "cross-platform" isn't a real problem? It sure seems to me like mobile app developers need a way to share large chunks of their code, and possibly even some UI code, between platforms while still delivering native apps.
I believe it is recommended to use one relative layout instead of multiple linear layouts, because depth quickly becomes slower than the more complex measurements needed for a relative layout.
I find layouting on Android really bad TBH and there are so many presentations and guidelines on what (not) to do.
Its hardly more performant. But here is some more info: https://www.youtube.com/watch?v=NYtB6mlu7vA&t=1m41s
Yes, the documentation is far from good.
But the larger problem I find is that the 2 platforms are made from opposites points, and I don't see Xamarin glueing it together as magic.
But you are right, the layouts and measurements even differ per api level as they get optimisations and are really complex. It would be awesome if Xamarin could combine both platforms native performs, but I don't see that happening :(
I've been working for half a year with Xamarin Forms. I Think using Xamarin is the way to go, there is no need to re-code something for 3 different platforms when you can just have a shared codebase. Tools like Cordova and Phonegap don't work. They produce a very crappy experience that doesn't use the native OS functions, doesn't look and feel native, feels slow and has many bugs (for example they can't use the hardware back button).
So Xamarin can create real native apps, which is a HUGE advantage over Cordova/Phonegap/others, but there are also serious downsides:
1) It's BUGGY. Many components have bugs, and the code often behaves in very very weird ways (I had exceptions not being caught by catch blocks for example), many debugger functions don't work properly with mono (like locals) and very, very often exceptions are thrown without ANY indication what caused them or where they occurred exactly.
2) You a limited in the features you can use because it's a wrapper (as mentioned in OPs post).
3) Documentation sucks and is very limited. It's getting better (mostly because of StackOverflow), but it's still not sufficient.
4) It has XAML which is very nice combined with MVVM, but the XAML implementation sucks. It doesn't have intellisense and it's just generally very awkward.
I don't think the 'big cost' is a valid argument against Xamarin. If you can develop 1 app for $40k where you would normally have to develop 2 or 3 apps for $30k each, that's a BIG win and Xamarin's costs are negligible.
Hey, Xamarin CEO here, thanks for your feedback. A couple comments/questions on the issues you raised.
1) We aren't aware of any debugger issues like this. Is it possible you were debugging optimized code which had the local variables optimized away? Similarly, when an uncaught exception is thrown, it comes with a stack trace with line numbers. Were you not getting these?
2) Xamarin does map the entire set of iOS and Android APIs into C#, so yes it is a "wrapper," but you should NOT be limited in what native features you can use. We literally cover almost 100% of the entire set of native APIs. What limitations were you running into?
4) We do include XAML intellisense in Xamarin Studio. To get it in Visual Studio you have to install an extension: http://www.cazzulino.com/mobileessentials.html This will be included by default in a future version of Xamarin.
I'm sorry about the trouble you had, and I'd like to get to the bottom of those issues. Please feel free to contact me at nat@xamarin.com.
Our app Pacifica (http://thinkpacifica.com) is built with Cordova and the Ionic Framework. It's far from a crappy experience. I think that too often people pick these frameworks and assume that it's a substitute for good design. You still need to put in the effort.
There's also the fact that the bar is a bit lower to get an app finished and released with something like Ionic. So you might see more apps that aren't quite up to par, but that doesn't mean that it isn't possible to create something beautiful with them.
I gave your app a try. I think its fairly good. It was a -bit- choppy when clicking on sign up, but once signed in, I couldn't tell it apart from a native app. The 'swipe to move to next screen' was pretty good too.
> They produce a very crappy experience that doesn't use the native OS functions, doesn't look and feel native, feels slow and has many bugs (for example they can't use the hardware back button)
Can you elaborate on what you mean here?
Sure, the apps never feel completely native but you can still invoke native features including the back button on Android, reuse the same code to make a web app and while bugs happen it isn't any worse than trying to create a cross-browser web app (which is essentially what you're writing).
Pretty much every software development choice is a trade off and PhoneGap is a good one sometimes.
I've used PhoneGap. There is a huge conflation of "feeling native" and the "native controls" aspect of PhoneGap's features. Can you access the camera on a phone using PhoneGap? Sure, but you know those apps you use every day? They are polished and you can't polish with PhoneGap. Scrolling is snappy, navigation doesn't lag, etc. etc.
But you're dealing with trade-offs unless you have unlimited resources. If you want an iOS, Android and web app as soon as possible with a decent UI on a limited budget, PhoneGap is hard to compete with. If you want the slickest possible iOS UI, native is likely the way to go but it costs significantly more resources if you want to support other platforms as well. You're not getting anything for free and you have to decide what you want to spend your resources on.
So how would you rate a PhoneGap UX compared to a native UX? I agree the latter is better but I don't see the former as significantly worse. If you have limited resources, you've usually got the choice between supporting multiple platforms with a decent UX or a limited number of platforms with a great UX.
Having an app that isn't "significantly worse" can be the difference of having 5,000 or 1 million users. While it's impossible to prove, there is loads of evidence to suggest even just 200ms of UI delay can cause UX problems. [0]
Your comment does bring up a good point however, I've struggled to prove any of this with any scientific manner. I wish there was, because it would selling native solutions so much easier. The only proof really is the fact that the most downloaded apps in the world all use native, and many (FB and LI come to my mind) tried the hybrid solution and it failed miserably.[1][2]
Obviously I'm not going to advocate apps that have 200ms delays no matter what framework you use. It's also possible to write laggy and bad native UIs as well.
Was the Facebook app really a failure that made the difference between 5000 and 1 million users? I think Facebook is an example of a company that has unlimited resources to throw at app development and can afford to spend a lot for even a little better anyways.
My only point is that writing native apps for multiple platforms does not come for free. While usually better than hybrid apps, the development costs need to be considered.
You need to consider that developing two native apps is probably twice the cost of developing one cross-platform app for two platforms.
I think developers are overly aware of the differences between native and non-native apps, and overestimate how much a casual app user cares about a native experience to be honest. I'd love to implement native experiences for all apps I write but I have to take budgets into account.
> I think developers are overly aware of the differences between native and non-native apps, and overestimate how much a casual app user cares about a native experience to be honest.
I would expect the opposite. They may not be able to put a name to the issues or even describe them, but I'd expect average people to show a clear preference for native apps basically every time in a side by side test.
I think developers tend to underestimate how important good UI responsiveness and feel is.
Hey there, I am James Montemagno a developer evangelist at Xamarin. I have been developing native apps with Xamarin for nearly 4 years now across iOS, Android, and of course Windows (I was a customer for 2 years before joining Xamarin). I just wanted to clarify a bit about Xamarin and Xamarin.Forms. It is important to know that Xamarin.Forms is a cross platform UI layer that sits on top of the core Xamarin platform. Using native Xamarin you are still sharing your backend C#/.NET code and then building out native user interfaces for each platform.
The Xamarin.Forms library adds an abstraction over common controls available on iOS, Android, and Windows Phone. Xamarin.Forms is extremely extensible, but it is not for every app, especially if you need a lot of custom UI or API access. For data entry, proofs-of-concept, or other simple apps it is great and we have a guide to help you select: http://cdn1.xamarin.com/Architecture%20Selector.pdf. The nice thing here is that either approach can use a shared-code backend.
I think I can address some of your concerns below:
1.) I would love to know which components you were having issues with and I can work with the team. There are a lot of settings in Visual Studio and Xamarin Studio as far as when to break on exceptions so I would love to help out here.
2.) If you are exclusive to using Xamarin.Forms then yes you will have a limited set of controls, since Xamarin.Forms is a subset of common controls. It is extensible via “CustomRenderers”, but that require some work and if you need a lot of them then it might be worth looking into the native approach without Xamarin.Forms as this approach will automatically give you access to every control on each platform you are creating.
3.) We are always looking to expand our documentation across all of our products and highly recommend checking out our updated developer portal: http://developer.xamarin.com there is a plethora of Xamarin.Forms related documentation as well as http://developer.xamarin.com/guides/cross-platform/xamarin-f... It is pretty extensive, but if there is something missing please please please let us know and we will work with the documentation team to add it. In addition to this documentation we do have a book that has been written by Charles Petzold on Xamarin.Forms that is freely available: http://developer.xamarin.com/guides/cross-platform/xamarin-f...
4.) For XAML intellisense it is built right into Xamarin Studio, for Visual Studio there is an extension that you can install: http://www.cazzulino.com/mobileessentials.html This will be integrated automatically in the future. I apologize that this is tricky to find.
Hopefully this helps out a bit with some of the issues that you have run into, but again please please feel free to email me with any questions, encounter any problems please reach out to us so we know and can fix them. You have my direct line: james@xamarin.com.
What would be the best way to do 2D graphics using Mono? I have an editor project written in WPF, but mostly uses 2D APIs (since...I'm building my own editor, some videos here [1]). Anyways, my only Windows platform dependency is WPF (most of the magic is platform independent), and I'm wondering how to make my app cross platform. The most appropriate I can find is mono.cario, but it doesn't seem to be very active.
> Tools like Cordova and Phonegap don't work. They produce a very crappy experience that doesn't use the native OS functions, doesn't look and feel native, feels slow and has many bugs (for example they can't use the hardware back button).
Have you taken a look at Facebook's new framework, React Native?
Just to be clear (for you or anyone else), React Native is nothing like Cordova or Phonegap - Using Javascript, you instruct React Native to draw native components (UINavigationBar, UIButton etc) with native interactions.
The end user is not touching HTML and CSS. They touch native components with native performance.
Having been building a decent size app (tens of thousands of lines) in Xamarin this really reflects our experience. One particular point is that the memory management is fairly complex under the covers with bridged objects and multiple memory management mechanisms working in parallel, this occasionally rears its head.
Another important point is they do provide a single automation test framework that targets both platforms.
If I was starting the app again I'd be very conflicted whether to use Xamarin vs native, though ReactNative looks very interesting too and doesn't have the complexity of running the full .net stack.
I wonder if RubyMotion is much better when it comes to memory management. According to the website, RubyMotion objects are platform native objects (ObjC objects for iOS/Mac, java objects for Android), so each platform's native memory management scheme applies, rather than having two GC's or GC plus reference counting.
I'd probably use RubyMotion for an upcoming project at work if it had a port to WinRT for Windows universal apps.
Judging by the docs [1], RubyMotion does indeed not seem to use a GC on iOS but instead relies on ref counting, reusing auto-release pools. That means cyclic refs are an issue. You have to explicitely use weak references throughout your code.
They are not on Android, where RubyMotion uses the Dalivk/ART GC.
So, your cross-platform Ruby code has to deal with two different types of memory management systems. I'm not sure this qualifies as a better option to what Xamarin provides.
Great article, we have a similar story but only used Xamarin for 1 iOS app. If I had option to go back I would not chose Xa marin, we would have used native. Main reason being that we now need to add 3 SDKs to our app and none of them are supported in Xamarin, it seems it will be cheaper and more predictable to rewrite to native than implementing SDKs. Porting libraries to Xamarin is possible in theory but in practice major effort and hard to do without access to library code.
Hi there, I'm the CEO of Xamarin. I'm really sorry to hear that you had issues with consuming third-party libraries. This is actually something we've been recently very focused on improving.
First of all, in December we released a new tool called Objective Sharpie that can automatically bind Objective-C libraries into C#:
If you're skilled enough to build the Objective-C library, then you'll be able to use Objective Sharpie to create a C# binding. We also have docs on doing this for Java on developer.xamarin.com.
Some of our customers don't have the time or skill to do this themselves, and so we've recently created a bindings team that wraps third-party native libraries for our customers. Many of these end up published on http://components.xamarin.com/ (there are over 300 components now). But some of them we can't immediately publish because we need to get permission from the original library author to redistribute their library. This is especially true for commercial SDKs. But if you contact us directly, we might be able to give you something.
We also do custom bindings through our support team. This is something that unfortunately we haven't made very obvious. But you can just email support@xamarin.com and we can create a binding for you.
Like I said, this is an area we're pretty focused on. If you have any feedback, please feel free to let me know directly: nat@xamarin.com.
I fear never. We made this question over and over on the forums or via emails but the answer is ever the same: "we have no plans to support linux".
Originally the problem was about "there are too many linux distros!", then when some people suggested to at least support ubuntu as Valve did (and correctly considering the big part of used distros are ubuntu based or related) they went again on "we have no plans to support linux" without futher explainations.
+1 on this... within a year, my main desktop OS will likely be Linux.. right now, I keep an Ubuntu VM in the background and edit in windows (Sublime) via Samba shares in the VM.. running via SSH terminal windows.. mainly because a significant amount of my time was windows dev.. this is shifting as I'm using node/io.js much more. This also means, however that I'm more likely to reach for something like Cordova for apps (you can go a long way with web based apps for many use cases) or React Native.
What would be the point of developing with the Xamarin Platform on Linux? You'd only be able to target Android, not iOS, Mac, or Windows. In that case, one might as well not use Xamarin at all.
To target the full range of mobile devices, one has to have Windows, a Mac, or both anyway. So there doesn't seem to be much advantage to supporting development on Linux.
The point would be to develop on a platform that I like developing on. Either way, there isn't a single platform that you can use that will give you 100% of the available platforms...if you want cross-platform across Android, iOS, Mac, AND Windows, you are going to need a minimum of two computers. Why not develop as much as possible on the one you like?
I think this is the key to making a great cross-platform solution. Pretty much any mobile app that's not a toy relies on native 3rd party sdks, be it ad providers or fancy Ui compinents. Whatever platform first solves the issue of making integration of pods on iOs or AARs on Android a smooth process, will win.
I don't see any options that come close to solving this. Xamarin is not native to either iOS or Android. RoboVM (the one i work on) can cheat, as we only need to solve it for iOS, Android comes for free. React Native has no clear path for accessing 3rd party libs at all yet. Whatever they can come up with will be further complicated by the fact that the JS engine is single threaded.
I stand corrected, I must have overlooked that section. Callbacks (used to pass return values) are still experimental though, and it's unclear how this will port over to Android once that backend works.
My experience with third party libraries has been quite different, for the most part.
I've often been surprised at how easy it is to create bindings to libraries written in Obj-C even if no one else has before. Usually it requires extracting the compiled library from the framework, and then translating each declaration from the library's header into the C# binding definition. In many cases it's a couple of hours work (or less).
That said, libraries that are provided as source files, with the instructions "just copy them into your project," can be incredibly frustrating. Our designer would love to use github.com/MengTo/Spring but I have yet to find a way to use it in Xamarin easily.
Bindings are actually not that bad with Objective Sharpie. What SDKs are giving you trouble? I would agree that for a single platform it is not worthwhile though.
We tried mostly anything (and not only tried; we used for production work because clients wanted us to) and, outside native, Xamarin really is the best thing we worked with so far. For it's downsides, the upsides are too good to not take advantage off. Some cons I recognize but the case everyone keeps mentioning that you get into issue when you really want to do complex native platform stuff with animations etc I haven't encountered. Nor is integrating SDK's an issue. It's just something you plan in your project; it's a one-off. We integrated very large SDKs for hardware products and the hardware vendors, when something goes wrong, always blame the wrapper and it has 0 times been the wrapper; most of the times a bug or undocumented feature by the SDK creator. The wrapper is so thin and the mapping is so clear that it's actually never an issue.
Have you tried Cocos2d/Spritebuilder? If you don't ever make games for clients it wouldn't really make sense. But if so could you explain what you didn't like about it?
I've used Cocos2d with JavaScript binding a few times and really like it. You can develop primarily in a browser then package a web (without requiring plugins), Android, iOS, Mac and Windows app from your code with minor modifications.
I have used Cocos2d for clients and Monogame and Unity as well and the combination as well. I was talking about Xamarin here as app building tool, not for games. I do like Cocos2d.
Cocos2d is nice to work with as well as with Unity; we had most issues with Monogame (and that uses Xamarin) but once we got over those issues I believe we would be effective equally with Cocos2d & Monogame and slightly more so with Unity (because of the community mostly).
Most people don't realize how convenient it is to build and maintain your entire codebase (iOS, Android, Windows Phone, Windows 8, web client, web server) all in one place (Visual Studio), mostly using C# and Typescript. Just have a Windows VM on your Mac. It truly is the best of both worlds.
Yeah, a huge part of why I still (mainly) run Windows at home is easy access to Visual Studio. With third party extensions (e.g. ReSharper), and even without them, it's probably the best single IDE I've ever used.
I still use WebStorm + JS for frontend Web work, though. Would you say it's worth the switch to VS and TypeScript (though WebStorm supports TypeScript, too)?
The .Net/Visual Studio ecosystem has been looking increasingly compelling these last few years. But, I am old enough to remember evil Microsoft, so I will almost certainly never go there.
I have more than a year of experience building applications for Android, iOS and Windows with Xamarin. Overall, I much prefer my experience with Xamarin than the alternatives. Keep in mind that I did have prior experience with C#, .NET, and Visual Studio.
As far as "recommendations on developing for multiple mobile platforms", I'd be happy to answer slightly more specific questions.
> As far as I understand it, if you are big and have the resources, your best bet is still to develop separate native apps for each platform.
If you have different teams for each platform, it makes sense to go native and duplicate the effort. As soon as you want to share code or resources (including employees) between more than one platform, Xamarin starts making sense. If you have a small mobile development team (1-2 people), you'll probably need to either pick a single platform, or go with Xamarin. If you plan to have a Windows app, Xamarin makes sense. If the business is already using Microsoft technologies (Windows, .NET, C#, Visual Studio, TFS, or even Typescript), then Xamarin makes a lot of sense.
However, Xamarin is not a silver bullet. It does comes with some trade-offs (in addition to those mentionned in the article).
- You still need a Mac (either as your main machine, or on the network).
- Compile time is a bit slower.
- You don't get access to the latest Android SDK on day one (you do with iOS, though).
- You can't use any existing iOS/Android libraries out of the box. Someone (which could be you) need to manually "bind" the Java/Objective-C library interface to C# first.
- Application startup time might be a bit longer on iOS.
I work in enterprise world, as such, my mobile development experience is mostly on side projects, across all the three major platforms.
Did a project at work with Cordova, it works, but it is only usable for CRUD type of applications.
As for hobby projects, a few multimedia ones with SDL, which was ok since nothing more was being used besides OpenGL and touch input.
Tried to use Qt/C++, only to discover it kind of works, but even with all these years of talking about mobile support, Qt is pretty raw. Lots of native API wrapping is required or only available in the commercial version.
Xamarin is quite appealing, and even with the usual HN complaints about their prices, they are actually not much different from other commercial solutions for the mobile market.
Personally, I am using C++ for portable logic, together with the native UIs in Java, C#, C++/CX. However due to the pain it is to use the NDK, specially now that Google dropped the ball, I am thinking about focusing on just one platform.
If I would be doing this at work, maybe Xamarin would be the solution to go.
Do you think the commercial version of Qt would have covered what you needed? I would also be interested I'd anyone else here is in a position to compare Xamarin and Qt. It's very hard to compare the two from the outside. Thanks.
Xamarin provides a managed runtime environment (Mono) and a way to call native iOS and Android APIs from that environment. Xamarin Forms builds on top of those things to provide a cross-platform UI toolkit that uses the native controls on each platform.
Qt is a cross-platform GUI toolkit that draws its own controls using each platform's low-level graphics facilities. As such, the controls in a Qt-based application aren't fully native to each platform. Qt tries to mimic the native controls, but the emulation isn't completely faithful. A particular problem is accessibility for users with disabilities, e.g. blind users who need to use a screen reader. Last time I checked (several months ago), Qt didn't implement the accessibility APIs for iOS or Android at all.
Because of the non-native nature of Qt, I would strongly recommend avoiding it in favor of something like Xamarin or RubyMotion.
Thanks for that. The application I'm looking at has a very specialized ui. The functionality also counts for much more than native look and feel from the customers point of view so Qt might still be a runner.
On my case, I wanted to make use of the native file pickers, which only became available in Qt 5.4 via QML (not C++)[0] for Android, with iOS and WP8 support still coming.
Granted, on Android's case the pickers are only available as of version 4.4, but they are available and it is also possible to use intents for lower versions and vender specific pickers.
On my specific case, I came to the conclusion that writing my own JNI layer would be less trouble than debugging Qt. However note that for me this is just hobby development, whenever I feel like coding for it.
Compared to Xamarin, The Qt Company seems to still be searching on what platform integration to sell to companies and how.
I have been developing cross-platform mobile apps for the past five years, initially on Phonegap and for the last three years, on Titanium (Appcelerator).
If I was starting from scratch today, I'd take a good look at Titanium, React, Xamarin and Ruby Motion (in that order). In general, I think cross platform will save you time and money if you do it properly.
Titanium has been a timesaver for me. My current backend (stocklight.com) is written in Rails. For iOS and Android clients, Titanium gives me about 90% code reuse on the front-end.
ie. It allows you to implement cross platform GUI's using the same view code and you just make platform specific adjustments (eg. Action Bar versus NavigationWindow) where neccessary.
There's no way I would have had time to develop both backend and android/iOS by myself if I had to write everything natively.
Having a single model/controller layer with Titanium has been good also but I recently made the effort to upgrade this part of the project to use Alloy and that has felt very Rails-ish which has been a big improvement.
This week, Appcelerator have announced their new pricing structure ($39 per month) and are pushing a new service called Arrow for managing your back end. Personally, I don't think i'll be using Arrow (Rails seems like a better choice) but it will be great to get LiveView 'instant updates' with their new SDK.
Also, re. speeding up Android development, you should definitely check out Genymotion.
Absolutely check out Genymotion, it blows both the native android and Xamarin emulator out of the water. Xamarin studio sees it as a native device and any issues we've had with it have been minor annoyances rather than major blockers. Deployment time from the IDE is also pretty nippy.
I use Unity3D to develop for multiple platforms and can't recommend it enough -- it is a 3D game engine so it may be too heavy for some applications, but it can do anything you want it to. Everything is written in C#/.net on your end, Unity cross-compiles to other platforms.
Unfortunately, the built-in IDE for Unity is MonoDevelop, which has all the problems Xamarin does, You don't have to use Mono though, you can use any editor.
>Unfortunately, the built-in IDE for Unity is MonoDevelop, which has all the problems Xamarin does, You don't have to use Mono though, you can use any editor.
In fact, Visual Studio has first-class support for Unity now, since MS bought the company that made UnityVS and released it as a free VS extension.
I really don't think I could recommend using Unity for a non-game app, though, at least in most cases. It would be a subpar experience for both the developer and the user.
How useful is it to develop non-gaming applications (including 2D UIs)? And how much overheads it results in in terms of application performance and size? Thanks.
Not very: it fundamentally assumes you're making a game, so it draws 3D scenes and uses a continuous update loop, which taxes the battery on mobile devices. The UI tools are also just finicky enough to make non-game app development a pain.
In addition, it does have a little size overhead - the smallest possible build on iOS (a blank screen) is 12 MB with all the optimizations on, and double that if you need to invoke System functions or libraries that need them.
If you're small and a penniless startup, I think creating a native app is also often a wise choice -- all in the spirit of getting something delightful out to the market as quickly and effortlessly as possible.
That said, when all the work is done and the critical bugs are squashed, and a cross-platform app works as intended, it's a thing of beauty -- and especially wonderful when it comes time to roll out new features every week.
I have worked with various cross platform tools for a few years now and in the end all of them came to the same conclusion:
Its faster and easier to get a prototype or very simple (non-polished) app working that does not rely on specific api's to the mobile too much.
So basically you will manage to get 80% done more quickly with the cross platform tool.
However the last 20% are the very tricky part. There might be some strange bugs appearing from the cross platform tool that are hard to solve or just simply wanting to achieve a very polished app with smooth transition and the latest 'native' UI components and UI paradigms (e.g. Android Lollipop).
I also had a few major bugs coming from the interface between the native SDK and the cross platform framework. One example was that suddenly the phone fonts for some Asian languages were not displayed anymore. These problems often happened when there were some SDK changes on Android or iOS and the cross platform framework had to catch up with these changes.
Compared to native developments its also way harder to find good libraries and solve bugs (e.g. via stack overflow) because there are just way less people developing with these cross platform tools.
Since last year I stopped all cross platform developments and are now developing for iOS and Android natively and I realised that I am actually developing IN SUM faster natively then before with the cross platform tools. Main reason for this is that I have a huge focus on polished and high performing UI's and in the past I wasted a huge amount of hours just to fight the weaknesses of the cross platform tools.
So my recommendation for all who want to develop polished and professional iOS and Android Apps is now to go the native route from the beginning. Its better to try and save time by shifting some code to the server side (if you have a mobile app that extends a web app) and by developing a great abstract documentation/specification that can then be quickly implemented in the respective native language.
I built the same app using Android and iOS, but considered Xamarin at one point. I'm still considering it.
When I was deciding, I had a look at the Xamarin docs, and it seemed to reference the underlying native idioms quite often. I figured that I'd end up spending the same amount of time learning Xamarin as iOS, so what's the point?
In the end, I found the backend logic was pretty easy to write in Android or iOS. They're both OO languages, and once you've figured out the model it's not going to be hard to port. After all the phones all have similar hardware, and there's got to be some way to do the same thing.
The problem is the UI. I found it was a massive pain to learn two ways to lay out stuff. Android seems to encourage you to layout things in group containers (horizontal/vertical) that have an internal logic of their own. iOS seems to have a thing for constraints. Neither is very obvious, and they are not that easy to port from one to the other. They also each have somewhat different aesthetics (this friggin changes every time there's an update), which means you need slightly different designs (no hardware back button? no built in check box?). After grappling with this for ages, I ended up doing webviews with responsive pages. Makes the thing look like a web page, but a simple one that works like an app and can also be tested on a desktop browser.
I completely agree.. I just feel that native is worth the extra time, at least for me. Its really not hard to reimplement OO logic in objective C or Java if you have already written it for one of the two.
Has anyone had the opportunity to compare Xamarin with Corona SDK?
Corona SDK is free and builds to Android/Windows/iOS with cross-platform wrappers available for what Corona has chosen to wrap, which can be different for each platform.
You don't get access to native UI elements. Instead, Corona offers OpenGL-based replacements (which may or may not be sufficient). You can also pay for Corona Enterprise and write your own platform-specific wrappers around native objects.
I've been on projects with both: For business like apps, Xamarin (Forms in my case) is miles ahead. Although Xamarin.Forms isn't really stable (We experienced quite a lot of regressions with each new version) neither is Corona.
Corona is nice if you have a lot of custom graphics, but if you are going for pretty standard user interaction, you will spend a lot of time recreating what exists on other platforms.
For both Xamarin.Forms and Corona you will run into the limitations, but with Forms it is much easier to adjust those with native code.
I think the main issue with Corona is that they are more focussed on the game case (for which it works)
Finally, I really started to appreciate C# after doing Lua, PHP and JavaScript for years. Especially on a complex app, the static typing really helps making changes to code you did not write yourself.
This to me sums up my experience with Xamarin. It has A LOT of potential, and I did generally enjoy working with it. However, the amount of small issues I dealt with that were never solved (and still haven't been solved 2 years later) are what drove me away. That and the cost...
That is incredibly cheap. It's the sort of cheap that's so cheap you wonder what the catch is.
Assuming a perfectly spherical developer, you're at $100,000/year. You're using Xamarin because it makes that developer more efficient because (1) you've determined C# is an easier language to maintain and/or (2) cross compatibility is worth something. If this developer is just 1% more efficient, you've paid for your Xamarin license. If he's not 1% more efficient, why are you even using Xamarin in the first place?
Er, that's on top of your Windows license, your Visual Studio license, your Apple Developer License, your Apple Macbook because you can only compile and deploy to the app store with a Macbook... oh and Xamarin university if you want to become certified... and if I understand the terms correctly, it's not $1000 per developer, it's $1000 per developer per platform, so if you want iOS and Android, it's $2000 per developer on top of all that previous licensing. So to say it's incredibly cheap at $1000 isn't the whole story.
You don't need a MacBook. You can develop on Windows (which means you don't have to pay for that Windows license) and use a Mac Mini on the network for the OS X build requirements.
I've been using Kivy. But decided if I did native, I'd only support iOS. Mostly because I don't want to go down the rabbit hole of having to support some random Android device.
So I'm looking at learning more about Swift and that ecosystem someday. I don't know C# but I certainly see Xamarin as an upgraded version of Kivy.. obviously going from a free platform to a paid one. It's something I've keeping my eye on for quite some time.
If I ever find Kivy and the native iOS development combo to not meet my needs, Xamarin is the next stop for me.
We launched an online training program called Xamarin University, and so we have a fair amount of data on how long it takes people to get to the point where they are proficient enough to write a production app. As you might expect it's highly varied. But the median is about 45 days to pass our certification.
I have been starting to learn how to write mobile applications with Xamarin to contribute to a friend's project and had not heard of Xamarin University until I saw this comment. Now that I have looked at it, I'm a little confused. I can understand charging for 1-on-1 help, interactive classes, and certification exams, but why wouldn't "recorded class videos, class labs and materials" be free? Don't you want it to be easy for people to use your software so that people will? Charging $1995/year for learning materials seems pretty steep.
The learning investment is what makes me most hesitant to use Xamarin. It was supposed to be less of a learning investment because we all have C#/.NET experience, but now I'm not so sure. It now seems like we're going to have to dive deep into learning iOS and Android specific UI concepts anyway, and on top of that learn Xamarin concepts and quirks, and if we want to continue using Visual Studio when the trial is up we'll have to pay $1000/year. Maybe we're just not the target market.
As for Xamarin University, the vast majority of that experience is live, interactive learning with a teacher. That's why it costs money. The recorded versions of those interactive classes aren't that useful on their own. But, we're working on developing some good standalone e-learning content and when we do it will be widely available.
If one is not burdened with knowing anything yet is it feasible to start and stay with C#/Xamarin alone or must one also master the other environments to fill gaps?
I'm sure they'll tell you that you can do this using Xamarin.Forms but we quickly realized that it is only useful for very basic UI. Anything of more than trivial complexity is going to require that you learn the platform specific frameworks and idioms (on top of learning Xamarin). At this point I have no idea if Xamarin is going to save time or cost time over going native. My guess is that it will depend on how much domain logic you can share between platforms.
I came from a pure C# background about a year ago and I found I was able to get up to be productive within a month and feel comfortable within about 3. The major sticking points for me have been understanding the iOS and Android development process and their respective APIs. I think if you've previously developed iOS applications and understand the view/viewcontroller and application lifecycle, the learning curve won't be huge. Xamarin does a great job of making you feel like you're developing natively in c#, but, as someone entirely new to iOS development, the native APIs just feel odd.
If anyone here has tried out Titanium by Appcelerator, I'd very much like to know how your experience was. I've heard conflicting reports on how native it actually is. This article says it uses HTML5 / web views, but I've heard that it uses native widgets, and is pretty close to native. Any ideas?
And, do most of the things listed here apply to it as well?
The approach with Xamarin is that you are able to build out a shared C#/.NET business logic layer. All of your platform independent code such as Models, ViewModels, Database code, Restful Service calls, etc. You get to use the power of C# and .NET to build this out. Then you build out user interfaces for iOS, Android, and Windows and tie this logic all together. Xamarin apps are native so you follow the same paradigms for building the UIs out such as Android XML and iOS Storyboard or XIB files, but you can build these out in the Xamarin Designers for both iOS and Android inside of Visual Studio or Xamarin Studio.
On the code behind side of iOS/Android (UIViewController or Activity) you write all of this in C# with C# features like LINQ, events, delegates, etc. and you have access to 100% of the iOS and Android APIs of the platform as well.
Now we do have the Xamarin.Forms library which adds on top of this to build on a shared UI layer for iOS, Android, and Windows Phone as well. However it is not for every app and we have guidance at www.xamarin.com/forms. Hopefully this is a nice overview of the platform.
That's actually the way Xamarin works the best - you usually don't develop UI natively, but use Xamarin's wrappers for native UI elements for each platform separately. They're not all that compatible when it comes to UI and UX anyway.
If you are building for Android you can do it 100% of on Mac OR a PC. Since Google ships sdks and tools for both Mac or PC that is why you can do this.
Apple is much trickier. You can still open iOS projects, modify code, and compile without a Mac connected. However, to actually do design in the storyboard designer in VS or build the package to deploy on a simulator or device you need to be connected to a Mac somewhere on your network. This is apple restrictions and also for the fact that all of the simulators and tooling only exists on the Mac.
You don't have to have a power house machine to do this though, something like a Mac Mini would work fine. There are some cloud solutions out there as well.
Anyway, you will spend a LOT of time fixing Xamarin bugs and developer their controls.
However, I LOVED .net functions, especially LINQ !
Anyway, development was really slow and performance is no were near to native.
So if you want to deliver a simple app to a client and be cross platform, then sure. But don't try to maintain that app, you will regret it.
I'm afraid the whole Xamarin thing won't solve "cross-platform" which isn't a real problem but sure. Its just another horse that Microsoft is betting on.
Oh and for the people that will have to do it anyway. Use Resharper ! Xaml IntelliSense !!! It will help you a lot.
I'm sorry I'm so negative, but it was genuinely the worst development I had.