6 ms·

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

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.

paulryanrogers 7y ago
How does that work out when things change over time: requirements and the platforms themselves?
- Scarbutt 7y ago
  Rinse and repeat.
  - dougk16 7y ago
    Ha beat me to it!
- dougk16 7y ago
  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.
  - paulryanrogers 7y ago
    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.
    - ufmace 7y ago
      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.
weq 7y ago
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.
- jmtulloss 7y ago
  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)
  - oblio 7y ago
    Xamarin is open source now.
- dougk16 7y ago
  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!
gitgud 7y ago
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 http://wiki.c2.com/?RewriteCodeFromScratch
- karmelapple 7y ago
  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.
- gitgud 7y ago
  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 Downsides: - 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
wpietri 7y ago
> 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.
- karmelapple 7y ago
  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.
  - wpietri 7y ago
    No, I've built entire products without a spec: http://williampietri.com/writing/2015/the-big-board/ http://williampietri.com/writing/2015/the-big-board/ It's fine.
- eecc 7y ago
  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.
  - wpietri 7y ago
    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.
    - eecc 7y ago
      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.
roel_v 7y ago
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.
- tkp 7y ago
  > 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 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.

paulryanrogers 7y ago

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

Scarbutt 7y ago
Rinse and repeat.
- dougk16 7y ago
  Ha beat me to it!
dougk16 7y ago
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.
- paulryanrogers 7y ago
  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.
  - ufmace 7y ago
    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.

weq 7y ago

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.

jmtulloss 7y ago
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)
- oblio 7y ago
  Xamarin is open source now.
dougk16 7y ago
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!

gitgud 7y ago

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 http://wiki.c2.com/?RewriteCodeFromScratch

karmelapple 7y ago
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.
gitgud 7y ago
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 Downsides: - 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

wpietri 7y ago

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

karmelapple 7y ago
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.
- wpietri 7y ago
  No, I've built entire products without a spec: http://williampietri.com/writing/2015/the-big-board/ http://williampietri.com/writing/2015/the-big-board/ It's fine.
eecc 7y ago
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.
- wpietri 7y ago
  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.
  - eecc 7y ago
    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.

roel_v 7y ago

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.

tkp 7y ago
> 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 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.