4 ms·

Xamarin's value proposition is developing for multiple platforms at once (or at least, as a current Xamarin user, sharing as much as possible between platforms)

Xamarin's value proposition is developing for multiple platforms at once (or at least, as a current Xamarin user, sharing as much as possible between platforms). Swift still offers nothing for that scenario so I don't really understand the comparison. Obviously if you are only going to ever develop for iOS then going with Swift could make sense but then it seems that Xamarin would've never really have been an option anyhow, irrelevant of cost.

untog 12y ago
Last time I tried Xamarin (and I'll admit it's been a while) cross-platform was surprisingly difficult. A project had to be either iOS or Android - and that included projects that had no UI code in them. So the concept was there, but the execution wasn't yet. Of course, this may have changed.
- eropple 12y ago
  Portable Class Libraries help here. They aren't perfect, and honestly they're justly badly reinventing Java's loosely coupled jars, but they give you the ability to link stuff together in a little more general of a way. In my current project (a video game), the core library is a PCL - it contains data structures and the interfaces and abstract classes that content (mods as well as the base game) must fulfill. I have a "desktop" library that's a normal .NET 4.5 class library that contains stuff like "load your config data from files, include the runtime-compilation mod system", and I have runner projects--text-mode via curses for now, eventually graphical post-prototype--for MacOS, Windows, and Linux[1]. I use configurations (not platforms, leave everything as AnyCPU unless you want to hate your life) to provide preprocessor flags for #if; my solution has ended up with an ugly number of "Windows-Debug", "MacOS-Release", etc., but the differences between XS and VS make it hard to do things "right". [1] - all source/content files added via a single template .csproj, using a Ruby watcher I'm going to eventually open-source, because using MSBuild correctly to handle this situation breaks in both VS and Xamarin. (That last bit, you may be realizing, is a common theme. .NET has such good stuff, but half of it is broken at any time.)
  - JonathonW 12y ago
    Assuming you don't need to pass around binary libraries, take a look at shared projects-- added in Visual Studio 2013 and Xamarin Studio 5, IIRC. Unlike PCL projects, they compile in the context of the projects that reference them, so you have full access to the libraries that are common between each platform, and (if your coding style allows it) full access to platform-dependent APIs as long as they're protected by the appropriate #if __IOS__/#if __WIN32__/etc. Keeping common code in shared projects is like night and day compared to the mess that is keeping common code in a PCL and having to deal with common APIs that aren't present (or worse, are incomplete) in your chosen PCL subset. They really clean things up a lot, even if you're treating them like they're a PCL and avoiding any platform-dependent code.
    - eropple 12y ago
      Ooh. I didn't know about this. I'm using VS2012, because I don't want to shell out again for VS2013 but want ReSharper - I'll have to look at this...thank you!
- jdhawk 12y ago
  There is still a degree of that, depending on how you structure the application, and how much of it is reliant on your UI layer vs backend business logic. Xamarin.Forms is their solution - common UI components wrapped in a generic layer. They have a nice way to blend Xamarin.Forms, native UI controls and library projects that is getting much better, but still a bit of a pain. They true value in my eye is that I only have to be proficient in one language, and they have very good documentation. I still need to have a firm understanding of the API's for both Android, iOS, and WinPhone if I want to make a non-Xamarin.Forms application, but at least I'm not mentally shifting between 3 languages.
  - Alphasite_ 12y ago
    Picking up languages really isn't that te key, it's always been the library that's hard, so I can't say I can see the value if it's just that.
    - jbergens 12y ago
      I suppose the value is that you don't have to rewrite your application logic multiple times. That takes time even if you're fluent in all languages. It is also a duplicatio which increases the risk of later bugs due to not doing all changes in all copies.
      - jdhawk 12y ago
        Exactly - and as a after work only developer, the less I have to do over, the less I have to consult the docs, the more comfortable I am with a single tool, the more productive I become.
usea 12y ago
At work we use Xamarin for iOS-only projects, as we're primarily a C# consultancy. It's expensive, but it would be more expensive and difficult to find or train native iOS developers. Or at least, that's the impression management is under. The fact that we could port an app to Android somewhat easily when a client requests it is just icing on the cake, since almost all of our mobile projects are iOS only.
- lordnacho 12y ago
  Interestingly, most of my experience is in c#, but I've now got a side project that requires apps. I wrote them in Android and iOS. I looked at Xamarin as well, but I couldn't see the point of learning essentially a new framework. I figure whatever pattern you use (probably MVC) it will be the same on both. And the layout paradigms are different between them, so how is Xamarin going to fix that? My solution was just to use webviews instead of the native layouts (decided after bashing my head against both layout engines). Anyway, my point is once you understand how things are organised, the language shouldn't make much of a difference. Especially not between popular, run-of-the-mill languages like c#, java and ObjC. Your devs could probably learn iOS pretty easily.
  - usea 12y ago
    I agree. However, there is a lot of fear among developers in my area with regards to learning new languages. Many developers I know would rather learn 20 new frameworks than a single new language. Managers feel even more strongly along those lines. I don't share their views, but I think I am in a minority.

