在开始之前，我想澄清所有工具都是为解决问题而创建的，但它们都没有解决所有问题。如果您的开发团队匆忙，或者高质量的UI不是主要优先事项，请继续选择像Xamarin或Flutter或React Native这样的“端到端”开发平台来为Android和iOS编写应用程序代码。你可以完成工作！
现在，如果您已经拥有应用程序的UI，或者您希望为每个平台优化UI，那么您将需要使用Kotlin Multiplatform。原因？它根本不做UI（至少还没有）。但它的确做到了 - 而且非常好 - 是Android和iOS应用程序的业务逻辑。
虽然其他多平台解决方案希望支持所有应用层，但它们无法充分覆盖所有应用层。
无论如何，跨平台共享UI代码并不一定是可取的。通常，当完成此操作时，需要进行多次迭代才能使UI看起来更具原生性。这将耗尽开发周期，给您的开发团队带来更多压力，以便按时交付。通常，该业务正在推动更多功能而不是UI质量。共享UI是有风险的，对于士气或业务而言，它很少有用。
与Xamarin，Flutter或React Native不同，Kotlin Multiplatform并不属于自己的生态系统。相反，它非常像一本“选择你自己的冒险”一书，这就是它如此强大的原因。
虽然KMP目前拥有有限的库（虽然数量正在增长），但它确实使您能够使用iOS和Android上的所有现有库和工具，因此无需等待库或实施黑客和解决方法。你不能用Flutter或React Native做到这一点，而不会遇到相当大的障碍。
Kotlin Multiplatform的输出只是Android上的另一个软件包和iOS上的框架。这可以节省大量的时间和麻烦，因为编写桥接代码或完全重写其他解决方案中缺少的东西的时间要少得多。
要在Flutter中编写业务逻辑代码，您的团队首先必须使用小众语言编写共享逻辑--Dart - 在新的生态系统中，使用较小的社区，并且难以将其与现有代码连接起来。在React Native中，您的移动团队需要沉浸在JavaScript的新IDE和其他工具的Web生态系统中。在Xamarin中，他们必须使用C#编写代码，使用Visual Studio，以及一个较小的，不太活跃的社区。更糟糕的是，无论您的团队使用哪种平台，他们都需要在本机和非本机代码之间建立通信桥梁。
但是，在Kotlin Multiplatform中，您的团队可以编写特定于平台的业务逻辑，与本机平台直接通信，无需等待库或实施黑客或变通方法。
（如果你愿意，你可以选择。这也是你选择的冒险的一部分。）即使有任何问题，与Kotlin Multiplatform的可选共享意味着你只需要恢复与问题直接相关的代码 - 不要撕掉整个引擎，因为一个坏的火花塞。所以，你总是有选择。
当然，这很重要，因为它是决定应用程序中所有功能如何工作的业务逻辑。因为您为此层编写了一次本机代码，所以可以加快开发时间并帮助确保可靠的代码库。另外，编写一组本机代码是一种非常有效的方法，可以为以后的版本提供面向未来的代码。
换言之，Kotlin Multiplatform为您的开发团队提供了更大的灵活性。
其他多平台解决方案基本上是专有的，导致供应商锁定。它还导致需要实际管理第三个平台，因为生态系统与本机平台太不相同，并且因为它们试图解决所有问题，但它们无法解决所有问题，您需要编写更多特定于平台的代码比宣传的。
与Xamarin和React Native不同，Kotlin Multiplatform不需要VM。Flutter不需要生产中的VM，但它确实将您置于非本地生态系统，使用非本地语言编写，这与Kotlin Multiplatform不同，Kotlin Multiplatform尊重每个平台的本地语言和生态系统。Kotlin Multiplatform是您的团队目前可以使用的最原生的多平台解决方案。
KMP并没有隐藏您正在处理多个平台的事实，因为它已经编译为iOS或Android的本机库。
没有中间层可以处理，几乎消除了任何互操作瓶颈。由于Kotlin Multiplatform与原生平台生态系统协同工作而不是自己的生态系统，开发人员可以使用他们一直使用的工具和库，包括SwiftUI和Jetpack Compose等新平台创新。您遇到的限制并非死胡同，因为您始终可以使用Kotlin，Swift或其他语言对其进行编码，以便以最小的风险解决问题。
总而言之，这就是我们如何衡量多平台解决方案的世界。下周，我们将分享有关我们排名细节的更多细节。在此期间，如果您有兴趣与我们讨论Kotlin Multiplatform，请与我们联系。
