人们普遍认为，如果想构建一个良好的移动应用，则必须建立iOS和Android两个版本。与此同时大多数企业想要的是：只实现一次业务逻辑，并快速打包成具有原生体验感的用户界面。
作者
GaryHunter
译者
弯月，责编
郭芮
以下为译文：
直到去年，我们公司的主要应用EasyDietDiary还只有iOS原生版本。这是一款澳大利亚的通用减肥跟踪应用，另外还有一个面向研究以及不幸患有肾病用户的特殊版本。该应用程序的大致状况如下：
拥有75,行ObjectiveC和Swift代码；亚马逊AWS后端：DynamoDB、Postgres和S3；每天都有22,名用户和万次下载。后来，Flutter问世了（Beta版于年4月2日问世）。Flutter能够为我们提供足够多的功能：跨平台、良好的性能、快速实现、原生体验、开源，我们只需构建Flutter一个版本，就可以同时服务于iOS和Android。
六个月后，我发布了GoogleOpenBeta，却没有使用原生代码。
本文是在OpenBeta的基础上：
通过谷歌应用商店发布Android版本；直接替换掉苹果的应用商店中原有的iOS原生应用。本文的主要内容包括：
代码行数与开发速度GoogleOpenBeta架构后端服务（亚马逊AWS）性能原生代码跨平台设计风格与方案总结后记
代码行数与开发速度
在导入代码的时候，我真实地感受到了声明式编程的效率有多么高，而且摆脱基于XML的故事板的束缚，能够重用界面代码是多么方便。好吧，随着JetpackCompose和SwiftUI的推出，似乎这些也习以为常了。
最终我获得了35,行Dart代码。此外，还有3行Objective-C/Swift代码负责处理HealthKit等iOS特定的逻辑，以及行Java图像处理代码。
导入完成后，Flutter应用的代码行数只有iOS原生应用的一半。
GoogleOpenBeta
我花了大量时间通过苹果的TestFlight流程来操纵应用，却发现将一个不断发展的应用交到广大用户手中是多么艰辛。而且我觉得短期内这种状况还无法得到改善，因为苹果认为其审核流程是确保应用符合某些标准的方式，他们并没有恶意刁难。对于能力很强的热心开发人员来说，可能会觉得很受打击。
相比之下，广大用户可以利用GoogleOpenBeta的流程，在应用商店中像搜索其他应用一样搜索测试版的应用，而且还可以无缝地加入测试版程序，使用这些应用并提供（有限的）反馈。如果你对OpenBeta版本感到满意，那么就可以升级到正式版本。如果应用的使用合理，那么用户很快就会接纳并提供建设性的反馈。至少我个人的经历如此——这是一种良好的开发方式。
随着我添加功能和修复错误，EasyDietDiary累积了10,个beta用户。于是，3月份我发布了1.0Android版本。
架构
去年刚开始的时候，我还不熟悉声明式UI编程以及随之而来的状态管理。对我来说，依赖于异步流的Redux和BLoC学习曲线十分陡峭，最终我利用InheritedWidgets在部件树中实现了状态同步。我想方设法将业务逻辑与表示逻辑分开，但并没有使用状态管理框架来强制两者的分离。
从那以后，有关状态管理的方法和热烈讨论与日俱增。将Flutter中状态管理的开源演变与SwiftUI的响应式编程框架（另一个更大的团队正在秘密开展工作）的开发进行对比是一件有趣的事情，这颇像史蒂夫·乔布斯的风格。MattGallagher对苹果的Combine框架进行了一些有趣的分析。
在年的GoogleI/O大会上，为了减少开发人员对于状态管理的恐惧心态（我认为部分原因是如此），并抑制越来越多的InheritedWidget封装库的出现，Flutter团队宣传了由RemiRousselet开发的provider小部件，详细说明