Live data from Hacker News

Some thoughts after (almost) a year of real Xamarin use

estaun.net

101–110 of 113 posts

Re: Some thoughts after (almost) a year of real Xamarin use

#101

Now that we are at it, if you have experience / recommendations on developing for multiple mobile platforms please share it here. 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. Right?

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 (…

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.

Re: Some thoughts after (almost) a year of real Xamarin use

#102

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 platfor…

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 Xam…

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 ;-)

Step three is to architect your network services and data persistence exactly as detailed here: http://arteksoftware.com/resilient-network-services-with-xam...

For more information on the above see https://www.youtube.com/watch?v=voa44OHBKME - "Writing Mobile Apps the Github Way by Paul Betts"

(disclaimer: contributor to the ReactiveUI project ;-)

Re: Some thoughts after (almost) a year of real Xamarin use

#103
post #91

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 you…

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.

Re: Some thoughts after (almost) a year of real Xamarin use

#104

> but 1000$ developer/year is not exactly cheap. 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 ju…

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 develop…

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.

Re: Some thoughts after (almost) a year of real Xamarin use

#105
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.

Re: Some thoughts after (almost) a year of real Xamarin use

#106

Earlier quoted context omitted.

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#: http://forums.xamarin.com/categories/ObjectiveSharpie If you're skilled enough to build the Obje…

ObjectiveSharpie is awesome! No problems so far. But when are you gonna let us use Xamarin Studio on Linux?

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.

Re: Some thoughts after (almost) a year of real Xamarin use

#107

Earlier quoted context omitted.

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 Xam…

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 event…

Excellent write up, cleared things up for me. Xamarin guys should just take it and put on their website.

Re: Some thoughts after (almost) a year of real Xamarin use

#108

Earlier quoted context omitted.

ObjectiveSharpie is awesome! No problems so far. But when are you gonna let us use Xamarin Studio on Linux?

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?

Re: Some thoughts after (almost) a year of real Xamarin use

#109
post #75

Earlier quoted context omitted.

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. T…

Thanks, interesting links.

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.

Post reply on HN