react-native@0.50.1 依赖的是 facebook 精简之后的 boost_1_63_0 版本，而不是官方在 sourceforge 上发布的那个版本。
官方发布的版本是这样的。
curl -Lo boost_1_63_0.tar.gz \
https://sourceforge.net/projects/boost/files/boost/1.63.0/boost_1_63_0.tar.gz
shasum -a1 boost_1_63_0.tar.gz # macOS, = 2cecf1848a813de55e5770f324f084c568abca0a
sha1sum boost_1_63_00.tar.gz # Linux, = 2cecf1848a813de55e5770f324f084c568abca0a
而 Facebook 自己改过的版本是这样的。
curl -Lo boost_1_63_0.tar.gz \
https://github.com/react-native-community/boost-for-react-native/releases/download/v1.63.0-0/boost_1_63_0.tar.gz
shasum -a1 boost_1_63_0.tar.gz # macOS, = c3f57e1d22a995e608983effbb752b54b6eab741
sha1sum boost_1_63_00.tar.gz # Linux, = c3f57e1d22a995e608983effbb752b54b6eab741
这是个比较大的坑。
依赖第三方开源 lib，文件名与第三方官方 release 的文件名一致，内容却是自己修改过的。稍不注意就会上当。
因为之前有习惯先通过别的途径下载这个大文件，手动放置到 ~/.rncache 缓存目录下，所以发现了这个问题。
补充说明，为什么说这是一个坑。
react-native run-ios
在模拟器上运行 ios 版本的时候，脚本会首先编译 ios 版本的 app 出来。从安装脚本 node_modules/react-native/scripts/ios-install-third-party.sh
文件最后部分可以看到，会下载编译 ios 版本所需要的几个第三方库并编译。其中就包括了 boost_1_63_0.tar.gz 这个第三方库。
在一个多月前，大约 react-native@0.48.x
版本的时候，facebook 还是依赖的官版 boost_1_63_0，可能是发现某些国家的码农反映比较强烈，因此转成依赖自己精简过后的 boost_1_63_0。官版的 boost_1_63_0.tar.gz 文件有 93MB 之大，某些国家的码农无论访问 sourceforge（boost 官版的发版平台）还是 github 都很慢，几乎所有要在新环境运行项目（包括想要尝鲜）的码农们都遇到过下载这个大文件失败的情况。一个第三方依赖库下载失败，错误信息常常隐藏在大段大段的日志中，尝鲜的人容易漏掉，并且造成一种『ReactNative 不成熟，「Hello World」都不容易跑起来』的第一印象。有经验的码农们能发现这个问题，也不容易解决。即便有能力找到快速的源预先下载好依赖，自动化构建的过程被破坏了，也是一种非常糟糕的体验，对一个开源的框架来说，不能容忍。
所以，从前段时间开始，大约是 react-native@0.50.x
，Facebook 开始使用一个精简版的 boost 库。就像 google 自己的 boringssl
库 一样，facebook 以社区的名义为了这事儿维护了一个自己的版本。好在，目前来看，仅仅是一个精简官版的工作，还不涉及到修改。
出发点是一个好事儿，但是这么一来，增加了项目管理和维护风险。起步的小伙伴们，要小心一点。
