跨平台 App 开发一套代码，iOS 与安卓双端

• 产品带设备、需要配套 App 的公司：传感器、摄像头、控制器、仪表——App 是设备的遥控器与显示器。

• 不想做「通用 App 外包」交付的客户：设备类 App 的难点在配网、断线重连、推送到达率，不在 UI 套模板。

• App 与设备两家供应商扯皮中的团队：App 说设备没发数据、设备厂说 App 没连上，没人能查整条链路。

• 要同时覆盖 iOS 与 Android 的客户：双端功能与发布节奏要保持一致，跨平台是自然选择。

XTELL 的移动 App 开发不是单卖前端：App 与它背后的服务端由同一支团队设计、开发、联调。433MHz 安防联动系统的 Flutter App 与 NestJS 后端就是这样一起交付的——App 的每个功能在后端有对应的接口与消息链路，配对、状态、报警在方案阶段就整体定义。这条规则的原因很实际：设备类 App 的问题大多出在 App 与后端、设备之间的边界上，前后端分家时，边界问题就是没人能独立解决的孤儿。

多数跨平台 App 开发公司说的「跨平台」只有一层意思——一套代码同时跑 iOS 与 Android。在 XTELL 它还有第二层：App 要对话的那台设备，固件也是同一支团队写的。软件侧跨平台，硬件那道边界也跨。做移动应用开发的公司能把界面做出来，但界面表现如何，取决于设备那一侧。

433MHz 安防联动系统的手机端是 Flutter 双端 App（iOS 与 Android）：go_router 管理路由，provider 管理状态，dio 负责网络请求；扫码配网完成设备绑定，WiFi 扫描辅助接入网络，视频经 VLC 播放 RTSP/HLS 流，报警推送实时到达。工程结构与插件选型按双端一致的行为组织——同一套业务逻辑在 iOS 与 Android 上表现一致，不需要两套测试口径。

超声触摸屏系统用 Android 平台做医疗设备的触摸交互开发：M8 Touch 通信协议与设备交互，系统化的 UI 效果图与切片管理保证界面一致性，TouchControl 负责触摸控制。难点是在医疗设备上实现稳定流畅的超声影像界面与触摸交互。这是原生 Android 开发的实例——医疗场景对界面稳定性与响应确定性的要求，高于一般消费 App。

Apollo2 低功耗显示终端是 App 之外的另一端：设备用 Apollo2 MCU 做主控，低功耗模式待机，SMX 布局优化显示，多版本 BSP 支持不同功能配置，Keil/IAR/GCC 多工具链开发。设备侧界面（终端显示）与手机端 App 的信息分工在方案阶段统一设计——本地显示什么、App 显示什么、断网时各自怎么表现，都是同一支团队定的。连接设备的产品里，App 从来不是孤岛。

XTELL 的默认路线是 Flutter 跨平台：一套代码覆盖 iOS 与 Android，业务逻辑复用，双端行为一致——433MHz 系统的 App 就是这么交付的。边界也很明确：深度依赖平台能力或对响应确定性要求极高的界面，原生更合适——超声触摸屏系统用原生 Android 正是这类判断的结果。选型时不纠结信仰，按功能需求与维护成本算账，方案阶段把选择理由写清。

配网决定设备类产品的留存：用户第一次开箱十分钟连不上网，后面的一切都白做。433MHz 系统的 App 用扫码配网绑定设备、WiFi 扫描引导接入，把手工输入 SSID 与密码的出错环节砍掉。配网流程的设计原则：每一步失败都要有明确反馈与出路——配网失败是设备问题还是网络问题，App 界面上要能分清，排查日志要能定位。

摄像头类产品的 App 视频不是「调个播放器」：433MHz 系统的 App 经 VLC 播放 RTSP/HLS 流，视频链路后端由 ZLMediaKit 做流媒体转发。要处理的真实问题：起播延迟、切后台回来要不要续流、弱网下清晰度怎么降、报警瞬间视频与推送谁先到。视频体验是安防类产品的核心指标——链路从摄像头经服务端到 App 每一环都在我们手里，问题不用跨供应商定位。

设备报警的价值等于「报警到达用户的概率」。433MHz 系统的报警链路：设备经 MQTT（EMQX 代理）上报后端，后端确认状态后触发 App 推送——推送与设备状态的时序关系由后端统一保证，避免「推送到了、状态还没更新」的错位。到达率的敌人是系统级省电策略与权限设置，App 侧的引导流程与后端的重发策略要配合设计，这是连接设备 App 与普通 App 的又一处不同。

XTELL 负责。固件、App、后端在同一支团队手里：App 连不上设备时，我们直接打开固件看设备到底广播了什么、后端有没有收到注册——「设备没上报」这类现象描述会被具体到报文与时间戳。设备类 App 项目里，联调占的工期常超过开发本身，联调能力跨层与否直接决定交付节奏。

Flutter 工程的基础选型决定后续维护成本。433MHz 系统 App 的组合：go_router 管理路由与深链、provider 管理状态、dio 处理网络请求与拦截。选型原则是「主流、稳定、可替换」——不为小众库的新特性引入维护风险。工程结构按业务域组织，新成员接手时按目录就能读懂功能划分。

1. 需求评估：提供设备类型、通信方式与 App 功能清单，确认跨平台或原生的技术路线。

2. 方案与合同：界面流程、接口定义、里程碑写清；App 源码与后端源码是否交付、按开源还是闭源模式，逐项在合同中约定，页面上的任何描述都不构成统一承诺。

3. 开发与联调：App、后端、设备侧并行推进，配网、视频、推送按链路整体验证。

4. 交付：范围以合同为准；交期与报价评估后给出，本页不写死数字。

XTELL（深圳市极智未来科技有限公司）2016 年成立于深圳，至今十年，交付过 100 多个项目，客户以欧美 B2B 企业为主。业务覆盖从电路板到云端的每一层：PCB 设计、FPGA、嵌入式固件、Linux BSP、设备界面、手机 App、服务端与物联网平台。