Hacker News new | past | comments | ask | show | jobs | submit login

I have come to this same conclusion after many years. It's not cost-effective to have any bespoke business logic (models, controllers, etc.) shared between the two mobile platforms (don't get me started on sharing UI code). If you have some incredibly tricky low-level algorithm/library and/or need for speed, think database, crypto, intense graphics, etc., then fine, you may be able to swing a shared module in C++ or something. Other than that, it's almost like the collective consciousnesses of Google and Apple conspire to make cost-effective code-sharing of typical CRUD apps almost impossible.

Here's a fine alternative to code-sharing: well first and foremost you need to have a good requirements spec. After that, implement it on one platform first in a platform agnostic way. So heavy use of delegates/interfaces/injections to handle platform-specific functionality, even for one-liners like getting current system time. So the code should be pure, boring, plain old Java, Kotlin, Swift, whatever. Minimal use of fancy language features that may not port cleanly. After one platform has the module in place and well-tested, do a copy/paste port to the other platform. You will find that the copy/paste port will actually uncover bugs, optimizations, edge cases, etc., that can then be ported back to the original platform. Things you would not have found if you were only writing the code once. It's like the most intense kind of PR code review you can get.

So I've found that copy/paste-port-based code sharing between platforms is not just a lesser evil, but actually a strategy that has its own unique benefits. If you get into a groove you can build up a set of regexes to give you a sloppy transpiler that does most of the tedious porting for you.

The article says it all - they chose the wrong language with no community support for the trail they were blazing and that technical debt destroyed their productivity.

I achieved 90+% code share in Xamarin including UI across windows - ios - andriod. 100% buisness logic shared. You can write cross-platform UIs, and swap out to native code on a widget by widget basis. Threading is seemless. Sure it has its own set of issues, but everything is a trade-off. Look at your use case, and define what trade-offs you are happy with.

The drop-box use-case is also an outlier - to achieve high levels of responsiveness, it must integrate with low level platform specific APIs to the point their entire app may be some kind OS specific service. Look at blogs about their desktop apps and you see my point.

If you going to drink cool-aid from companies just because they are dominant in an area, atleast drink the cool-aid of a startup which was created for the purpose of building cross-platform apps.

I took a look at Xamarin recently to see how far it had come, and the tooling is really impressive. They seem to do a great job of keeping up to date with iOS/Android SDK changes, too.

But when trying to find an example of a native-feeling Xamarin-based app for iOS, I was really underwhelmed. I tried to find one that was (a) well-known and (b) third-party (not developed by Xamarin or Microsoft). The 4 contenders were:

- UPS - 1/4 stars - All views of the app are awkward embedded web views. Every page has a full screen modal spinner.

- Outback Steakhouse - 1/4 stars - Not updated for modern iPhones, so the whole app is letterboxed. UI is completely custom, so didn't attempt to feel native. Crashed as soon as it tried to get my location.

- Alaska Airlines - 3/4 stars - Feels native-ish, nice "vanilla" design. Mix of native forms and web views. All UI related to searching flights & buying tickets is a web view. Every tap on the tab bar causes a full screen modal spinner.

- FOX Sports - 4/4 stars - Wow, impressive. Lots of native-feeling views with their own branded styling. The custom widgets feel native.

It was great to find one "hero" app for Xamarin (FOX Sports), but the fact that it's an outlier is a little concerning.

I believe the Fox Sports app was done by a company called WillowTree.


They specifically mentioned when I was interviewing there that the reason their Xamarin apps are so good is because they already know how to make good native iOS apps.

Also, I specifically asked about whether or not they would be using more technologies like Xamarin in the future and they didn't seem too keen on it.

According to them, making a truly native seeming app in Xamarin isn't much less work than making two separate native apps.

Many businesses go with Xamarin because some guy in a management mandates it because he feels it will be a silver bullet that will let them get around having to hire skilled native mobile developers.

The reality is that to do Xamarin well you’ll have to wander outside out Xamarin Forms, and to do that well not only do you need native mobile developers but you need far higher caliber native mobile devs who are able to mentally translate swift/objc and android calls into their C# equivalent, and who have an idea of what’s going on the os when there’s a crash at a level lower than the .NET runtime caused by a native part that’s not apparent in the crappy Xamarin stack trace.

