Pic Zip: Bulk Resize to PDF
1. 自我推广一下
如果你有批量压缩图片,打包到zip或者单个pdf文件的需求,不妨试一试这款免费的,轻量的iOS软件.
直观的UI,没有privacy concern,无广告.
任何反馈都很欢迎.
2. Updates (2025-07-28)
2.1 收益
我曾经在搬家前的老博客上写过一篇文章,
2年过去了, 没有广告投流,小众需求,没有宣发,纯粹靠AppStore自然流量, 甚至几乎没做ASO的情况下,这是整个lifetime 的成绩单数据:
可以看到:
- 整体获得了将近4.56k的下载量.
- AppStore搜索页占了大部分流量.
- 除了两位好心人的2美金打赏外,没有任何其他收入.
- conversion rate低,说明要么我的ASO不太行,比如title,截图,关键字,都有问题; 要么需求过于小众.
这个结果是我意料之中的. 结论就是: 靠自然量,不做宣发,大量竞品,没有自己一套”流量工程学”的方法论, IndieDev难以为继.
2.2 接下来怎么办?
- 立项时,考察需求,不能靠拍脑袋,要形成自己一套能证伪的需求方法论,流量工程学方法论.
- 更好的本地化支持,目前语言翻译及其糟糕.当时用的ollama3.1 8B的模型翻译
- 比机翻好不了多少的翻译造成了ASO负优化.
- 用户自传播/分享时带上水印tag等等
- 外链,自发宣传.
- ASO + A/B test. 但是在弱需求的前提下,先天底子太差,不可能”结上品金丹”.
3. 背景
3.1 学习SwiftUI,一鱼两吃
这是我第一个非实验性质作品1.
在阅读了官方SwiftUI教程,同时查看修改了几个非官方的优秀的开源项目后 我迫切的需要一个实际动手项目来加深自己的理解.
注,如果你是Swift新手,推荐看完官方教程后,自己编译并修改一下你自己感兴趣的,简单的,优秀的开源项目. 比如RunewordsApp2和IceCubesApp3
3.2 App功能
App来源我自己生活中的具体需求: 在上传文件打包时,网站对照片大小有具体要求,有时需要一次性上传多张图片. 这个需求在涉及文件提交行业,或者事宜时,需求量还比较大. 比如: 退税时,你需要整理所有相关的图片到一个PDF或者zip中.
4 技术栈
- SwiftUI
- StoreKit (为了添加buy me a coffee打赏,学习StoreKit内购的运作流程)
- Analytics (为后来的用户分析做准备)
- ZipFoundation
- fastlane
- github
5. 一些踩过的坑
自己动手以后意味着各种各样的坑. 不要做云玩家.
5.1 收起完美主义,拿出实用主义
作为独立开发路上的第一个产品,还是不可避免的沾染了学生时代的书生气.
对于初次尝试独立开发的人来说,“堆量”是主要矛盾.
只有量上去了,同时不要给某一个App/产品寄予不且实际的高期望,
才能迅速积累经验,获得成长.
拿时髦的话来说,就是”先做个垃圾出来”的哲学.
5.2 反复重构 vs 新项目
重构不可避免. 但是每一次重构都应该有足够的理由. 如果仅仅调整UI,那么你应该思考,下一次是否应该提前做好组件化的工作. 如果是App体量变大了,需要添加Analytics埋点, 那么你就能思考怎么样埋点最合理.
重构时,尽量”另辟炉灶”,不要完全推倒重来,会引起动荡. 这个我会以后添加一篇,独立开发工程管理最佳实践的文章,进行总结.
5.3 不要在UI上花费太多时间
尽量使用原生控件,否则就会出现类似WWDC25之后,因为”liquid glass”引起的一篇哀嚎. 应用原生控件的同时,学习简单的配色原理,还有一个优势,就是开发成本会被拉的很低. Layout的设计更多的是UX的课题,这个我们要会抄,从自己用的顺手的,优秀的App里面找老师.
5.4 多语言
记录自己以前的多语言版本,如果某一个翻译出问题,尽快回滚. 多语言不要盲目用AI进行翻译. 如果一定要用大模型来做多语言的工作,尽可能用好一点的大模型. 这方面我也会继续实践.
5.5 在干中学,实践是最好的老师.
学习一门新语言新技术,实际动手做一做吧. 下面这些问题,只有你实践并思考了,才能有自己的一套答案.
从工程角度出发,你能理解为什么有些代码需要这么写. 为什么两种写法,一种比另一种更好. 为什么有各种各样的,为了简化代码量的语法糖. 等等.
6. 其他探讨
6.1 关于AI
AI就像是人人都能用的枪械/高精尖武器. 但是经过系统性训练的人,会应用的更好. 同时作战,指挥,部署,协同等等
6.2 SEO
这篇文章我会在其他论坛作为外链推广,来推广自己的公众号. 给自己的网站引流. 实践并加深自己对SEO的理解.