> The problem is coordination cost. If you want to launch new features and experiments here, there and everywhere, then the coordination complexity increases nonlinearly with the number of platforms.
Why not use a common library, where platform teams can update what features they use from it at their own pace?
Or why not use some other tech that allows multi-platform native shipping? The company I just started at, RemObjects, builds software for Mac and Windows (and iOS etc) from a common codebase. They just keep the UI separate, and all that is done when there's a new feature is _only_ UI layer coordination.
So an app has a C# (say) or Go codebase, and a UI layer in WPF and Cocoa.
I feel like coordination cost goes way down with both of these:
a) Library approach: central functionality, platform teams not tied to specifics
b) Shared codebase where all logic lives: platform teams do only UI
Edit: forgot to add, all this is can be across languages, ie maybe you have a Go shared library and write your Cocoa UI layer in C#, that's fine, their tech makes it all interop.
Personally I think the challenges with this approach (having literally used a Go shared library + native UI myself):
1. The web still exists. You can't practically use a Go shared library on the web. And you probably don't want your shared library written in JS.
2. In my experience, most of the coordination is about the UI, not the underlying implementation. So the human cost isn't reduced much with shared libraries.
3. At a big company, "feature teams" can't easily ship native desktop UI because feature team eng only knows web...
I do think this approach is super viable with a product development approach that is more waterfall, however. Where a team owns the platform and it's design.
>feature teams" can't easily ship native desktop UI because feature team eng only knows web...
This is the bane of a lot of the native developer's existence. Add to that the designers that only know how to use Sigma plugins and it just makes it worse.
Separating the UI from the functionality is not as easy as it sounds. Often the first iteration of a program has the business logic tightly coupled to the UI, and is designed for a single platform. You need engineers with foresight to refactor before it becomes a mess
Also even the non UI is not trivial. I once worked on a very la4ge code base that was console only. We en we eventually gave up on our Windows and Mac ports. Granted it was C++ …
Why not use a common library, where platform teams can update what features they use from it at their own pace?
Or why not use some other tech that allows multi-platform native shipping? The company I just started at, RemObjects, builds software for Mac and Windows (and iOS etc) from a common codebase. They just keep the UI separate, and all that is done when there's a new feature is _only_ UI layer coordination.
So an app has a C# (say) or Go codebase, and a UI layer in WPF and Cocoa.
I feel like coordination cost goes way down with both of these:
a) Library approach: central functionality, platform teams not tied to specifics
b) Shared codebase where all logic lives: platform teams do only UI
Edit: forgot to add, all this is can be across languages, ie maybe you have a Go shared library and write your Cocoa UI layer in C#, that's fine, their tech makes it all interop.