React Native 团队在这个 App 开发的过程中开发出了 React Native 平台，提供我们需要的组件和接口，使得我们的 App 成为可能。将来这些组件也会给所有的 App 开发者带来便利。即使我们不得不自己实现一些组件，在纯 native 之上使用 React Native技术 也是值得一试的。这些组件是我们不得不实现的，并且可能将来也不会被其他团队重用。
对于我们的教训是，即使有大量的工具和自动化脚本，要跨两个分离的 iOS 和 Android 代码库进行工作是很困难的。在我们开发这个 App 的时候，Facebook 使用的是这种模式，所有的构建自动化工具和开发流程都做了相应的配置。不过，如果一个产品有一个共享的 JavaScript 代码库，这种模式并不合适。幸运的是，Facebook 正在往一个统一的代码库迁移 ，所有的平台合在一起，只需要一份公共的 JavaScript 代码拷贝，代码同步也不再需要了。
我们遇到的另一个问题跟测试有关。有改动时，所有的工程师都需要小心的在所有的平台上测一遍，整个流程很容易产生人为的错误。然而，使用同一个代码库开发跨平台的应用，这种问题是必然存在的。即便如此，React Native 带来的开发效率以及一开始就在跨平台开发中重用代码带来的优势，远远超出测试不充分导致的偶发问题造成的代价。要知道的是，这个问题不光是产品开发工程师会遇到，React Native 平台开发工程师在开发 Objective-C 和 Java 的时候也会遇到。这些工程师大部分时间都不会只面对一门编程语言。同样，这个问题也会影响JavaScript，例如，开发组件 API 或者部分共享（partially shared）的实现。通常，纯 iOS 开发工程师是不需要测试 Android 上的改动的，对 Android 工程师也是如此。这主要还是一种文化上的差异，需要时间和努力去消除，在这个过程中我们产品的稳定性也在增强。
为了解决这个问题，我们还开发了每次构建都会执行到的集成测试。然而已有的持续集成系统只能在 iOS 平台和 Android 平台分别发现 iOS 和 Android 问题，不能做到在 iOS 的构建上运行 Android 测试，反过来也不行。这需要工程师去解决，不过还是有很多问题，可能会导致app出错。
当这些都搞定之后，我们可以在两个平台上一起发布 Facebook 第一个完全构建在 React Native 上的 app，有着 native 的外观和体验，由同一个 JavaScript 工程师团队完成。当这些工程师加入团队的时候，不是每一个人都熟悉 React Native，然而他们在仅仅5个月的时间就开发出了有着 native 外观和体验的 iOS 版本的 app。在3个月之后，他们发布 app 的 Android 版本。
英文原文：React Native for Android: How we built the first cross-platform React Native app