Xamarin really only makes sense if your company has a mountain of existing complicated .NET code with priceless business logic that you absolutely have to reuse.

I used to work for them. Great company, great technical talent. If anyone wants to move to Charlottesville or Durham I encourage you to apply! I live in CVille and I love it.

The Xamarin folks are native platform engineers first. Xamarin teams comprise Android experts and iOS experts who did then went on to learn Xamarin on top.

Thats the same experience with us except instead of Xamarin we used more popular cross platform mobile framework Flutter from google. Given most of business logic is maintained in back-end. Fron-end client be it mobile or web based needs UI and state management with some local data for offline storage. We thought it will be easy to share code across platform and we were so wrong.

Given advances in mobile platform and Native SDK a company like Google, Microsoft or Facebook will not be able to keep up with native SDK and will be one or two generations behind. You can see the result in issues on flutter project. Also given Swift has Python like syntax and ease of use with powerful toolchain and Kotlin with nice syntax with functional programming efforts are not that different working with native SDK.

Obviously this cross platform mobile framework are ok for simple crud apps. But when it comes to building a mobile app using modern vision, audio, keyboard, touch and gesture input along with modern sensors in the platform and provide a consistent UX is a big challenge. Also UI and UX have enough subtle differences across iOS and Android the code written to manage them is also substantial. So its nice to go native SDK route for mobile apps.

I think there is a little bit of bias here. Companies that are prioritize look and feel over cost probably are going native. And companies that prioritize cost over look feel are free are going xamarin.

Xamarin is indeed the closest there is to the holy grail of cross-mobile development. I too had some success with it for a small project at first, but just like the theme of the blog post, the challenge is in the long-term maintenance being cost-effective, not just the initial development. Especially in the face of these adversarial platforms constantly changing things underfoot. For example in Android recently I've been forced to switch to the AndroidX library, and iOS has Dark Mode coming out. Will Xamarin support both of those platform changes cleanly? Maybe, but it's a risk.

I'd be happy to hear if the project you worked on has been cost-effective to maintain in the long term. Then at least someone has seen the mountain top!

I’m pretty happy with nativescript. It suppers typescript, different ui libs (angular, vue, and no-lib)

You can directly access native apis within your js/ts code. And they provide good cross platform defaults for widgets.

there is a difference between Xamarin and Xamarin.Forms, one thing is just C# => ObjC binding / C# => Java binding (C# to AOT native shared libraries and binds it into the native things), which basically SUPPORTS ALL of the native features.

so basically you can either have one application on top of a custom ui framework (xamarin.forms) or you can only share business logic, and write controllers, which feels native in c# or the native language.

i.e. without forms you can build a controller with objc or you can have the implementation in c#, and call into a shared business logic library. unfortunatly the docs are really really weak when you consider what you really can do with xamarin.

with forms you can build a ui that works on both platforms so basically you have 100% shared code.

It was years ago, but Rdio went the Xamarin route, regretted it, and then did exactly what Dropbox just did and went full native.

