P.S. 今天刚正式发布就学到不少东西，定价就是其中一环，非常感谢大家的反馈🙏
Hi,
大家好，我是Justin。今天我发布了一款使用SwiftUI开发的，运行在iPhone, iPad, Apple Watch, Mac和Vision Pro的App: Just Toolbox。
这是一款面向开发者的工具箱应用，得益于苹果在SwiftUI的大力投入，这个项目的大部分代码只需少量修改就能很好工作在所有苹果平台上。
开发这个App最初只是出于练习目的，去年在上海苹果开发者加速器分享的时候，我使用的Demo也是基于SwiftUI开发的。
此后我还做了好几个基于SwiftUI的项目，但最终都没上架发布。分析下来我觉得有几个原因:
1. 基于SwiftUI开发，但仍采用UIKit的设计思路
SwiftUI目前的接口是高度抽象的，但我因为习惯了使用UIKit和AppKit的思路设计App，希望对App的每个细节都能掌握并修改。于是在实践过程中我不得不基于Representable协议在两者之间桥接，以达到我想要的细节效果。
于是付出的代价不少，首先是我需要针对UIKit, AppKit各自实现一次，实现的东西多了，SwiftUI的跨苹果平台的特性也就不复存在了。于是会产生“如果我到处都需要用Representable hack一下，那我为什么不直接使用UIKit/AppKit呢？”的令人沮丧的想法。
虽然我本意是延续苹果平台优秀的用户体验设计，但使用SwiftUI的短板来达成另一个Framework的长处，这又何尝不是在钻牛角尖呢？于是在Just Toolbox项目中，我转变了思路，寻找“适合使用SwiftUI”开发的场景。
大家可以看到，整个App的导航采用的是标准的SwiftUI Navigation控件，TabView, NavigationStack和NavigationSplitView，按钮, Slider等控件也是尽量在SwiftUI框架内进行UI自定义。于是他们可以在多个平台工作得很好。
2. 当时的SwiftUI还不够成熟，版本差异大
之前我尝试SwiftUI开发的时候，API还相当不稳定，Navigation也不好用，缺少必要的API。当时的iOS还勉强能自己手搓适配，但macOS之类的“用户量少”的平台就非常难受了。以前用AppKit + Storyboard能轻易解决的问题到了SwiftUI上就得各种绕过。
另外就是平台交互差异大的情况下，SwiftUI能不能很好解决的问题。当年苹果在WWDC19上发布SwiftUI的时候我正好在现场，当时还录了一期播客: Vol. 11 谈谈 WWDC 2019。我记得我在节目里提过这个问题。
现在看来，SwiftUI经过5年的发展，已经做到可用的程度了，“只要开发者愿意放弃旧版本系统兼容”。Just Toolbox兼容最低的系统版本是: iOS 16.0，macOS 14.0, watchOS 10.0, visionOS 1.1，跟当下的版本只差一个。
3. 总觉得没做到让自己满意，就不想发布
这点跟技术无关，我相信很多创造者都有这种没来由的不自信。身边也有不少朋友，不管是做App的还是拍纪录片的，明明做了特别厉害的东西，我看了觉得很哇塞，但是他却觉得不够完美，不愿意对外发布。所以面对这种情况，我觉得我的乐天派朋友们反而是更优的。
“有什么关系，大不了再做点别的咯”。先发布再迭代，基于这样的心理转变，我决定把过去这段时间用SwiftUI鼓捣的几个项目再装修装修，然后一个个发出来。
4. 支付逻辑怎么做才是最佳实践
我不是一个全职独立开发者，平时有在上班，所以之前对这方面的考虑可以说非常初级，仅停留在尝试StoreKit 1和2的API的程度。这次在Just Toolbox项目上我尝试接入RevenueCat，只能说他真的很强，省了我很多功夫。他的收费模式是每个月$2.5K支付免费，超过就抽成1%，非常巧妙。
有了上述这些前提，我觉得使用SwiftUI开发一个正儿八经能解决问题的App且运行在苹果全平台，应该是可行的了。
那么使用SwiftUI开发苹果全平台有什么利弊呢？
缺点是共享的代码任意一个平台改了就会影响到其他平台。目前我还不确定同时维护这么多平台到底有没有额外的好处。
优点是一个人开发，一套代码实现苹果全平台变得简单。
以前如果想实现苹果全平台上架，我需要用UIKit开发一次iPhone与iPad版，这两个平台差异不大，只要交互设计愿意接受在iPad上有部分折中，那么直接把iPhone放大拉宽运行在iPad都可以。
接着Mac上我得用AppKit再实现一次UI，逻辑代码可以抽出来共享，甚至激进一点，把MVVM中的ViewModel也抽出来，这样每个平台就剩一个UI壳往里套就好。如果不想用AppKit，那么直接用Catalyst，把iPad版改一改也能运行在Mac上。
接下来，watchOS没辙，以前必须得用Storyboard和WatchKit写一遍，毕竟是完全不同的东西，UI代码几乎没有可以共享的。
最后是visionOS，这个平台上基于3D建模的Immersive交互是他独有的，这部分无法跨平台，他的原生界面则是采用SwiftUI的。所以如果采用老的技术路线，那么我们至少需要UIKit，AppKit, WatchKit和SwiftUI（visionOS）各写一遍。如果愿意基于iPad来折腾，那么macOS和visionOS都能运行基于iPad的版本，只是体验没那么好。
所以在苹果平台上，想要实现一套UI代码运行多个平台，且每个平台都能实现该平台的原生体验，比如macOS的Menubar，比如visionOS的hoverEffect，比如iOS和watchOS各自独有的一些SensoryFeedback，并且这个App是全新开发的，没有历史负担，并且开发者愿意采用SwiftUI的设计思路来设计App，那么确实使用SwiftUI是最优解。
最后，苹果的App Store是一个平台，同时面向大公司与中小开发者。如果论收入比例，可能大公司的App占比很高，但如果论人数与App数量，那么中小开发者才是大头。我觉得SwiftUI就是面向中小开发者设计的，因为大公司有足够的资源去解决各种问题，甚至如上面所说的，每个平台各安排一个Team，就为了让该平台的细节被打磨到最好。但中小开发者，尤其是个人独立开发者可没这资源。并且大家要解决的问题其实也用不到大公司那一套深入框架内部，各种Hack各种奇技淫巧，大家遇到更大的问题是：旧框架的开发门槛相对还是高，而苹果的设备和平台又越来越多。
Catalyst也好，iPad App直接在Mac和Vision Pro上运行也好，我觉得都是权宜之计，没有根本上解决问题。而且强行转接也让开发者痛苦不堪，目前Catalyst做得最好的恐怕只有Craft这样的App，他们的团队也非常强，普通开发者恐怕难以望其项背。
所以拜SwiftUI所赐，我一个人就能开发一个上线苹果全平台的App，这个App面向用户的解决思路也很简单。
提出问题 → 输入原数据 → 处理解决问题 → 输出处理后的数据
这正好也是SwiftUI擅长的。
当然SwiftUI现在已经非常强了，它还非常擅长动画，因为它的渲染就是走CoreAnimation实现的（因为苹果在SwiftUI Team写渲染的那位小哥以前就是CoreAnimation作者），所以我也希望接下来在SwiftUI中尝试更多高级能力，看看这些高级接口的跨平台兼容性会是怎样的。
如果读者朋友们对于Just Toolbox有什么建议，或者有什么希望我去尝试的，欢迎大家给我留言提需求，提Bug。😁
关于定价
目前的定价是: 月付8元，年付38元，Lifetime 68元。
我最早给Just Toolbox设定的价格是:
中国区月付12元，年付80元，Lifetime 168元，
其他区月付2.99美元，年付19.99美元，Lifetime24.99美元。
月付提供一周免费试用，年付提供一个月免费试用。
年付大约是月付乘以7，Lifetime是年付的两倍或三倍。定价策略取决于想要主推的Plan是哪个。但实话实说，本人没有运营个人付费App的经验，今天我发现大家不太会关注“试用”，而是更关注总价😂这就意味着这个价格设定并不足够合理。且Free Trial的吸引力并没有那么强。
首次发布价格设定与App不匹配是宝贵的一课。这里先留个扣，以后有新学到的东西再来更新。
参考https://www.reddit.com/r/chrome/comments/1c8sthv/as_of_chrome_ver_125_the_customizechromesidepanel/
Select Language