我叫陆星河，是一名第 7 年的 ios 开发者。工作签在上海一家公司，名片上写着“高级工程师”，听起来还不错。
这篇文章不是给刚入行、满眼星光的人看的，而是写给：
- 正在做 iOS、却觉得方向越来越窄的人
- 想转 iOS、又担心“红利没了”的人
- 工作几年，想涨薪却不知道该补哪里的人
我会用自己的踩坑和观察，把我这两年做对的、做错的，都掰开讲清楚。没有煽情故事，都是干巴巴的现实和可落地的路径。
刚入行那会，我和很多 ios 开发者 一样，脑子里只有一句话：“移动互联网还在涨潮，学好 iOS，不愁没饭吃。”
后来形势在悄悄变化。你也许能感受到：
- 招聘 JD 里，“同时掌握 Android 或 Flutter 优先” 变多了
- 纯客户端岗位减少，很多公司开始要“全栈一点的人”
- 面试不再只问 OC/Swift 和 UI，开始问网络、性能、架构、工程化
我真正被敲醒，是看到一组数据：在一些主流招聘平台上，用“iOS 开发”搜索，展示的岗位数量比 3 年前减少了约 30%-50%（不同城市略有差异），但竞争人数却没明显降。岗位少了，人还差不多多，这意味着什么不用多说。
更扎心的一点，是岗位的“要求变化”：
- 以前：熟悉 UIKit、会用 AFNetworking、会简单的多线程就行
- 现在：
- 要会 SwiftUI 或至少能快速上手
- 要能看懂服务端接口问题、排查网络异常
- 要能和产品讨论埋点、转化率、A/B 测试
- 要能解决性能问题，还得对架构有点想法
也就是说，“只会写页面”的 ios 开发者，越来越难。
我曾经也是典型的 UI 搬砖工：
- 公司改版一个界面，我能肝两天两夜
- 但一旦后端接口慢、用户频繁闪退，我就懵
- 更别提什么架构演进、工程化、质量体系
等我想通的时候，已经错过了两轮升职机会。不是公司不厚道，而是我真的没有证明“我配得上更贵”。
这一段写得有点冷，但这是我想说的第一个现实：ios 开发者的路没断，只是“门槛”从语言层面，悄悄抬到了“解决问题的能力”上。
不少人给我发私信，问“要不要转行”“学什么能涨薪”。我每次都反问一句：“你现在是在哪个坑里？”
大多数 ios 开发者，其实都困在下面这几个坑里：
1）一头扎进语法细节，却不敢碰真实业务我有一段时间热衷刷 Swift 新特性，用 Playground 写一堆小 Demo：Result、Combine、async/await、Property Wrapper……看起来很“上进”，可是对简历几乎没加分。
原因很简单：
- 业务代码里根本没用到
- 就算用上了，也只是“写法更优雅”，但对业务关键指标没明显提升
- 面试官问：“你有没有负责过一个完整需求，从方案到上线？”我答不上来
那段时间，我对语法极度熟悉，但一谈到：
- 崩溃率为什么居高不下
- 启动时间为什么拖得用户直骂
- 埋点怎么设计才能反映真实用户行为我完全没底气。
后来我意识到：语法是地基，但你不能一辈子住在地基里。
我做了两个调整：
- 自己主动接“难缠的需求”，比如支付流程改版、IM 模块重构
- 遇到业务方抱怨体验差，我不是甩给测试或后端，而是自己先查崩溃日志、抓包、分析性能数据
从那之后，我在绩效里第一次被写上：“能独立负责中型需求，从技术方案到落地。”这句话，比我会多少关键字更值钱。
2）盲目追“热门技术栈”，结果哪一块都浅尝辄止有段时间，圈子里特别流行“ios 开发者转 Flutter/React Native/跨平台”。我也跟风学 Flutter：
- 跟着视频写了三个小 Demo
- 界面酷炫、动画丝滑，自我感觉很牛
- 简历上加了一行“熟练掌握 Flutter 开发”
等面试官问：“你做过 Flutter 混编吗？怎么和原生通信？怎么做性能监控？”我直接原地去世。
那一刻，我才明白：“会用”一个框架，和“能在复杂项目中驾驭它”，差了一整条街。
后来我调整策略：
- 不再追一堆热点，而是挑一个方向打深，比如“移动端稳定性”
- 把 Crash 收集、性能监控、日志系统、灰度发布这些相关的东西啃透
- 在团队里主动推动接入崩溃监控平台，整理崩溃 Top N 的问题，定期复盘
当我能拿出一份报告，清楚地告诉领导：
- 崩溃率从 1.8% 降到 0.6%
- 活跃用户在极端网络下的错误率下降了多少那一刻，我才真正感受到“技术变现”。
3）只盯技术细节，完全不关心产品指标很多 ios 开发者有个共性：提起架构和设计模式可以聊半小时，提起 DAU、留存、转化，立刻沉默。
我以前也一样，觉得：“技术做干净就好，业务 KPI 关我什么事。”
直到某次绩效评审，我被问到：“你做的这个新功能，上线后核心指标有没有变化？”我当场愣住。那一刻很尴尬，也很清醒。
后来我给自己定了个小习惯：
- 每做完一个需求，去看数据看板：这个功能的使用率、转化率怎么样
- 和产品聊一聊：为什么要做这个功能，它想改变什么数字
- 下次方案设计时，主动提出：这个点可以加个埋点，看看用户是怎么用的
当你能说出“这个优化让订单转化率提升了 2%”，领导看你的眼神会明显不一样。
技术不是消失了，而是被包裹进了“对业务负责”这四个字里。
说这么多现实，是想把话说开：想在这条路上走得长一点，不能只指望“多敲两行代码”。
我这两年给自己做了一个“四层升级”，你可以对照看看自己在哪一层：
L1：写得出页面，修得了Bug
这层的特征很明显：
- 能按 PRD 搭界面、调接口
- 知道怎么用 Auto Layout、知道如何发网络请求
- Bug 能靠断点、日志定位一部分
这层可以找到工作，但一旦裁员，保护力接近于零。因为替代你的工程师太多了。
如果你现在在这层，最现实的建议：选一个“业务完整模块”，从头到尾吃透。比如：订单系统、支付流程、登录注册。你要做到：
- 熟悉所有接口的入参出参
- 知道这个模块常见的故障模式
- 出问题时，你是团队里最快能定位到原因的人之一
L2：能做模块负责人，撑得起一块业务我大概在第 4 年才踏实进入这一层。标志是：
- 产品提一个需求，你能主动拆解成若干子需求
- 能评估复杂度，预估工期，告诉项目经理哪些点有风险
- 上线后出了问题，别人第一时间会来找你
这层带来的直接收益是：
- 绩效不会太难看
- 在裁员风波里，你不会是最先被考虑的一批
- 工作成就感明显提高
要到这一层，有两个关键动作：
- 学会写“技术方案文档”，而不是只在脑子里想
- 学会把自己对风险的判断说出来，提前卡住坑
写方案这件事，多数 ios 开发者都在逃避。可是越是逃避，越容易被当成“执行工具人”。
L3：在团队里有“技术标签”，别人愿意听你意见某一天我突然发现：无论开不开心，大家都已经默认我来负责“稳定性相关”的事。
有人问我：
- “我们要不要换一个 Crash 收集 SDK？”
- “这次版本崩溃率有点异常，你帮看下？”
这就是技术标签的意义。你可能是：
- 性能优化专家
- 音视频相关的“那个人”
- 工程化工具的搭建者
- 或者某一块业务领域的守门员
当你有了标签，你就从“一个 ios 开发者”变成“这件事离不开的人”。
这层的关键是：少一点什么都学一点的焦虑，多一点“把某一块做深”的耐心。
L4：不止写代码，而是能影响方向的人这层不是所有人都要追，但值得知道它长什么样子。我身边少数做到这一层的 ios 开发者，具备几个共同特征：
- 能看懂业务的整体盘：公司的赚钱方式、产品的大方向
- 能在技术方案讨论里，兼顾“用户体验”和“成本收益”
- 有能力对某些业务需求说“不”，并拿出更好的替代方案
他们的薪资不一定是全公司最高，但稳定性和话语权都很强。
如果你有意往这层去，可以做两件事：
- 主动参与跨端、跨团队的项目，而不是只关心自己那点 UI
- 花时间理解公司所在行业的运作逻辑，多问一句“为什么做这个”
写到这里，可能你已经有点信息过载。我们换成具体一点的“动作清单”，你可以按节奏来做。
行动1：给自己做一次“技术体检”
找一个周末，把你现在掌握的东西写下来：
- 语言层面：Swift/OC 的水平、熟悉的框架
- 工程能力：单元测试、CI/CD、自动化打包
- 业务领域：你最熟悉的模块是哪一块
- 通用能力：沟通、文档、跨端协作
对比几份目标岗位的 JD，看看差距在哪里。这一步很枯燥，却非常关键。因为如果连“自己短板在哪”都不知道，后面所有学习计划都是盲打。
行动2：挑一个方向深挖 3 个月
不要一股脑报 N 门课程，先选一个方向，给自己 3 个月执行期。比如：
- 性能和稳定性
- 工程化和效率工具
- 某个业务域（支付、音视频、IM 等）
然后：
- 找 1-2 个公认还不错的系统教程或书
- 在现有项目中，刻意寻找能实践的切入点
- 每做完一个改动，记录前后指标变化
比如你选“启动优化”，就去量化：
- 优化前后首屏时间
- 用户从点击图标到可操作的时间差
只要你能在简历上写出：“主导 XX App 启动优化，平均启动时间从 2.3s 降至 1.4s”，你的竞争力就不一样了。
行动3：把“写文档”和“画图”当成日常能力
在很多公司里，像晋升材料、项目复盘、技术分享，这些东西的权重，比大多数人想象的要高。
你可以从两个小动作开始：
- 每做一个稍大的需求，写一份简单的技术方案，哪怕只有一页
- 习惯用时序图、架构草图来说明问题，而不是光口头描述
这不仅是为了“好看”，更是为了让别人知道：
- 你有能力做设计
- 你考虑过风险和替代方案
长远看，这一项能力，会直接决定你能不能往高级、架构这条路走。
行动4：别回避与产品、运营的对话
有些 ios 开发者，把产品当“需求机器”，把运营当“要数据的人”。其实你只是损失了很多可以成长的机会。
试试这些小动作：
- 每次评审会，多问一句“这个功能核心指标是什么？”
- 功能上线后一两周，自己去问产品“数据怎么样，要不要调一下？”
- 有时候主动向运营要一次完整的活动方案，看技术在哪些地方可以帮到他们
你会发现，很多时候，产品也不懂技术细节，他们也需要一个能讲人话的开发来一起做决策。这就是你成为“不可替代”的机会。
行动5：有意识地积累“可讲的案例”
很多人面试，说不出几件能打动人的事情。不是他们没做事，而是没有刻意去总结。
给你一个简单模板，每遇到一件像样的事情，就按这个记录：
- 背景：当时遇到什么问题、指标有多糟糕
- 动作：你做了哪些方案尝试，最终采用了哪种
- 结果：指标变化、用户反馈、团队收益
- 反思：如果再来一次，你会怎么做得更好
半年后，你手里会有一套属于自己的“项目故事集”。无论是内部晋升、对外面试，这些都比流水账式的“参与过 XX 项目开发”有价值。
行动6：适度拥抱跨端，而不是被跨端吓退
很多 ios 开发者听到“跨平台框架”三个字，就条件反射地焦虑，担心自己会被替代。
我的看法有点不一样：
- 有些公司确实会希望用 Flutter、RN 来减少多端人力
- 但只要有 App，就一定离不开原生能力和系统级问题解决
相比一味抵触，不如主动把跨端当成一个“加分项”：
- 了解现有项目的跨端技术选型，主动参与一部分
- 把你对原生性能、系统行为的理解，注入到跨端项目中
- 让自己成为“懂跨端又懂原生的人”
这样的角色，在团队里通常很难替代。
互联网的风口变得很快。ios 开发者这个标签，确实不再像十年前那样自带光环。
可每次我看到公司里离不开 App 的那些场景：
- 用户在手机上完成一笔复杂交易
- 在地铁里刷着短视频、听着播客
- 线下扫码、线上支付、实时查看物流我就很清楚：移动端不会消失，它只是在要求我们变得更成熟一点。
如果你也是一名 ios 开发者，也在纠结要不要转行、要不要“抛弃原生”，我想说：
- 与其盯着外面的风声，不如先把自己手里的牌打好
- 与其害怕被替代，不如让自己变成那个“难以被替代的人”
我这几年最大的感受是：当你不再只把自己定义为“写 iOS 页面的人”，而是把自己当成“用技术解决移动端问题的人”，很多原本看起来很窄的路，会慢慢变宽。
你不一定要成为多耀眼的“技术大牛”，但你可以让自己的每一步，都多一点掌控感。
如果这篇文章能让你少踩几个坑，或者哪怕只是今晚坐地铁回家时，多想一想自己的下一步，那我这个被现实撞醒的 ios 开发者，也算没有白写这段长长的自白。
