有的项目做久了会留下一种奇怪的时间感。我是铭2015年春天入行做iOS开发到2025年正好十年。这十年里iOS从iOS 8一路迭代到iOS 18开发语言从Objective-C到Swift再到SwiftUIApp形态从纯原生到混合开发、跨端框架、小程序生态多线并行。很多当年当宝的奇技淫巧已经变成历史包袱也有很多当年踩得头破血流的坑换了个马甲又在新人面前反复出现。这篇就是我自己的十年复盘不是面面俱到的教程而是一个普通iOS开发者在这十年里怎么选方向、怎么填坑、怎么在技术浪潮里没被拍死的过程。里面涉及的具体问题和排查思路都是真实遇到过的也尽量写了“为什么”而不是只给结论。如果你正在做iOS开发、做跨端项目或者准备转移动端应该能从里面找到一些能直接用的东西。1. 2015年入行从Objective-C到Swift的切换阵痛1.1 那年的开发环境和入门路径2015年的iOS开发环境现在回头看属于“远古时代”。Xcode还是6.xiPhone 6/6 Plus刚刚把屏幕从4英寸拉大到4.7和5.5英寸App Store的审核周期稳定在7到10天。那时候入行没有现在这么多视频课最靠谱的学习路径是看Apple官方文档、看GitHub开源项目源码、再加一本《Objective-C编程》翻来覆去地读。我第一份工作是在一家外包公司入职第一天就被丢了一个iPad项目做一套企业内部报表展示应用要求支持iOS 8横竖屏都要适配。当时Auto Layout虽然已经在iOS 6就引入了但真正用起来也就那一两年很多老同事还在用frame硬算坐标。我一开始也学着用frame做结果iPhone 6和6 Plus一出来坐标全乱只能老老实实回头学约束。那时候我也第一次碰到了一个后来困扰无数人的问题iOS版本碎片化。iOS 8的用户还没升级完iOS 9的beta就出了而客户明确要求“系统低于iOS 8的不管”反倒是我们自己要小心翼翼地避免用到iOS 9的新API。这种“系统版本追赶”的节奏几乎成了往后十年iOS开发的常态。1.2 Swift刚发布时的混乱期与我的选择2014年WWDC发布Swift的时候我正在用OC写一个电商详情页。当时周围人的反应分两派一派觉得“苹果终于要改革了”一派觉得“这玩意写起来跟脚本一样不可能成气候”。我属于观望派。真正让我开始认真学Swift是2015年Swift 2.0发布、Apple宣布Swift要开源之后。但那个阶段切换到Swift痛苦是真实的。Swift 1.x和2.x的语法变动频繁今天写的代码明天升级Xcode可能就编译不过。最典型的就是println改成printString的桥接逻辑变了好几次AnyObject和Any在使用上经常让人抓狂。我有一次给一个页面做数据解析在as!强行转换的地方崩了无数次最后才发现是服务器返回的NSNull被直接当成了String。我的建议是如果你现在回头看那段历史不要觉得“Swift一出来就该全面转”。任何语言都有一个成熟周期。在Swift 2.x时期我采取的策略是新模块用Swift写老模块继续用OC维护通过桥接文件XXX-Bridging-Header.h让他们共存。等到Swift 4之后语法趋于稳定才逐步把核心模块重写。这个“渐进式迁移”的思路后来在React Native、Flutter这些跨端方案上又用了一遍也算是一套方法论了。1.3 早期常用框架与适配经验那时候的iOS开发基本离不开三件套AFNetworking网络、SDWebImage图片缓存、Masonry自动布局约束。这三样到现在看都不过时只是随着系统能力和Swift的发展很多功能被系统API或新框架替代了。AFNetworking使用的时候最需要注意的就是AFHTTPSessionManager的生命周期。很多人因为把它写成局部变量导致请求刚发出去对象就被释放了回调永远不执行。我那时候养成的习惯是网络层永远做成单例服务所有请求都走同一个manager并且统一设置requestSerializer和responseSerializer。Masonry则是解决Auto Layout代码冗长问题的利器。用frame写死坐标在3.5寸、4寸、4.7寸、5.5寸屏幕上都走不通之后我开始全面拥抱约束。但这里有个经验约束不是越多越好而是“能少则少缺什么补什么”。比如一个按钮要水平居中对齐、距离底部20pt只需要给它添加centerX和bottom两个约束再给一个固定宽高它自己就能确定位置。你不需要把leading、trailing、top、bottom全写上约束冲突往往就是这么来的。适配方面还有几个容易忽略的细节。状态栏高度和导航栏高度在不同设备上不一样iPhone X之前是20pt和44ptiPhone X之后状态栏变成了44pt导航栏整体高度变成了88pt4444Home Indicator还有额外的34pt安全区。那时候很多人做自定义导航栏结果iPhone X一发布按钮全部被刘海挡住。所以从iOS 11开始苹果引入safeAreaLayoutGuide其实就是帮开发者统一做这件事。2. 2018年的跨端混战React Native、Flutter与uni-app的真实取舍2.1 我为什么从纯原生转向跨端方案到了2018年前后业务侧的压力上来了。公司想要用一套代码cover iOS和Android甚至还要覆盖微信小程序。纯原生开发在需求快速迭代、双端人员紧缺的情况下显得越来越“重”。于是我开始认真研究React Native、Flutter以及国内团队用得更多的uni-app。先说结论跨端方案从来都不是“技术上最优雅”而是“商业和团队上最划算”。如果你的团队同时有iOS和Android两个资深工程师并且App对性能和交互要求极高那原生依然是第一选择。但如果你要在三个月内交付一套同时上iOS、Android、微信小程序的MVP纯原生就是灾难。我当时负责的是一款社区类产品功能包含信息流、用户主页、聊天、发布器。在排期不足的前提下我们团队选了uni-app Vue这套技术栈。原因很简单团队成员之前有Vue背景上手的成本低uni-app对微信小程序的支持比较成熟可以一套代码同时编译到App和小程序端。相比React Nativeuni-app的生态更贴近国内的需求场景比如微信登录、微信支付这些能力封装的粒度更细坑也更少。2.2 React Native与Flutter的浅层体验对比虽然后来生产项目用的是uni-app我也在几个Demo和工具型项目里分别试过React Native和Flutter。React Native最大的问题是“依赖原生桥接”带来的不确定性。TextInput这类基础组件的表现在iOS和Android上经常有细微差异而且原生模块升级升级着就可能出现兼容问题。我记得有一次RN升级版本后Android端键盘弹出时会把整个页面顶飞排查了很久才发现是adjustResize模式没有正确设置的锅这类玄学问题特别消耗心力。Flutter在渲染性能方面确实好因为它不走原生控件而是用Skia引擎自己画UI。但Dart语言在2019年前后的社区氛围还不算浓厚第三方库质量参差不齐。而且Flutter包体偏大——一套很小的Demo打出来也要十几MB直到Impeller渲染引擎普及后才有改善。如果你的App重度依赖原生SDK比如地图、推送、音视频Flutter那套Platform Channel通信机制写起来会比RN的桥接更繁琐。所以我的判断是如果你是个人开发者、以中小型工具类应用为目标优先考虑uni-app这类国内生态完善的跨端框架如果团队有较强的原生功底、需要做偏重交互和动画的应用Flutter更合适如果只是想在现有原生项目里局部引入跨端页面RN还是能用但要对兼容问题有心理预期。2.3 uni-app的几个移动端深坑textarea遮挡按钮、canvas导出白图、H5下载文件变预览选跨端框架不意味着坑会比原生少。这里列三个我在连续踩坑中复盘过的典型问题都是热搜词里高频出现的textarea输入时弹出的键盘盖住按钮这个问题在小程序里尤其明显。场景是页面底部有个“提交”按钮用户点击textarea输入内容时弹出的软键盘把按钮顶起来了或者反过来——按钮被键盘完全遮住根本点不到。解决方案是分两步走。第一步把按钮所在区域监听keyboardheightchange事件小程序基础库有uni-app里就是uni.onKeyboardHeightChange动态调整按钮的安全区偏移量。第二步是解决“键盘弹起后页面整体被压缩”的问题在pages.json对应页面的app-plus节点下配置softinputMode: adjustResize并在页面样式中用env(safe-area-inset-bottom)做适配。实测下来iOS端会有大约0.5秒的延迟按钮跟随会掉帧所以更好的做法是做一个自定义工具栏放在输入框上方而不要指望键盘弹起后页面还能保持原始布局。textarea输入文字失去焦点后层级盖住按钮这个更诡异。iOS端textarea在失焦后会有一个“真空期”它自身已经不在输入态了但生成的cover-view或原生组件层还没完全释放于是“一块透明的东西”盖在了按钮上点击没反应视觉上却什么都看不见。这是我做过最头痛的前端问题之一因为根本没法用普通的开发者工具复现。最终方案是失焦时加一个小延迟手动触发表单重新渲染例如在blur事件里先让按钮位置移动1px再用setTimeout在200毫秒后复位或者给textarea绑定blurhandleBlur后将它的v-if置为false等300毫秒后再恢复。这个“图层残留”的怪癖本质上是iOS WKWebView对textarea原生层复用机制的bug暂时只能靠这种触发重绘的偏方规避。uni-app canvas队列导出白图如果你用uni-app的canvas做批量生成图片比如生成带二维码的海报很可能会遇到“导出的图片是白的”。原因很简单你调用uni.canvasToTempFilePath导出的时候canvas上的绘制操作还没完成或者绘制时序因为iOS的离屏渲染缓冲被提前回收了。解决方案是严格串行化绘制流程。不要直接在onReady里一次性画完所有内容再导出而是画完一张图后在draw回调里再画下一张全部画完后再调用导出。如果绘制的图片较多建议使用队列控制每张图片用uni.getImageInfo预加载到本地缓存然后逐张drawImage最后再导出。另外记住一个细节canvas的宽高要用逻辑像素乘以pixelRatio否则在iPhone这种高分屏上导出的图会模糊但也别乘过否则内存飙升导致的“白图”也是常见现象。2.4 iOS浏览器里H5下载文件变预览的处理还有一个跟iOS浏览器强相关的坑在iPhone上通过Safari访问H5页面点击一个文件下载链接结果文件没有下载而是直接在浏览器里被打开了PDF、图片、文本类文件尤其常见。这个现象的根本原因是Safari对Content-Disposition: attachment的处理和桌面浏览器不一样它更倾向于直接预览a标签指向的资源。在iOS上真正稳妥的做法是用fetch把文件获取为Blob对象再用URL.createObjectURL生成临时地址最后通过a download触发下载。但iOS Safari对download属性的支持本来就不完整所以更可靠的方式是引导用户“在Safari中打开页面再下载”或者用Web Share API直接调起系统分享面板。面对必须静默下载的场景还有一个思路后端将文件打包成zip格式Safari对它没有原生预览能力就会走下载流程这算是取了个巧。3. 调试是门手艺从Charles抓到证书校验的一次完整排障3.1 HTTPS抓包的完整配置链路移动端调试的日常离不开抓包。我自己用的是Charles十年来基本没换过。顺手聊一下iOS上HTTPS抓包的完整链路因为很多人卡在“装了证书还是不生效”在Charles里开启SSL Proxying并添加需要抓包的域名通常直接填*全部监听。手机连上Mac同一个WiFi设置HTTP代理为Mac的IP和Charles默认的8888端口。访问chls.pro/ssl下载证书然后在系统设置中安装。关键一步iOS 10之后只安装证书是不够的还要在“设置-通用-关于本机-证书信任设置”里开启针对Charles证书的“完全信任”。如果App是Release模式或者做了证书锁定SSL Pinning光靠系统信任还抓不到。这时候就需要用到Frida、Objection这类工具绕过App内的证书校验逻辑。这一套在国内合规的测试流程里经常会用到但在生产包上我是建议保留证书锁定的否则中间人攻击风险很大。这里必须说明一点做抓包调试只能针对你自己开发的应用或者你拥有合法授权的测试场景。千万别把这套能力用在别人家的App上换个角度别人对你的App做同样的事你也会不舒服。安全能力和安全边界从来是一体两面。3.2 线上环境证书校验导致的问题排查有一次线上问题让我印象特别深用户反馈某个版本的App无法登录但攻城狮本地复现不了。后来通过日志分析发现是服务器端证书链又升级调整过而App在Release配置下开启了AFSecurityPolicy的证书校验导致新证书链不被信任。排查过程中Charles帮了大忙。我在本地把App切换成Debug模式关闭SSL Pinning然后照常抓包发现请求根本没有发出去——因为iOS的URLSession在网络层就拒绝了服务器的证书握手。再一看服务器返回的证书链发现叶子证书的颁发者是我们自己没安装到App bundle里的中间证书而不是之前信任的根证书。这个坑的教训是开启证书校验时不能只信任某一个证书文件而应该固定整条证书链如果服务器更换了CA机构就必须同步更新App内置的证书文件。否则老版本App会大面积“网络请求失败”。这也是为什么很多大厂的网络协议栈如腾讯的AnyTS、阿里的APT会内置一套证书固定机制并且做灰度更新。3.3 我常用的调试辅助工具与习惯有人说“调试能力是iOS开发的隐形天花板”我很认同。除了Charles我还会定期用这几个工具组合Reveal查看运行时视图层级排查UI约束冲突和奇怪的遮挡问题时特别好用。FLEX嵌入式调试器直接在真机App内查看网络请求、文件目录、UserDefaults。Instruments尤其是Time Profiler和Leaks定位卡顿和内存泄漏。Xcode View Debugging查看Auto Layout警告和约束冲突的具体位置。调试习惯方面我给自己定了一个原则遇到必现Bug先想“它和正常流程的差异点是什么”再想“复现的条件是什么”最后才动手改代码。因为大部分Bug都是条件触发盲目堆日志只会让问题更难定位。比如iOS 18刚发布时很多人反馈App启动白屏其实不是代码坏了而是新的SwiftUI生命周期对旧场景迁移有额外要求——调试时先看系统版本和日志能省一半的排查时间。4. 2021到2023的独立开发沉淀自动化测试、设备模拟与多机型适配4.1 XCTest与自动化测试的落地经验2020年底我离开了公司开始以独立开发者的身份接项目、做自己的产品。也就是在这个阶段我意识到一个人开发时自动化测试不是负担而是“电脑替我盯着回归”的助手。以前在公司测试用例是QA写的自己干以后你既是产品经理又是开发又是测试没有自动化测试改一个地方冒出一堆回归Bug是常态。我最常用的是XCTest框架。这里分享一个经验iOS的UI测试别一上来就写一堆XCUIApplication的点击流程那样太脆稍微改个UI元素ID用例就全挂了。更稳的做法是给关键UI元素加上accessibilityIdentifier然后用“页面对象模式”把每个页面的操作封装成一个类。这样就算UI布局变了只要标识符不变测试代码就不需要大改。单元测试比UI测试更值得花时间。像数据解析、日期处理、金额计算、加密逻辑这类和UI无关的代码我会尽量把它们抽成独立的工具类然后写纯函数的单元测试。这十年里我吃够了“在同一个方法里同时做了解析、过滤、UI刷新”的亏这样的代码根本没法测出问题也难定位。所以后来我养成了一个习惯哪怕后端返回来的是一个复杂JSON我也会先把它map成Model对象再传给UI层所有转换逻辑都跑一遍单测。4.2 设备模拟与多机型适配测试iOS设备模拟这个话题在热搜词里也很热。很多人会问能不能不买真机只靠模拟器就完成所有测试我的回答是能解决80%的问题但剩下的20%必须上真机尤其是这些场景——相机、推送、音频外放、键盘弹出、手势冲突、多任务切换、以及不同屏幕比例的适配。模拟器的优势在于可以快速切换不同机型比如iPhone SE第3代和iPhone Pro Max之间的屏幕尺寸差异靠模拟器一眼就能看出来。但它模拟不了AR/VR模拟不了重力感应模拟不了Taptic Engine甚至在iOS 17之后部分涉及SceneDelegate生命周期切换的场景模拟器行为和真机也有细微差别。我的习惯是每个产品迭代至少准备三台真机——一台小屏机型iPhone SE或mini、一台大屏Pro Max、一台有刘海的“异形屏”老机型iPhone 12或13。如果预算实在有限至少要有一台“边缘老机型”因为新手机跑得动不代表三年前的手机跑得动。而且iOS 18正式版发布后很多老机型的动画性能会下降如果你目标用户里有用旧设备的人就必须早做低端机测试。4.3 上架与签名分发的合规记录独立开发绕不开上架和分发。很多人对开发者账号和签名机制有误解这里聊一下我这个阶段最常做的合规操作。如果是自己公司的产品或外包项目最稳妥的方式是使用Apple Developer Program的正式证书配合TestFlight做内测分发。TestFlight的优点是审核比App Store快外部测试员上限也从原来的100人增加到10000人App Store Connect后台配置。这个流程我已经走过几十次基本稳定。有些场景需要把App装到客户自己手机上做demo演示但客户没有开发者账号这时候也不能图省事去走那些灰色签名渠道。合规路径是让客户注册一个Apple ID然后通过TestFlight发送外部测试链接满14天后正式构建生效。整个过程需要一点点耐心但安全性有保障不要让业务方用那些“一键直装”的方案短期方便长期风险大到不可控。另外iOS系统一直在收紧各种权限。iOS 13之后如果App在后台调用CLLocationManager获取位置系统会弹窗iOS 14后App Tracking TransparencyATT上线不经过用户授权无法获取IDFAiOS 17之后UIPasteboard的访问也会触发系统提示。这些隐私合规问题在上架审核时被拒的概率极高建议每个独立开发者在写代码前就把隐私清单整理好不要在提审时才发现漏了一堆。4.4 iOS分屏与iPad适配的那些额外工作量热搜词里出现的“iOS分屏”是每个开发者都该重视的适配项。iPadOS的“台前调度”功能在iOS 16之后变成了默认能力如果你的App不支持分屏用户体验会非常割裂——用户想一边查资料一边记笔记你的App直接变成全屏霸占。我踩过的坑主要是分屏时viewWillTransition(to:with:)会被频繁调用如果你在里面做耗时任务分屏一拖动就会卡顿。正确做法是把布局更新写在viewWillLayoutSubviews或traitCollectionDidChange里并且用UIView.performWithoutAnimation包裹住避免不必要的系统动画。另一个是自定义控件在分屏宽度变化时的布局崩溃。iPad分屏时App的窗口可能是屏幕宽度的1/3如果你的UI设计是按iPad全屏设计的很多按钮会被压缩得没法点。后来我引入了UICollectionViewCompositionalLayout来重构网格布局它能根据可用宽度自动调整列数这一点在iPad分屏场景下省了特别多事。5. 2024到2025iOS 18新特性、鸿蒙入局与面试标准的变化5.1 我对iOS 18 SwiftUI新变化的观察写到这里时间线已经到2024和2025年了。iOS 18这代系统比较大的变化不是某个单一新特性而是系统整体在向“AI能力系统级重构”方向走。从开发者视角看比较能感知的点有几个SwiftUI的地位进一步稳固越来越多的系统级界面改版开始用SwiftUI编写。这意味着作为iOS开发者如果你到2025年还在只用UIKit写页面确实有点跟不上节奏了。但我也理解很多老项目从UIKit迁到SwiftUI的成本不低。我的建议是新页面优先用SwiftUI老页面别急着重写通过UIHostingController把SwiftUI页面嵌进现有项目等页面本身的业务逻辑迭代时再顺便迁移这个节奏比较稳。另一个值得关注的是Observation框架它取代了SwiftUI早期的State、ObservedObject等一大票属性包装器的大部分职责。简单说状态管理和视图刷新的逻辑变得更“细粒度”了不再因为一个Published属性变化就整体刷新body。这个变化对长期维护的App是好事但对新人的学习曲线是变陡的——因为工作要求你把“什么状态该放State”“什么数据该走Observable”想得更清楚。此外iOS 18对隐私权限的提示更频繁了。如果你正在做相册权限、位置权限相关的功能记得考虑新的“选择照片”权限类型PHPickerViewController它能让用户只授权选中的照片而不是一次性授权整个相册。这不仅是对用户的尊重也是过审的加分项。5.2 鸿蒙设备对iOS开发者的影响2024到2025年鸿蒙在整个移动开发圈子里已经是一个绕不开的变量。很多企业开始要求“iOS、Android、鸿蒙”三端并行也出现了大量“有没有鸿蒙开发经验”的面试需求。作为iOS开发者我的观察是不用慌但也要花时间补课。HarmonyOS NEXT的鸿蒙原生应用理论上不再是安卓APK兼容方案而是用ArkTS和ArkUI构建独立的App。它的状态管理思路State、Prop、ObservedObject和SwiftUI非常像事件驱动模型也和iOS的Target-Action/Delegate模式有相似之处。我试过用半天时间过了一遍ArkTS的基础语法发现只要理解了SwiftUI中“状态驱动视图”的思想ArkUI学习的成本在可接受范围内。但这里要提醒自己和你的是跨端不是目的交付价值才是。不要因为“鸿蒙很热”就去接一个你完全没把握的项目。我认识几位朋友在2024年仓促接鸿蒙项目结果因为开发者账号申请、测试机适配、App备案等环节出问题交付延期口碑受损。技术栈可以迁移但工程化的经验和风险管理能力才是真正不可替代的。5.3 从面试官角度看这些年iOS面试题的变化做独立开发这几年我偶尔也帮朋友公司做技术面试官。看了不少iOS岗位的候选人最大的感受是面试标准从“你会不会用某个API”变成了“你懂不懂为什么是这个API”。2015年面iOS开发面试题可能会问copy和strong的区别UITableView的复用机制怎么写block的循环引用怎么解决这些问题到今天依然是基础但它们已经不足以区分候选人水平。现在我会更倾向于问你在项目里遇到过什么棘手问题是怎么定位和解决的如果让你设计一个图片缓存库你会考虑哪些维度iOS 18的新特性里你最关注什么为什么你用过Swift Concurrency吗它是怎么解决回调地狱的这些问题没有标准答案却能真实反映出候选人的项目深度和工程素养。所以如果你准备iOS面试我的建议是基础题一个都不能丢内存管理、线程、RunLoop、事件传递链、列表性能优化但更重要的是准备一个“深度项目故事”——一个从发现问题、排查、解决到验证的完整案例。面试官不关心你背了多少题而是关心你踩坑之后是否真的弄明白了。6. 十年高频问题实战清单能避一个是一个最后按惯例整理一份实战清单把热搜词里那些高频出现的iOS相关的场景问题按我自己的经验统一过一遍。不做长篇原理分析直接给答案和方向方便你按图索骥。6.1 移动端H5与小程序高频问题速查问题现象根因我推荐的解决方向iOS H5重复刷新微信公众号内微信浏览器对pagehide/pageshow事件处理与普通浏览器不同页面被错误地重新加载避免用pageshow做初始化改用DOMContentLoaded判断event.persisted属性区分缓存恢复iOS下载文件变成了预览Safari不支持a download在跨域场景的静默下载用Blob URL.createObjectURL或引导Safari打开后下载zip包绕开预览uniapp canvas导出白图绘制时序未完成就被导出pixelRatio配置不当导致离屏缓冲异常串行化绘制流程全部draw回调后在导出按pixelRatio缩放画布textarea键盘遮挡按钮键盘弹起时页面容器压缩不足或按钮定位不正确监听keyboardheightchange动态计算偏移或用自定义工具栏textarea失焦后透明层盖住按钮WKWebView原生组件层回收延迟失焦后延迟触发重绘通过移动1px、再复位等操作刷新渲染层微信小程序iOS静音模式下无声音iOS把静音开关当成全局媒体输出控制小程序里设置InnerAudioContext的obeyMuteSwitch falseApp内H5调起安装App失败缺少Universal Links或scheme拦截逻辑不严谨配置apple-app-site-association用Universal Links调起App并透传参数这张表里的问题很多单独翻资料都能搜到但放到一起看就会发现一个共性绝大多数都是系统和WebView层的“隐式行为差异”而不是真正的业务逻辑Bug。调试时先确认环境、再逐步隔离变量比一上来就改业务代码靠谱得多。6.2 用户侧常见问题的处理还有一些热搜词看起来像是“用户折腾手机”的问题但开发者也需要了解因为它们会影响口碑和客服咨询量。比如“iOS高版本备份恢复到低版本”这个痛点。很多用户在新手机上用高版本系统备份了数据换回旧手机后想把备份恢复却发现iTunes提示“备份版本过高”。这种情况通常是备份文件的版本号比目标系统高苹果为了防止数据损坏会直接拒绝恢复。开发者需要知道的是如果你的App在系统版本升级后改了本地数据结构也要考虑“用户降级”的场景——你的App数据库字段或UserDefaults结构要能容忍新版本写入、旧版本读取时的异常。否则用户跨版本安装后App会直接闪退这是非常差的体验。再比如“iOS延迟升级”这个话题。很多用户出于性能或习惯的原因会刻意停留在老版本系统上这就意味着我们开发者不能只盯着最新系统做适配。应用最低支持版本最好往前覆盖“占活跃用户比例约90%”的系统版本。具体到2025年如果某个App还只支持iOS 17以上那就会把相当一部分还停在iOS 15和iOS 16的用户拒之门外。iOS审核本身不强制一定支持老系统但从产品角度看过度收缩最低版本等于自动放弃用户。6.3 一些个人长期受用的开发习惯这些年的开发习惯让我在项目多、时间碎片化的独立开发阶段活了下来也分享给你参考每个版本迭代开始前先写一个几十字的“发布说明”明确这个版本解决什么问题。没有目标的迭代往往会拖成无尽的需求膨胀。代码提交信息写得足够具体。不是fix bug而是fix: 修复TextView失焦后遮挡提交按钮的问题在blur事件中触发一次延迟重绘。半年后回看commit记录你会感谢自己。每次修完一个线上Bug问自己一句这个问题会不会在App的其他模块也存在如果存在就花时间做一次系统性排查。在工程里维护一个docs/fuckingbugs.md记录你踩过的坑和解决思路。它既是你自己的调试字典也是带新人时最好的教材。不要在小版本里顺手重构模块。重构和功能开发要分开提交分开测试否则出了问题时你根本分不清是重构引入的还是新功能引入的。我在2024年接一个外包项目时客户说他们上一个团队“功能都能跑但没有人敢动老代码”。这就是工程债的典型症状。好的代码不一定是技术多炫酷而是改起来安心、接手的人能看得懂。这个标准无论你是做一个亿级用户App还是维护一个个人工具都适用。最后分享一件小事。去年我整理自己十年来的代码文件夹发现很多项目编译不过了不是因为语法变了而是依赖的三方库已经停止维护、或者版本不兼容。这提醒了我一个IT行业通用的道理技术的保质期越来越短但解决问题的思路和方法论是可以长期复用的。这十年我从OC写到Swift从纯原生写到跨端从公司项目做到个人产品很多东西都在变不变的反而是一些朴素的习惯——先想清楚为什么再动手写代码把复杂问题拆成能验证的小块为自己的每一行代码负责。希望这篇复盘能在你踩坑的时候帮你早点摸到方向。