直播App开发

项目背景

这是一个直播类 iOS 应用的交付项目：单个 Objective-C 工程，体积约 590MB，最后一次提交在 2024 年 1 月。需要在一开始就说明性质——这是「上架交付」，不是从零开发的完整产品。工作内容集中在工程整理、第三方 SDK 集成与上架材料准备，使应用能够通过 应用商店 的审核流程。

客户当时的状态

直播类应用在上架环节有一类典型受阻：审核方认为应用与已有产品内容重复，或者判定为没有实质内容的壳应用，直接拒审。这类问题不解决，工程改得再多也上不了线。另一方面，直播应用普遍依赖多个第三方 SDK（推流、播放、美颜、统计一类），这些 SDK 版本之间、与系统版本之间存在兼容关系，集成顺序和配置项错一处就可能导致启动崩溃或功能异常。此外，上架需要的隐私声明、权限说明、审核备注等材料，如果不提前准备，会反复来回。

我们的做法与取舍

第一个取舍是把审核通过当作明确目标来组织工作，而不是先埋头改功能。这类项目的成败标准就是能不能上线，围绕这个目标来排序工作，优先级才清楚。

第二个取舍是逐个梳理第三方 SDK 的集成关系，把版本与配置固化下来。直播应用的工程体积大（约 590MB），很大一部分来自这些依赖，理清依赖关系比写新代码更重要。

第三个取舍是如实划定交付性质。这个工程交付的是可上架的包体与其配套材料，不等于一个从零开发的完整直播产品。区分清楚，客户对交付物的预期才不会错位。

系统怎么承载这条链路

工程是原生 Objective-C 结构，按模块组织，第三方 SDK 以依赖形式接入，各自的初始化时机与配置项按集成要求处理。交付内容包括整理后的工程、可上架的构建版本，以及配套的上架材料。整个链路是「工程整理 → SDK 集成与验证 → 材料准备 → 提交审核」。

交付状态与边界

代码库最后一次提交在 2024 年 1 月，交付后没有再更新。边界需要写清楚：交付性质是上架交付，我们负责工程整理、SDK 集成与上架材料准备，不包含从零开发一套完整的直播产品；应用内的内容与运营责任由客户承担，平台侧的内容审核机制由客户按其制度执行；应用商店 的审核结论由应用商店侧作出，我们提供的是使之具备上架条件的工作，不对审核结果做保证；第三方 SDK 的授权与费用由客户与其供应商之间处理。