原文摘要

Swift、Kotlin、Dart、C++、Combine、液态玻璃（Liquid Glass）、AI……等等，我到底在构建什么来着？

→ 1: 那很有趣。真的很有趣。

让我带你回到 2017 年。 我下载了 Xcode。打开了 Swift。制作了我的第一个“Hello, World”应用。它成功了。我尖叫了。生活很美好。 我当时想，“哇！我刚刚做了一个应用。我真是个天才。”

快进到 2025 年： 我正在哭泣，因为 SwiftUI 中的一个 .sheet 无法正确关闭，而 Combine 吞噬了我的灵魂。

到底发生了什么？

→ 2: Swift 不够了。苹果说“再试试！”

于是我学习了 Swift。 然后苹果轻声说：

“嘿，试试 SwiftUI。它是声明式的。它会改变你的生活。”

它确实改变了。主要是通过破坏预览和我的精神。 接着 Combine 来了。

“要正确使用 SwiftUI，你需要响应式编程。”

于是我学习了 Combine。 现在我正在 mapping、flatMapping，并更深地陷入困惑。

还有——UIKit？是的，仍然需要。 Objective-C？就像家庭聚会上那个奇怪的叔叔一样，还在那里。就是不肯走。

→ 3: Dart、Kotlin、C++ 和困惑登场

然后有一天，团队说：

“我们来做跨平台开发吧。Flutter 是未来！”

酷。现在我正在学习 Dart。 还有 Kotlin。 还有 C++，为了那个蓝牙 SDK，因为……为什么不呢

在这一切的中间，我忘了如何让一个按钮居中。 我到底又在构建什么来着？哦对了——一个待办事项列表应用。

→ 4: 倦怠身穿连帽衫和洞洞鞋悄然而至

所有的危险信号都在那里：

• 我开始梦见 Combine 链。
• 看到 Xcode 更新时，我感到愤怒。
• 我开始在日常对话中说“幂等（idempotent）”。

然后我崩溃了。

一天晚上，SwiftUI 预览又坏了。我打开 StackOverflow。 置顶评论是：“在我的电脑上没问题啊。”

我合上了笔记本电脑。

盯着墙壁。

点了份梅菜扣肉饭。

质疑了我的职业生涯。

→ 5: 然后 AI 来了——那个我没要求的实习生

AI 带着一个承诺来了：

“让我们为你写代码吧！”

听起来很棒，对吧？

错了。

AI 写代码就像一个过于自信的实习生：

• 一开始看起来不错
• 破坏一切
• 当事情出错时责怪你

现在我不仅仅是在写代码了。 我是在看护 🧑‍🍼一个根本不懂 iOS 如何运作，却仍然坚持像吃糖果一样使用 .forceUnwrap() 的大型语言模型。

→ 6: 我选择了暂时离开（而且没有爆炸）

于是我做了件不可思议的事： 我对下一个sprint说了不。

我删除了 Xcode。

关掉了 Slack。

去接触了草地。是的，真正的草地。

我开始用 Python 构建一个简单的 CLI 应用。只是为了好玩。

我玩 Swift Playgrounds，不用担心 Bug 或截止日期。

然后慢慢地……

我记起了我最初为什么开始编程。

不是为了工单。不是为了 JIRA。 而是为了当某个东西成功运行时的那种小小的兴奋感。

→ 7: 移动开发并未消亡——但我需要休息

并不是说移动开发不好。 只是它太多了，太快了，而且种类太多了。

• 跨平台开发并不简单。
• Swift 变得更沉重了。
• Flutter 变得更喧嚣了。
• AI 变得更专横了。

我只是需要退后一步。深呼吸。然后提醒自己：

“你不必了解一切，也能创造出美好的东西。”

最后的话：亲爱的开发者，有时选择“退出”是可以的

如果你感到疲惫、困惑，或者想把你的 MacBook 扔出窗外——嘿，我懂。

你并不孤单。

你也没有落后。

你只是厌倦了为了让一个视图居中而学习五种语言。

休息一下吧。

去构建一些小东西。

嘲笑这混乱的一切。

如果所有方法都失败了——那就怪 Combine 吧。

原文链接

进一步信息揣测

• SwiftUI的预览功能稳定性问题：实际开发中SwiftUI预览经常崩溃或无法正常工作，官方文档很少提及这一痛点，但开发者社区普遍抱怨。
• Combine的学习曲线陷阱：苹果推荐Combine作为SwiftUI的响应式编程解决方案，但实际使用中map、flatMap等操作符极易引发复杂性问题，且调试困难，属于“官方推荐但实际坑多”的技术。
• 跨平台开发的隐性成本：团队推崇Flutter时往往忽略需同时掌握Dart、Kotlin、C++等语言，实际开发中跨平台工具链的集成问题（如蓝牙SDK）会大幅增加复杂度。
• AI生成代码的可靠性问题：AI生成的代码（如使用.forceUnwrap()）可能违反平台最佳实践，需人工大量修正，实际效率可能低于预期，且缺乏公开讨论的维护成本。
• 技术栈膨胀的倦怠风险：移动开发领域（Swift/Flutter/AI）技术迭代过快，开发者被迫多线程学习，但行业内部较少公开讨论由此导致的心理健康问题。
• Xcode更新的兼容性隐患：经验开发者私下抱怨Xcode更新常破坏现有项目，但官方很少提前预警，需依赖社区非正式渠道获取回滚方案。
• UIKit/Objective-C的遗留负担：尽管苹果主推Swift/SwiftUI，实际商业项目仍依赖UIKit和Objective-C，这种“新旧技术并存”的过渡期比官方宣传的更漫长。
• 行业内的“假装正常”现象：StackOverflow上“我的电脑没问题”类回复掩盖了环境差异导致的普遍问题，反映开发者社区中存在隐藏真实困难的倾向。
• 简单项目重启疗法：资深开发者通过回归CLI或Swift Playgrounds等低压环境重建信心，属于非公开传播的对抗职业倦怠的有效手段。
• 技术决策的营销误导：苹果/谷歌等公司常过度包装新技术（如“声明式编程改变生活”），实际落地时需结合旧技术栈，但这一混合开发的复杂性很少在官方材料中体现。