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.
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.
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.
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.
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.
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.
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'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!
You can directly access native apis within your js/ts code. And they provide good cross platform defaults for widgets.
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.
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)
- 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.
Other article talking about it:
Xamarin for .NET devs, React Native for C++ devs (a bit like QML/Qt).
Office naturally fits the C++ devs way.
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.
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.
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.
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.
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
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
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.
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.
What's the point of writing the spec after? At best, it's duplicative. At worst, it diverges, making it incorrect.
One just has to have an idea where to go before starting, and a good description where one went when you’re done.
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.
In theory the shared code approach means platforms could be tested in parallel.