原生还是跨平台移动应用？

位于匈牙利布达佩斯的软件开发公司 Mesterséges Intelligencia Központ Kft. 认为，当应用需要深度使用设备时，就需要原生应用；如果两个平台需要相同的功能，共用一套代码库更便于维护。

要点：决定取决于功能，而不是潮流：应用需要在多大程度上深入调用设备、对性能有多高的要求，以及由谁来维护它很多年。如果在应用商店上架和深度访问设备都不重要，一款 Web 应用（PWA）可能就已足够。无论选择哪条路，后端系统、应用商店规则以及操作系统的定期更新都会占据工作量的很大一部分。

原生应用、跨平台应用和 Web 应用分别是什么？

移动应用可以通过三种方式构建：针对每个平台分别开发，使用平台自己的工具；用一套共享代码库，编译到两个平台；或者使用 Web 技术，在浏览器中运行。三条路都能产出可正常运行的应用，区别在于设备访问、维护，以及应用需要按照谁的规则更新。

原生应用

对于原生应用，iOS 版和 Android 版分别开发，各自使用平台自己的语言和界面工具。在 iOS 上，目前通常是 Swift 语言和 SwiftUI：据 Apple 介绍，SwiftUI 采用声明式语法，以 Swift 语言为基础，可以在 Apple 的所有平台上构建用户界面（Apple: SwiftUI）。在 Android 上是 Kotlin 和 Jetpack Compose：Google 称 Jetpack Compose 是 Android 推荐的、用于构建原生界面的现代工具包（Android Developers: Jetpack Compose），并建议新的 Android 应用从 Kotlin 起步（Android Developers: Kotlin-first）。原生路线的优势在于，平台的每一项新功能从第一天起就可以直接使用；缺点是需要开发和维护两套代码库。

跨平台框架

借助跨平台框架，iOS 应用和 Android 应用都由一套共享代码库构建。四种常见的方式：

Flutter：使用 Dart 语言的框架。根据其文档，Flutter 自行实现每一个界面控件，而不是使用系统自带的控件，并使用名为 Impeller 的引擎进行渲染；平台自身的代码可以通过所谓的平台通道调用（Flutter: Architectural overview）。
React Native：基于 React 和 JavaScript；按照该项目自己的说法，它用 JavaScript 编写，但以原生代码呈现，因为其基础组件会映射到平台的原生界面构建块（React Native）。从 0.76 版起，所谓的新架构成为默认设置，它用 JavaScript Interface（JSI）取代了异步桥接（React Native: New Architecture）。
Kotlin Multiplatform：JetBrains 的开源技术，可以在 Android、iOS、桌面、Web 和服务器端目标之间共享代码。既可以只共享业务逻辑、保留原生界面，也可以借助 Compose Multiplatform 把界面也一起共享（Kotlin: Kotlin Multiplatform）。根据 Kotlin 的文档，Compose Multiplatform 在 iOS 上也已达到稳定级别（Kotlin: stability of supported platforms，2026 年 10 月 17 日核实）。
.NET MAUI：Microsoft 的框架，使用 C# 和 XAML，可以用一套共享代码库为 Android、iOS、macOS 和 Windows 开发应用；它是 Xamarin.Forms 的演进版本。构建 iOS 和 macOS 应用需要使用 Mac（Microsoft Learn: What is .NET MAUI?）。

渐进式 Web 应用（PWA）

PWA 是在浏览器中运行的 Web 应用，可以安装到主屏幕上，并通过渐进增强（progressive enhancement）提供更可靠的体验。web.dev 的概述指出，平台应用在功能方面最强，Web 应用在覆盖面方面最强：一套代码库就能触达任何人、任何设备（web.dev: Progressive Web Apps）。在 iOS 和 iPadOS 上，自 16.4 版起，添加到主屏幕的 Web 应用也可以请求推送通知权限（WebKit: Web Push for Web Apps）。一个重要的限制：根据 App Store 审核指南第 4.2 条，应用提供的内容应多于重新打包的网站，因此仅仅把网站包装成应用提交到应用商店并不可取（Apple: App Store Review Guidelines）。

对比一览表

