Splync v1.12 引入了小费箱

虽然Splync v1.12专注于通过新通知和徽章增强用户间的沟通，但下一步是加强用户与开发者之间的交流。在即将推出的版本中，我们计划引入专门的反馈按钮，让用户轻松分享他们的需求、建议或担忧。Splync旨在以用户为中心、社区驱动的方式成长，而开放的沟通对这个目标至关重要。作为朝这个方向迈出的第一步，Splync v1.12实验性地引入了一个小费箱来支持开发者。这是Splync首次提供自愿支付选项。应用程序仍可完全免费使用，小费完全是可选的。小费箱不会解锁功能、移除限制或提供任何应用内奖励。在Splync中给予小费就像字面意思一样——一种简单的感谢之举。如果您喜欢使用这个应用程序并希望支持其持续开发，我们对您的小费表示感谢。这是一次性的、可选的贡献，纯粹是表达谢意的一种方式。

需要澄清的是，Splync由一个人开发。我以独立企业家的身份设计、开发、维护和推广这个应用程序。这个博客也是由一个人撰写，并通过我的Python + OpenAI API脚本自动翻译成42种语言以节省时间。目前，我喜欢作为一个独立的全栈工程师进行端到端的构建。我尚不确定单独能走多远。总有一天，我可能会组建一个团队，让Splync更加出色。俗话说：“欲速则不达，欲达则不速。”Splync可能会最终走上这条路。虽然Splync以集体声音呈现为产品，但其开发目前由一个人驱动。为了保持一致性和专业性，这个博客和应用程序经常使用“我们”而不是“我”。根据上下文，我可能会在两者之间切换。无论用词如何，您通过小费箱提供的任何支持都是非常鼓舞人心的，并直接帮助持续开发。

在iOS应用中实现小费箱听起来简单，但它需要技术上和哲学上的仔细考虑。在Splync v1.12中，小费箱是通过苹果的应用内购买（IAP）系统实现的，使用的是不可消耗的一次性产品。从技术角度看，该过程从在App Store Connect中定义小费产品开始。每个小费选项都作为一个独立产品注册，具有固定价格，明确标示为自愿贡献。这些产品背后没有功能限制，购买后也没有解锁应用内内容。这一区别很重要，因为苹果严格审查应用内购买是否提供数字商品或功能。在应用程序端，Splync使用StoreKit获取可用的小费产品并在专用小费箱界面上展示。用户选择小费后，购买流程完全通过苹果的安全支付系统处理。交易成功后，应用程序仅显示感谢信息——不存储标志、不改变用户状态，也不授予任何权限。

实现小费箱不仅仅是编写StoreKit代码。它还需要与用户的清晰沟通、适当的法律和财务准备，以及与苹果应用审核指南的仔细对齐。即使对于一个简单的小费功能，开发者也需要确保相关协议已经到位，并在App Store Connect中配置有效的银行账户以接收付款。在完成所有这些步骤后，我提交了应用程序进行审核。差不多一天后，状态从“等待审核”变为“审核中”。我很兴奋——这感觉像Splync终于要开始盈利了。然而，仅仅几分钟后，状态变为“被拒绝”。我为Splync提交的第一个小费箱被拒绝了。拒绝信息提到“指南3.2.2 – 商业 – 其他商业模式问题 – 不可接受。”苹果表示：“我们注意到您的应用包含在应用内收集慈善捐款的能力，这在App Store上是不合适的，因为您的应用使用应用内购买来收集捐款。”

简而言之，我的小费箱被解读为慈善捐赠功能。根据苹果的政策，通过应用内购买收集捐赠是不允许的，除非满足特定要求和审批流程。这并非我的本意。Splync的小费箱纯粹是为开发者提供自愿小费，而不是捐赠给某个事业或组织。问题出在措辞上。诸如“支持”之类的短语和对“Splync社区”的引用无意中让这个功能听起来像是一个捐赠系统，而不是个人小费。在重新措辞以使其更加明确直接后，我重新提交了应用程序。更新被接受，没有进一步的问题。在我生活的日本，小费并不是日常文化的一部分。这一经历让我尤其清楚：小费和捐赠本质上是不同的。小费是对服务提供者的个人感谢，而捐赠是对某个事业的支持。这种区别很重要——不仅在文化上，而且在法律上和平台政策中。

如果您喜欢使用Splync，可以随时向开发者小费。小费完全是自愿的，不会解锁任何功能或优待。它仅仅是表达感谢的一种方式，任何金额都受到真诚的感谢。未来，Splync可能会推出付费计划。在此之前，小费箱仍然是应用中唯一形式的自愿财务支持。