IndieForge

写在前面：这篇文章记录了我从零开始开发一款 iOS App 的全过程。没有融资，没有团队，没有外部资源。只有一个刚毕业的硕士生、一台 Mac、和一个想做点什么的念头。 一、为什么做这件事 今年硕士毕业。 毕业季过后，有一段属于自己的时间。论文写完了，答辩结束了，学位拿到了。然后呢？艰难的大环境，让我难堪，于是我想做点什么，做点我想做的事情。 我做过‘冰箱’物品管理软件《别忘了你的冰箱》，但是这个软件完全是免费的，对于那688的Apple developer会员，我想做一些商业化的产品。 二、做什么产品 做产品之前，先想清楚一个问题：谁需要什么？ 我的回答是：我需要什么。 我自己平时会维护一些小项目——有的在 App Store 上架了，有的是 side project，有的写着写着就放下了。管理这些项目的过程让我特别痛苦： Notion 管任务，但它面向团队，一个人用总觉得大材小用； Google Sheets 记收入和支出，但和任务完全割裂； 备忘录 写开发日志，但没有结构，翻回去看一片混乱； 纸笔 画看板，但没法跨设备同步。 我试过 Trello、Linear、Things、OmniFocus，每一个都很好，但没有一个是从”一个人做产品”这个场景出发设计的。 市面上缺少一款工具：它能按版本管理任务，能追踪每个项目赚了多少花了多少，能把散落各处的文件归档到一起，能让我记录自己的开发故事，还能让我把这些故事分享出去。 既然没有，那我就自己做一个。而且恰逢这两年OPC经济又被炒出来了，独立开发者也渐渐增多，于是 IndieForge 被推了出来。 所谓IndieForge 就是，Independent Forge，字面意思独立锻造，翻译过来就是独立产品的意思。还具有两个层次的更深层含义： 第一层：Forge = 铁匠铺：铁匠铺是一个人工作的地方。 铁砧（Anvil） ：承载一切的基础 —— 就像项目管理框架，任务有了放的地方 锤子（Hammer） ：反复敲打的工具 —— 就像每天的编码和迭代 火焰（Fire） ：让金属变软、可塑的热量 —— 就像热情和动力 火花（Spark） ：锤子落下时飞溅的光 —— 就像灵感、突破、每一次发布 铁匠不是一次性造出完美作品的。他反复加热、反复敲打、反复淬火。独立开发也是一样：一个版本一个版本地打磨。 第二层：Forge = 创造 Forge 还有一个意思：to forge ahead（奋力前进）。 对独立开发者来说，每一天都是在没有路的地方开路。 没有人给你分配任务，没有人检查你的进度，没有人告诉你方向对不对。你自己决定做什么，自己动手做，自己承担结果。 这就是 forging —— 在未知中开辟道路。 三、这段时间做了什么 接下来是这段时间的完整开发记录。我会按功能模块逐一介绍，每个模块说清楚它解决什么问题、怎么设计的、用了什么技术。 3.1 版本驱动的项目管理 IndieForge 的核心设计决策：按版本（Version）组织任务，而不是按 Sprint。 为什么？因为独立开发者的节奏不是两周一个 Sprint，而是”这周把 v0.3 的功能做完，下周末发 TestFlight”。版本是独立开发者心里真正的节奏单位。 在 IndieForge 里，一个项目有多个版本，每个版本有多个任务。任务可以在四列看板（To Do → Doing → Review → Done）之间拖拽移动。 3.2 收入与投资追踪 独立开发者最常被问到的问题之一：你那个产品赚钱了吗？ 大多数人的回答是：好像赚了？不太确定。 因为收入数据分散在 App Store Connect、支付宝、Stripe 等多个平台，成本数据分散在各种订阅账单里。没有一个统一的视图能看到：这个月净利润到底是多少。 IndieForge 的财务模块就是为了解决这个问题： 收入条目 按项目、按月份记录，支持手动录入和 CSV 导入 投资条目 记录每一笔支出（服务器、工具订阅、域名、广告、设计外包等），自动归类 损益面板 收入 – 投资 = 净利润，按项目维度和整体组合两个视角展示 六个月趋势图 使用 Swift Charts 绘制堆叠柱状图，一眼看出收入走势 数据全部存在用户的 iCloud 里，我不碰任何人的财务信息。 3.3 项目文件归档 做产品过程中会产生大量文件：PRD 文档、API 合同、设计稿、App Store 截图、财务表格…… 这些文件通常散落在各种地方——有的在 Downloads 文件夹，有的在微信聊天记录里，有的在 iCloud Drive 的某个深层目录。 IndieForge 的文件管理模块让这些文件归到项目里： 支持 Word、Excel、PDF、图片、Figma、Sketch、JSON 等常见格式 文件自动按类型分组（文档 / 表格 / 设计 / 图片 / 数据） 可以关联到特定版本，也可以被任务引用作为参考资料 通过 CloudKit CKAsset 同步到所有设备 缩略图优先同步，大文件按需下载，本地缓存自动管理 3.4 Apple 生态深度集成 作为一个 SwiftUI 项目，IndieForge 覆盖了 Apple 几乎所有的系统扩展点： 桌面小组件（WidgetKit） 小尺寸：连续天数 / 今日聚焦 / 收入摘要 中尺寸：今日任务详情 / 收入仪表盘 大尺寸：完整数据概览 Apple Watch 伴侣应用 表盘 Complication：四宫格数据摘要 Today’s Focus：查看今日任务，点击标记完成 Revenue Glance：收入概览 + 趋势迷你图 Streak Ring：环形进度 + 统计数据 Mac 桌面端 三栏布局：侧边栏导航 + 主内容区 + 详情面板 支持项目表格视图、看板视图、Overview 仪表盘 所有数据通过 CloudKit 同步。iPhone 上记一笔收入，Mac 上立刻能看到。 3.5. AI助手 Forgey AI 四、技术决策与取舍 做独立产品，技术决策要服务于一个原则：一个人能维护。 所以我做了以下取舍： ✅ 选择 Swift 全家桶：SwiftUI + SwiftData + CloudKit。优点是和 Apple 生态深度绑定，API 一致性好。缺点是只能跑在 Apple 平台上。但对于一个 iOS 优先的产品，这不是问题。 ✅ 选择 CloudKit 而非自建后端：好处：零服务器成本（10,000 用户以内基本免费）、数据加密、Apple 维护基础设施。坏处：调试痛苦（CloudKit 的错误信息堪称谜语）、平台锁定。权衡之后，对一个 MVP 来说是正确选择。 ✅ 选择 RevenueCat 管理订阅：StoreKit 2 本身可以处理订阅，但 RevenueCat 提供了更友好的 dashboard、A/B 测试、和跨平台能力。8 美元/月的成本完全可以接受。 ❌ 不做 Android现阶段没有精力同时维护两个平台。如果 iOS 端验证了 PMF（Product-Market Fit），再考虑用 Kotlin Multiplatform 扩展。我本来是做Android的，不做Android的还有一层次原因是Android的国内上架程序繁琐，商业化流程复杂。 ❌ 不做 Web 端同样的原因。先把一个平台做到极致。 ❌ 不自建后端省掉服务器运维、数据库管理、API 开发、安全审计等大量工作。一个人的时候，能不做的事就不做。 五、这段经历教会了我什么 1. 完成比完美重要。 我一开始想做很多功能。后来发现，如果每个功能都想做到完美，永远发布不了。最后给自己定了规则：先交卷，再改。所以 v0.3 就提交审核了。不是完美的产品，但它是完整的、可以被人用的产品。 2. 自驱力是一种需要练的能力。 没人催你，没人检查你的进度，全靠自己。前几天很兴奋，中间有几天想摆烂，后来看到功能一个个做出来又停不下来。这段时间下来，我觉得自己的自驱力上了一个台阶。 3. 做产品的过程中，你会变成一个更好的人。 这句话听起来很鸡汤，但我是认真的。做产品让你学会取舍（功能优先级）、学会共情（用户到底需要什么）、学会面对不完美（总有 bug）、学会坚持。这些能力不管未来做什么都有用。 六、接下来的计划 短期： 等待 App Store 审核结果 通过后发布第一个商业化验证版本 收集第一批用户反馈 长期： App Store Connect API 集成 如果验证了 PMF，考虑 Android（KMP），以及自建服务器。 接入AI问答功能，作为您的独立开发顾问。 七、写在最后 这篇文章不是成功故事。App 刚提交审核，还没有一个用户，不知道市场会不会接受它。 但这是一段真实的记录。 记录一个人怎么从一个想法开始，一段时间后把它变成一个可以下载的产品。 如果你也在做自己的 side project，或者正在考虑开始，希望这篇文章能给你一点参考。 不需要很大的团队，不需要很多的钱，不需要完美的时机。 你需要的只是：一个你真正想解决的问题，和打开编辑器的勇气。