要素	原生（Swift、Kotlin）	跨平台（Flutter、React Native、KMP、.NET MAUI）	PWA
性能	可以直接用平台的工具进行优化	计算密集的部分可以放到原生代码中	取决于浏览器和 Web 技术
设备访问	平台的所有功能，从第一天起	通过框架或插件；新功能要晚些时候才能使用，或者需要额外的原生代码	仅限于浏览器支持的 Web 接口
外观与手感	完全是平台自己的组件	Flutter 使用自绘组件，React Native 使用原生组件	类似网页，取决于浏览器
代码共享	没有，两套独立的代码库	逻辑共享，界面通常也共享	一套代码库适用于所有设备
团队	分别需要 iOS 和 Android 专业知识	一个团队，但也需要懂原生层	Web 开发团队
维护	两套代码库都要跟进平台的定期变化	一套代码库，另加框架自身的更新	无需在应用商店发布，但要跟进浏览器的变化
应用大小	基于系统自带的库	框架的引擎也会被打包进应用	没有安装包，由浏览器缓存
应用商店上架	是	是	不需要；如果打包后上架应用商店，则受第 4.2 条的限制

Flutter 的文档明确指出，Flutter 应用的安装包是自包含的，包含运行所需的全部代码和资源，因此其大小可能是一个需要考虑的因素（Flutter: Measuring your app's size）。在实践中，这一差别很少起决定作用，但如果目标用户使用的是较旧的设备或网络连接较差，就值得了解这一点。

分别适合什么情况？

适合原生的情况

应用需要深度使用设备：摄像头、传感器、蓝牙、后台任务；
对性能要求高，例如实时图像或音频处理、复杂动画；
需要立即利用平台的最新功能；
只需要面向一个平台的应用，或者两个版本差异很大。

适合跨平台的情况

两个平台需要相同的功能，并且改动需要同时出现在两个平台上；
应用主要由表单、列表、数据展示和通知构成（大多数企业应用都是如此）；
由一个团队长期维护该应用；
企业已经在使用该框架的语言，例如具备 Web 端 React 技能时倾向于 React Native，具有 .NET 背景时倾向于 .NET MAUI。

适合 PWA 或 Web 应用的情况

用户不是在应用商店里搜索这款应用，而是通过链接或网站访问；
不需要深度访问设备；
应用需要在台式电脑和手机上以同样的方式运行；
无需应用商店审核的快速更新比平台功能更重要。

这里的界限同样不是泾渭分明的。例如，借助 Kotlin Multiplatform，业务逻辑可以共享，而界面保持原生；在 Flutter 和 React Native 中，关键部分也可以用原生代码编写。我们自己网站上的游戏就是作为 Web 应用运行的：无需安装，直接在浏览器中运行，在台式电脑和手机上表现一致。关于 Web 路线，我们在网站建设与 Web 应用开发页面中有专门介绍。

后端系统与管理后台

移动应用很少能独立存在。一旦它有了用户账户、共享数据或通知，背后就需要服务器：账户、数据和权限都保存在那里，通知也从那里发出。后端系统通常通过专门的服务发送推送通知；例如，Firebase Cloud Messaging 是一种跨平台的消息传递解决方案，由可信的服务器环境构建消息，并将其发送到 Apple、Android 和 Web 应用（Firebase: Cloud Messaging）。

管理后台是后端系统的控制面板：可以在浏览器中编辑内容、管理用户和设置，日常的改动无需开发人员参与。我们也会把现有的企业系统，例如客户管理系统、库存管理系统或开票软件，接入到这里，让应用与企业其他部门使用同样的数据。如果还没有这样的系统，我们也可以把它作为定制软件开发出来。原生还是跨平台的决定并不影响后端系统：同一台服务器既可以为原生应用提供服务，也可以为用 Flutter 开发的应用提供服务。

应用商店发布：2026 年 10 月需要注意什么？

应用商店的规则经常变化，因此以下内容均注明日期（2026 年 10 月 17 日核实）。

App Store（Apple）

