1. 16
  1.  

  2. 3

    There’s plenty of good comments on this story on HN https://news.ycombinator.com/item?id=20695806. I like reading the experiences of people trying to use code-sharing solutions on mobile - consensus seems to be that it usually isn’t worth it.

    1. 2

      I am reading comments (and judging from my own experience slightly differently though).

      • If the app has sufficiently complex UIs that leverage platform-specific code, that prevents usage of something like Xamarin or ReactNative , then coding for each platform will be needed. In this scenario, trying to share ‘business logic’ modules in C++ will not work well. That’s the experience of the article authors. And I suspect most will agree.

      • If, on another hand, an app has sufficiently ‘standard’/‘vanilla’ UI needs that can be covered by Xamarin or React Native – than that’s the path that should be taken.

      In other words, what drives ability to share ‘business logic’ between Ios and Android, is the basic ability to share UI code. And if UI code cannot be shared, neither can be business logic.

      Unlike Xamarin, React Native can, also, be embedded into otherwise native application.

      Therefore, with React-Native, a ‘hybrid’ app can be created, where some UI code is native widgets, and some ‘activities’ or ‘screens’ are done in React Native. This let’s developers to compose the application from the two UI stacks (that look native to the end user). The screens that share the UI code, then, can also share the logic. Which, subsequently minimizes the code duplication, yet gives the flexibility to decide if something really needs to be done using native widgets – without recoding the whole solution.

    2. 1

      Not that this is really a rare case, but I only know this from smaller companies and this made me wonder a little:

      This group started the C++ project and trained other mobile developers at Dropbox on how to contribute to the codebase.

      Over time, these developers moved on to other teams and other companies. The engineers who remained did not have sufficient experience to fill the technical leadership gap that opened up, and it became increasingly difficult to hire replacement senior engineers with relevant C++ experience who would be interested in mobile development.

      How can that happen at a company that size that they had to abandon this (to me) core functionality because the “new” people weren’t trained up to the level needed to use this? Wow.