[skrowl]

You may have missed the announcement where MS bought out Xamarin and is now giving it away for free. You owe it to yourself to at least give it a try while waiting for actual cross-platform Swift.

90+% of your mobile code can be shared between Android and iOS. Not sure if that's something currently possible with Swift or not, but it was worth keeping C# around for our needs.

We're more of a "mobile app is something we also offer" and web is our main presence though, so your mileage may vary (especially if you're mobile-only or mobile-centric).

[danielrhodes]

If there was a common native language between Android/iOS, it would make things easier for sure. But using a third language to solve the existing problem is a rookie error.

> 90+% of your mobile code can be shared between Android and iOS

This stat depends on how complex your app is, but it usually only applies to gaming. Otherwise it's almost always false.

We've already been down this path with the webview craze a few years ago. It was a total nightmare. These newer cross platform frameworks may no longer use webviews, but under the hood things are just as gross.

What is true though is that these cross platform frameworks always oversell themselves (with the exception of Unity3D). You end up trading in one problem for another.

Among the many problems you will encounter:

1. You miss a lot of newer features in the native platforms. If you want to incorporate those features somehow, the code becomes a conditional mess.

2. Performance is very meh and your hands are mostly tied in optimization. In both Android and iOS, getting performance correct (for example in a table view) requires a lot of tweaking. All of the cross platform frameworks I've used, including React Native, work for basic cases but quickly start dropping frames after that.

3. The majority of a mobile app's code is front-end, and this is not the place where you want to share code. Users on each platform expect different types of interactions and behaviors, not to mention UI aesthetics.

4. These different platforms all have their own characteristics and ways of doing things. These differences are not easily abstracted out. At the point where you are coding around these differences, you might as well have two different code bases. For all the complaining about differences between WebKit/Chrome/IE etc, the behavior is remarkably similar -- mobile platforms are far more diverged.

5. Native third-party libraries are very difficult to use because there is never the same library on the other platform. If there is, say with Facebook, they are not in sync.

6. You end up writing a lot of bridge code between iOS/Android and the framework. It's never pretty and painful to debug.

7. Getting locked into a third-party's framework is a bad place to be later on. Once it's in there, it's never coming out.

I could go on...

If you absolutely need to go cross platform early on, the best thing you can do for yourself is to lock down a common API/data model as early as possible, and create an aesthetic and design that is simple to implement on both platforms.

[carlosrg]

I can see you have no idea what Xamarin is. With Xamarin, you still use UIKit and the native Android UI, the difference is that you program it in C# and thus the non-UI code can be shared seamlessly. Performance is not "very meh" as the UI is completely native and Xamarin compiles the C# to native code ahead-of-time. It has literally nothing to do with WebViews.

[matthewmacleod]

Hey, you need to read the parent a bit closer.

Nobody's saying that Xamarin uses web views, but clearly there's a comparison to be drawn with the craze a few years back for writing mobile apps using web views. This was advocated as being cross-platform, allowing developers to write the same code and run it on multiple platforms. The downsides are the same in some ways, as the parent enumerated.

Xamarin's use of native UI is important, but in my experience it's clearly not as seamless as you think; while you access the UI natively, there are intrinsic architectural differences that make it difficult to do so in a high-performance manner without a lot of fairly hacky code.

[carlosrg]

Yes, I've read the parent closely. The downsides are still wrong, because they assume that Xamarin is a cross-platform UI toolkit, which is not true. The performance downside is wrong, the newer features downsides is wrong, the front-end code sharing is wrong, the third party libraries is wrong (Xamarin can generate bindings for other frameworks automatically), and the only debatable one is getting locked in a framework.

[danielrhodes]

I haven't used Xamarin, but I've used a number of other frameworks (some webview based, many not). Some had benefits, but many had a lot of drawbacks.

I could write a long blog post about what a headache it is to support both platforms, but I don't think any of these frameworks solve the real pain points. It's generally a lot of small things which add up. It also takes a lot of team discipline.

Code sharing would be useful, but not massively since the majority of code is in the UI. When the UI is different, a lot of differences start to be needed in the non-UI code as well. Suddenly you are back at square one. Depends on the app though.

[neppo]

90%+ shared code is a bold claim, Xamarin.com states 60-90%.

In my experience it's closer to 60%.

[rdsnsca]

And you must of missed when Apple open sourced Swift and released binaries for Ubuntu 15.10 and Ubuntu 14.04.