审核指南：App Store 审核指南最近一次更新于 2026 年 10 月 16 日。根据第 2.1 条，提交的应是可供审核的完整版本；如果应用有登录功能，必须提供演示账户，而且后端系统在审核期间也必须正常运行。根据第 5.1.1 条，每款应用都必须链接到其隐私声明；如果应用支持创建账户，也必须在应用内提供删除账户的功能（Apple: App Store Review Guidelines）。
隐私详情：必须在 App Store Connect 中申报应用的数据处理做法，包括所集成的第三方组件（例如分析 SDK）的做法；提交新应用和更新时都需要提供这些信息（Apple: App privacy details）。
开发工具要求：自 2026 年 4 月 28 日起，上传到 App Store Connect 的应用必须使用 Xcode 26 或更高版本、以 iOS 26 SDK 构建；自 2026 年 9 月 9 日起，iOS 和 iPadOS 应用的目标版本必须至少为 iOS 13（Apple: Upcoming requirements）。
公司账户：以组织身份注册时，公司必须是法律实体，并拥有 D-U-N-S 编码（邓白氏编码），注册人必须有权代表公司承担法律义务（Apple: Enrollment）。
欧盟的交易商身份：Apple 要求开发者声明自己是否属于欧盟法律意义上的交易商；在欧盟境内，交易商的联系方式会显示在应用的商店页面上（Apple: Digital Services Act trader requirements）。

Google Play

目标 API 级别：自 2026 年 8 月 31 日起，面向手机的新应用和应用更新必须以 Android 16（API 级别 36）或更高版本为目标；现有应用必须以 Android 15（API 级别 35）或更高版本为目标，才能继续向运行较新 Android 版本的设备上的新用户提供。如在 Play Console 中申请延期，截止日期为 2026 年 11 月 1 日（Android Developers: Target API level）。
个人账户的测试要求：对于 2023 年 11 月 13 日之后创建的个人开发者账户，在正式发布之前必须进行封闭测试，至少要有 12 名测试人员，且他们已连续参与至少 14 天（Play Console Help: testing requirements）。
组织账户：没有 D-U-N-S 编码就无法创建组织开发者账户（Play Console Help: creating an account）。
数据安全表单：每款在 Google Play 上发布的应用都必须填写，即使应用不收集任何用户数据（Play Console Help: Data safety）。
账户删除：如果可以在应用中创建账户，就必须让用户既能在应用内、也能通过网页链接请求删除账户及相关数据（Play Console Help: account deletion requirements）。

无论采用哪种技术，这些规则都同样适用：用 Flutter 或 React Native 开发的应用，必须满足与原生应用相同的目标 API 和 SDK 要求；框架的更新必须跟上这些要求。我们建议开发者账户归客户的公司所有：这样应用会以贵公司的名义上架，商店页面也始终归贵公司所有。

无障碍

两个平台都内置屏幕阅读器（iOS 上是 VoiceOver，Android 上是 TalkBack），并提供接口，让应用能够与这些辅助技术协同工作（React Native: Accessibility）。例如，Flutter 的文档建议：屏幕阅读器应能清楚地描述每一个控件，文本与背景之间的对比度至少为 4.5:1，每个可点按的元素至少为 48×48 像素（Flutter: Accessibility）。Android 的文档推荐使用 Material Design 指南、Accessibility Scanner 工具和自动化检查来发现问题（Android Developers: Accessibility）。

这不仅仅是良好实践：根据指令 (EU) 2019/882，成员国自 2025 年 6 月 28 日起必须对面向消费者提供的电子商务服务，包括通过移动应用提供的服务，适用无障碍要求（匈牙利的规定以该指令的转化为基础）；提供服务的微型企业必须获得豁免（EUR-Lex：指令 (EU) 2019/882）。关于网店的具体细节，请见网店：租用式平台还是定制开发？一文。

人工智能：在设备上还是在云端？

在移动应用中，AI 功能可以在两个地方运行：在手机本身上，或者通过后端系统，在云端的大语言模型中运行。