untog 12y ago

Last time I tried Xamarin (and I'll admit it's been a while) cross-platform was surprisingly difficult. A project had to be either iOS or Android - and that included projects that had no UI code in them. So the concept was there, but the execution wasn't yet. Of course, this may have changed.

eropple 12y ago
Portable Class Libraries help here. They aren't perfect, and honestly they're justly badly reinventing Java's loosely coupled jars, but they give you the ability to link stuff together in a little more general of a way. In my current project (a video game), the core library is a PCL - it contains data structures and the interfaces and abstract classes that content (mods as well as the base game) must fulfill. I have a "desktop" library that's a normal .NET 4.5 class library that contains stuff like "load your config data from files, include the runtime-compilation mod system", and I have runner projects--text-mode via curses for now, eventually graphical post-prototype--for MacOS, Windows, and Linux[1]. I use configurations (not platforms, leave everything as AnyCPU unless you want to hate your life) to provide preprocessor flags for #if; my solution has ended up with an ugly number of "Windows-Debug", "MacOS-Release", etc., but the differences between XS and VS make it hard to do things "right". [1] - all source/content files added via a single template .csproj, using a Ruby watcher I'm going to eventually open-source, because using MSBuild correctly to handle this situation breaks in both VS and Xamarin. (That last bit, you may be realizing, is a common theme. .NET has such good stuff, but half of it is broken at any time.)
- JonathonW 12y ago
  Assuming you don't need to pass around binary libraries, take a look at shared projects-- added in Visual Studio 2013 and Xamarin Studio 5, IIRC. Unlike PCL projects, they compile in the context of the projects that reference them, so you have full access to the libraries that are common between each platform, and (if your coding style allows it) full access to platform-dependent APIs as long as they're protected by the appropriate #if __IOS__/#if __WIN32__/etc. Keeping common code in shared projects is like night and day compared to the mess that is keeping common code in a PCL and having to deal with common APIs that aren't present (or worse, are incomplete) in your chosen PCL subset. They really clean things up a lot, even if you're treating them like they're a PCL and avoiding any platform-dependent code.
  - eropple 12y ago
    Ooh. I didn't know about this. I'm using VS2012, because I don't want to shell out again for VS2013 but want ReSharper - I'll have to look at this...thank you!
jdhawk 12y ago
There is still a degree of that, depending on how you structure the application, and how much of it is reliant on your UI layer vs backend business logic. Xamarin.Forms is their solution - common UI components wrapped in a generic layer. They have a nice way to blend Xamarin.Forms, native UI controls and library projects that is getting much better, but still a bit of a pain. They true value in my eye is that I only have to be proficient in one language, and they have very good documentation. I still need to have a firm understanding of the API's for both Android, iOS, and WinPhone if I want to make a non-Xamarin.Forms application, but at least I'm not mentally shifting between 3 languages.
- Alphasite_ 12y ago
  Picking up languages really isn't that te key, it's always been the library that's hard, so I can't say I can see the value if it's just that.
  - jbergens 12y ago
    I suppose the value is that you don't have to rewrite your application logic multiple times. That takes time even if you're fluent in all languages. It is also a duplicatio which increases the risk of later bugs due to not doing all changes in all copies.
    - jdhawk 12y ago
      Exactly - and as a after work only developer, the less I have to do over, the less I have to consult the docs, the more comfortable I am with a single tool, the more productive I become.

usea 12y ago

At work we use Xamarin for iOS-only projects, as we're primarily a C# consultancy. It's expensive, but it would be more expensive and difficult to find or train native iOS developers. Or at least, that's the impression management is under. The fact that we could port an app to Android somewhat easily when a client requests it is just icing on the cake, since almost all of our mobile projects are iOS only.

lordnacho 12y ago
Interestingly, most of my experience is in c#, but I've now got a side project that requires apps. I wrote them in Android and iOS. I looked at Xamarin as well, but I couldn't see the point of learning essentially a new framework. I figure whatever pattern you use (probably MVC) it will be the same on both. And the layout paradigms are different between them, so how is Xamarin going to fix that? My solution was just to use webviews instead of the native layouts (decided after bashing my head against both layout engines). Anyway, my point is once you understand how things are organised, the language shouldn't make much of a difference. Especially not between popular, run-of-the-mill languages like c#, java and ObjC. Your devs could probably learn iOS pretty easily.
- usea 12y ago
  I agree. However, there is a lot of fear among developers in my area with regards to learning new languages. Many developers I know would rather learn 20 new frameworks than a single new language. Managers feel even more strongly along those lines. I don't share their views, but I think I am in a minority.