The reasons for regretting it were similar: lack of available engineers on the market, incompatibilities between runtimes, and lagging support for platform features (although in the Xamarin case it's not even in your hands to fix it)

Xamarin is open source now.

Xamarin on paper seems like the holy Grail, but the fact that Microsoft itself chose to use react native instead of its own solution for Skype made it seem like I should not expect long term commitment to xamarin from MS.

I would be careful to attribute framework decision making to careful thought. This is more the regular organizational dysfunctionality. Either:

- The entire organization uses a single framework (and improves on it), which will lead to a bunch of teams grumbling that "We are only using X because of organizational pressure, while Y is much better"

- You leave freedom to the org to pick their technology, and hope/steer people towards certain parts. But you will have to accept some divergence from the norm

I prefer the second org, and luckily I am in such a place where we can use Go while the team next to us is on Scala, and we weigh in-house developed technology against publicly available technology on ROI.

The Skype engineering team is an acquisition with relative autonomy, and is always making weird choices. Wouldn't take that too seriously.

Microsoft Office has gone all in with React Native as well. Here is a recent comment from Andy Coates talking about MS Office Android performance:


Other article talking about it:


They have addressed this at BUILD.

Xamarin for .NET devs, React Native for C++ devs (a bit like QML/Qt).

Office naturally fits the C++ devs way.

Office also has to make sure that things work on the web given they also support all the Office.com O365 versions of their apps. That's another reason they'd prefer React Native (for React Native Web) to Xamarin.

But the Office team is also a right tool for each job group and has both Xamarin and React Native apps and telling the difference between them is getting tougher to do. You can already integrate React Native components inside a Xamarin app and vice versa because they each can look like native components to each other, and it's not entirely an either/or decision.

Ah Xamarin, what a horrible mess. Limited UI, limited support, constantly breaking. Never again.

And the same problem with using C++, you have to build the app around it, rather than using the best arch for android and ios.

Years ago I wrote a programming language a bit like Haxe, except that it let you 'inject' snippets of your target language wherever you wanted. So you could keep your major architecture in one common language and still implement specific cases on the spot (ie you don't have to go to other files, and the various implementations for different target languages were right next to each other, making it easier to keep them in sync).

I implemented targets for JS, php and C++. It worked okayish but in the end it was more work to maintain the separate language than just write everything 3 times with some help of a simple macro/template language. I still sometimes wonder if the concept would be developed further, with a proper team and good tooling etc, if it would be a practical way of doing large scale cross platform software development.

> a bit like Haxe, except that it let you 'inject' snippets of your target language wherever you wanted.

If I understand you correctly, this feature is available in Haxe : https://haxe.org/manual/target-syntax.html

It targets js, php, C++, has a proper team and good tooling.. so you might be interested in giving it a try.

This is a fascinating idea, and reminds me of the dreaded [1] rewrite, where you rewrite the application because the new system will always be better in the new framework...

But this is different, if you write things simply, so the code can be ported easily. Then you're essentially making the code easier to share, without tightly coupling it to a specific platform... seems like a big win to me

[1] http://wiki.c2.com/?RewriteCodeFromScratch

Note to self:

This also has the benefits of:

- Being easier to on-board new developers, as the architecture is generally language agnostic.

- Easier to add new OS clients, as the system is easily portable


- Harder to incorporate language specific dependencies, as they are much harder to find in multiple languages.

- Code duplication...

Always important to weigh up the trade-off's

Agreed that it is both fascinating, and from the experience I’ve had with the approach, it has turned out to be quite an effective way to build very maintainable software.

> a good requirements spec

I think that kills a lot of interesting projects right there. If I could write a solid spec, that would mean I believe I wouldn't learn much from shipping the product. And also that my competitors aren't learning or advancing.

Nobody says you have to write the spec beforehand.

As long as you don’t blurt a lazy “use the source Luke” and take the effort to document and edit the spec during or right after implementing something, it’s ok.

Well, I think the comment I'm responding to expects the spec first. And almost anything that encourages writing a spec says to do it first.

What's the point of writing the spec after? At best, it's duplicative. At worst, it diverges, making it incorrect.

Nah, it’s just this whole manichean polemic between two grotesque caricatures of processes; agile improvisation vs upfront waterfall planning à la nazi wehrmacht going to Russia.

One just has to have an idea where to go before starting, and a good description where one went when you’re done.

Whatever you first create has some kind of vision behind it. Even if that vision is a rough spec, it might be precisely the little bit of spec that’s necessary to get things started.

A good requirements spec doesn’t mean it has to be heavyweight with all the corners and edges figured out. Instead, it can be just lightweight enough to get things moving in the proper direction... but some little direction is certainly needed.

No, I've built entire products without a spec: http://williampietri.com/writing/2015/the-big-board/

It's fine.

How does that work out when things change over time: requirements and the platforms themselves?

Basically the same process as when you first started. Implement the changes on Platform A, get it stable, port it over to Platform B, get it stable, port back any refinements to platform A. Platform changes themselves should ideally be quarantined behind said abstractions/injections, so your actual ported code is very simple and "timeless": no fancy language features, no preprocessor magic, no annotations, no excessive syntactic sugar.

Approaches like this could increase the second-class-platform effect. Where, for example, Android gets updates long after IOS. (Unless both releases are synchronized.)

In theory the shared code approach means platforms could be tested in parallel.

The whole point of the post here is that the theory doesn't apply very well to modern mobile development, and trying to share code effectively slowed them way down.

Rinse and repeat.

Ha beat me to it!

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact