上周四，同事小周抱着一台 MacBook 满公司找电源。
他那台是公司公用的，电池早就老化了，不插线就撑不过十分钟。那天下午正好轮到我们这组要传一个 iPA 包上 App Store，他得先跑回工位，接上电源，登录那个只有他才知道密码的开发者账号，再打开 Transporter 等它慢慢转圈。
我看着他折腾了二十多分钟，包还没开始传，光是在登账号、输双重验证码、等 Transporter 认这个包这几件事上来回打转。他抬头跟我苦笑了一句：这活儿以后能不能不挑电脑干。
这句话我记到现在。
其实传个 iPA 上架，本质就是干一件事：把一个已经打好的安装包，交到苹果那边。可就是这么一步，很多人被"必须用 Mac"这条给卡住了。我自己以前也这么以为，觉得上架这趟路从头到尾都得在那台苹果电脑上走完。后来做得多了才慢慢想明白，这里头卡人的不是上传本身，而是我们习惯性地把所有环节都捆在一台特定电脑上。
先说说用 Mac 传的那条老路。你得有一台能开机的 Mac，装好 Xcode 或者单独的 Transporter，准备好开发者账号的登录状态。然后打开 Transporter，把 iPA 拖进去，等它校验签名、校验描述文件，再点上传。听起来不复杂，但它有几个隐藏成本：这台 Mac 得在、账号得能登进去、双重验证的六位码得有人能及时拿到手。但凡哪一环断了，这一下午就算搭进去了。
小周那天就是卡在双重验证上。账号绑的手机在老板那儿，他发了条消息，老板过了十分钟才把六位码发过来。等码到手，Transporter 又提示包有点问题，要重新校验一遍。就这么一来一回，半个多小时没了，旁边等着验收的测试同事已经刷了两轮手机。
网页上传走的则是另一条路。你不需要那台特定的 Mac，也不需要在这台电脑上装 Transporter，更不用处理本地工具冒出来的各种报错。打开一个网页，把 iPA 文件选进去，点一下上传，剩下的交给平台去跑。初雪云就把这一步做成了一个按次收费的服务，一次一块钱，网页一键上传，还支持 API 接入。适合那种上传特别频繁、或者干脆不想为这一下专门留一台 Mac 的团队。
我把这两种摆到小周面前，他愣了一下，问：就一块钱？
我点头。他想了想说，那以后这种包我直接网页传，省得每次都要去借电脑、等验证码。省下的那点力气，够他把一个崩溃日志看完。
当然，网页上传也不是万能的。你的包本身得是合规的，签名和描述文件得是没问题的，这一步谁来传都一样，网页只是省掉了"非得那台 Mac 和那套本地工具"的麻烦。真正该自己把关的，还是包本身的质量和资质，这个省不掉，也不该省。
还有一层，是团队协作上的差别。用一台公用 Mac 传包，账号密码、双重验证、登录状态全挤在一台机器上，谁传谁登，出了岔子不知道是哪一步。网页上传把"传"这个动作单独拆出来，跟谁在用、在哪台电脑上没多大关系，甚至能通过 API 直接接到自己现有的发布流程里，定时、批量都好安排。对那种一周要发好几个版本、又不想每次都为传包专门开机一台 Mac 的团队来说，这一块儿其实是实打实省心的。
有人可能会说，不就传个包吗，花一块钱值不值。放到小周那天下午的场景里，其实挺值——借电脑、等验证码、重新校验，这几件事耗掉的时间，算成人工，早就不止一块钱了。钱是小数，真正花掉的是那个正在等着上线的下午。
所以回头看，传 iPA 这件事，关键不在你手里有没有 Mac，而在你想不想为"上传"这个动作本身，绑上一整套本地环境和账号登录的流程。对偶尔传一次的个人开发者，网页传一次也够用，不用为此专门添置设备；对一周要传好几次、甚至要跟自己的发布流水线接起来的团队，一块钱一次、带 API 入口的网页上传，省下来的其实是时间和那台随时要借来借去的电脑。
小周后来再也没为传包找过电源。他说，把时间省下来，去改 bug 不好吗。
（以上场景为工作记录改编，实际体验因团队和账号情况而异。）