在设备上（Apple）：从 iOS 26 起，Apple 的 Foundation Models 框架可以访问为 Apple Intelligence 设计的、在设备上和 Private Cloud Compute 上运行的模型；它可用于文本生成、结构化输出以及调用自己的工具，但仅限于支持 Apple Intelligence 的设备（Apple: Foundation Models）。
在设备上（Android）：Gemini Nano 在 Android 的 AICore 系统服务中运行，可通过 ML Kit GenAI 的接口使用，例如用于摘要、校对、改写和图像描述。据 Google 介绍，它无需网络连接也能工作，敏感数据会保留在设备上，但模型受到令牌上限和设备硬件的限制（Android Developers: Gemini Nano）。
在云端：OpenAI（ChatGPT）、Anthropic（Claude）和 Google（Gemini）的大语言模型，适用于更复杂的任务，例如依据企业自有资料作答的助手、文档和图像处理、摘要。AI 服务的访问密钥保存在后端系统中，而不是手机上：这样就无法从应用中提取密钥，使用情况也可以在服务器端进行控制。

在设备上运行的模型因数据保护和离线运行而颇具吸引力，但并非每位用户的设备都支持，因此通常值得同时设计一个云端备用方案。关于模型的接入，请见 AI 集成页面。

维护工作取决于什么？

移动应用在交付后也并非就此完成：它的环境在不断变化。维护工作主要取决于以下因素：

操作系统和应用商店的要求：Apple 要求上传时使用更新的 Xcode 和 SDK 版本，Google Play 则要求更高的目标 API 级别。上面的日期表明，这些要求会定期提高。
应用商店指南的变化：新的隐私申报、账户删除或测试规则。
框架更新：对于跨平台应用，Flutter、React Native 或 .NET MAUI 的大版本更新，可能意味着要在自己的代码和所用的插件中投入工作。
第三方组件：支付、地图、分析 SDK，它们也有各自的更新要求。
后端系统与集成：所连接的企业系统和 AI 服务的接口变化。
代码库的数量：两款原生应用需要在两个地方进行修改。

常见错误

技术选型取决于团队的习惯，而不是应用的功能。
只考虑了界面，没有把后端系统和管理后台计算在内。
只是把网站包装成应用，结果被应用商店拒绝。
开发者账户登记在开发公司名下，商店页面日后无法转移。
账户删除功能、隐私详情或演示账户直到提交当天才补上。
交付后的更新无人负责，一次规则变更之后，新用户就再也看不到这款应用。

常见问题

原生还是 Flutter/React Native？

如果应用需要深度使用设备（摄像头、传感器、后台进程）或对性能要求高，原生开发是更稳妥的选择。如果两个平台需要相同的功能，用 Flutter 或 React Native 开发、共用一套代码库的应用更便于维护。借助 Kotlin Multiplatform 还可以走折中路线：共享业务逻辑，界面保持原生。在首次咨询中，我们会根据具体功能提出建议。

什么时候一款 Web 应用（PWA）就已足够？

当用户通过链接或网站访问、不需要深度访问设备，并且应用需要在台式电脑和手机上以同样的方式运行时。它可以安装到主屏幕上，在 iOS 上也能发送推送通知，但不会在应用商店上架，而且可用的设备功能范围取决于浏览器。

需要后端系统吗？

几乎总是需要：只要应用有用户账户、共享数据或通知，背后就需要服务器。例外的是只在设备上存储数据的应用。后端系统和管理后台我们也会一并开发，并将其接入现有的企业系统。

由谁把应用上架到应用商店？

发布工作由我们负责：准备商店页面资料和隐私申报，提交应用，并全程跟进审核。我们建议开发者账户归您的公司所有；两家应用商店都要求组织账户提供 D-U-N-S 编码，因此最好及早申请。

维护成本取决于什么？

取决于需要维护多少套代码库、操作系统和应用商店的要求变化有多频繁、应用使用了多少第三方组件和集成，以及预计还有多少后续开发。开发的价格根据功能规模确定；具体方法见定价方式页面。

我们如何提供帮助？

我们开发 iOS 和 Android 应用：为其搭建后端系统和管理后台，接入人工智能，并一直负责到应用在商店上架。原生还是跨平台，我们会根据功能与您共同决定。这项服务的详情见移动应用开发页面。

我们以 COSMIC 功能点（ISO/IEC 19761）度量开发的功能规模，并据此编制报价和进度安排。首次咨询免费，可应要求签署保密协议（NDA），交付后我们还承担运行与维护工作。源代码和使用权由合同约定。请用几句话描述您的想法，并与我们联系。