我如何在 6 个月内将 GitHub Store 打造到 12,500 星标 — 我 16 岁时开始

抱歉，我只看到了来源链接，而没有看到需要翻译的正文内容。请您提供文章的其余部分（除代码块和 URL 之外的文字），我就可以按照要求进行翻译了。

Source: …

半年前，我还是乌兹别克斯坦的一个 16 岁少年，想要发布我自己写的一个小 Android 应用。

Play Store 的流程对这个项目来说太繁琐了，我于是自己做了一个替代方案。

六个月后，这个替代方案——GitHub Store——已经拥有 12.5 k+ 星、250 k+ 次更新、支持 13 种语言，并且可以在 Android、Windows、macOS 和 Linux 上运行。我在几周前刚满 17 岁。

这就是故事的全部，包括我差点放弃的那段经历。

Play Console 的壁垒

我之前也把应用上架过 Play Store，那时候觉得值得——真实的应用、真实的用户，摩擦成本是做生意的一部分。

这次情况不同。我在参加 Philipp Lackner 的 Mobile Dev Campus 挑战，做了一个让我自豪的小副项目，想把它发布出去。我重新阅读了 Play Console 的要求后直接停住了。

• 25 美元费用
• 政府身份证
• 地址验证
• 20 名封闭测试者
• 最低 2 周的封闭测试
• 等等… 也许会被批准

一个副项目要花一个月的流程，算不下来。

GitHub 已经允许开发者在 Release 中发布 APK，于是我想：在此基础上构建一个商店。这块空白就成了项目的起点。

我当时不知道的事

坦诚地说：刚开始时，我并不知道 F‑Droid 或 Obtainium 的存在。后来有人在我已经发布之后才告诉我这些。如果第一天我就知道，我可能根本不会去构建 GitHub Store。我只会直接装上 Obtainium，然后继续前进。

有时候，无知也是一种特性。

为什么选择 Kotlin Multiplatform

• 在此之前，我已经有大约两年的原生 Android 开发经验。
• Kotlin 是我的语言。Compose 是我的 UI 工具包。

其他选项都需要学习全新的生态系统：

KMP 让我可以把两年的 Android 经验直接搬到桌面端，而无需更改语言、IDE 或思维模型。我之所以选择它，是因为可以更快地交付。

1 周 MVP，未使用编码助手

GitHub Store 的首个版本在 一周内 完成发布。

• 全情投入。停课。停学。很多夜晚几乎不睡。
• 零编码助手。没有 Cursor、没有 Copilot、没有 Claude Code。只有 IntelliJ、Compose Multiplatform 文档、Ktor 文档和我的双手。

发布内容：

• 通过公共 API 实现 GitHub Releases 搜索
• 资产过滤——仅显示 APK 和桌面安装包，隐藏噪音
• 在 Android 上通过系统安装器实现“一键安装”
• 单一 UI 代码库：Android + Windows + macOS + Linux

粗糙，但是真实。它能跑。

我在 LinkedIn 上发布了它，甚至连 MVP 的技术定义都还不完整——这是我第一次在 LinkedIn 上发帖。约 100 条互动，5 k+ 次曝光，而我的个人资料之前几乎没有任何内容。随后几天，我又在 Kotlin Slack 社区里分享了它。

发展轨迹

我真的没有预料到会发生什么。增长最初很慢，随后却突然加速。我每达成一个里程碑都会在 LinkedIn 上发帖——这些帖子的互动比最初的发布还要多。

在这段时间里，最大的助推器是 HowToMen。他在大约 2 000 星标时，在他的 Top 12 App Stores Better than Play Store 视频中推荐了 GitHub Store。他的受众正是这款应用的目标用户：注重隐私、已经对 Play Store 持怀疑态度的 Android 用户。随后轨迹在那之后……

Source: (保持原样，不翻译)

t 视频看起来不同。

不可避免的比较： 是的，我了解 Obtainium。我每周都会被问到“为什么不使用 Obtainium？”

Obtainium 是针对你已经熟悉的仓库的轻量级高级用户更新器。GitHub Store 是面向还不知道该安装什么的人的 先发现后使用 商店——而且它是跨平台的。使用 Obtainium。使用 GitHub Store。两者都用。我们构建了 Obtainium 的导入/导出功能，让库可以在它们之间一键切换。

2‑3 k 星的低谷

我几乎从这篇文章中删掉的部分。

在 2‑3 k 星左右，我变得怪异。低头埋头数月。产品开始受到关注。有人写了好评。问题堆积。

我开始失去方向。

我会打开仓库，只是盯着看。

我为什么要这么做？会有人长期使用它吗？星标数量只是虚荣吗？我是不是在浪费生命做一些毫无意义的事？

那段时间我和 ChatGPT 聊了好几个小时。一次或两小时的对话。不是为了代码帮助——而是为了思考。和我同龄的朋友们并没有在做产品。我的疑惑在我的生活中没有合适的人可以倾诉。

把我拉出来的并不是某个洞见，而是 具体的用户信息：

• 一位开发者私信我说他们的工作流已经改变。
• 一条 bug 报告开头写着 “我喜欢这个应用，但 …”。
• 一位维护者声称这是他们的仓库，并说这是他们的项目第一次拥有真正的 store page。

他们根本不知道我在自我怀疑。他们只是普通的用户在使用这个东西。

如果你在构建某个东西： 低谷是真实存在的。外部的成功并不会让你有什么感觉；它只是摆在那里。来自真实用户的可感知反馈才是帮助。让他们容易联系到你。

我会对 16 岁的自己说

1. 先发布，再了解受众。
   我在发布之前没有研究受众。受众自然出现——喜欢折腾的 FOSS 用户，讨厌广告，讨厌追踪，重视隐私。了解这些让我后续的每一个产品决策都有依据：开放后端、无遥测、捐赠渠道、无暗黑模式。先发布，再去研究。受众的反馈比你的假设来得更快。

2. KMP 有效。即使在桌面端也是如此。
   跨平台的说法不是营销噱头。

3. 分发本身就是一个功能。
   F‑Droid、Obtainium 配置、Scoop、Winget、IzzyOnDroid —— 我添加的每一个渠道都是产品功能。不能安装你的用户根本不存在。

4. 直接与用户对话。就在应用内部。
   更新日志根本不够。大多数人根本不看它——我这辈子从未打开过 Play Store 页面里的 “有什么新”。

   创建一个简单的反馈渠道，亲自回复，让这成为你下一轮迭代的燃料。

My life. So I built an in‑app **what’s‑new** sheet (short, bullet‑format) that pops up after every update, an announcements feed for surveys and security notes, a *Send feedback* card with a diagnostics preview before you send, and a Discord. The first real survey I ran told me what 12 000 stars couldn’t.

**Localize early.**  
People will use your app worldwide if it’s good and they can read it. The limiters are language and network. GitHub Store ships in 13 languages and runs through a backend proxy that survives the Great Firewall. That’s why Chinese, Russian, and Arabic users are here.

**The hardest part isn’t the code.**  
Nobody warned me about the valley.

本地化要早。
如果你的应用足够好且用户能读懂，它就会在全球范围内被使用。限制因素是语言和网络。GitHub Store 支持 13 种语言，并通过后端代理运行，能够穿越防火长城。这就是为什么有中文、俄文和阿拉伯语用户。

最难的部分不是代码。
没有人提醒过我关于低谷的事。

接下来

• 还有很多内容即将推出。
  全新的设计，远比当前的更出色。

• 更好的桌面支持——有望实现与 Android 相同的自动更新机制。

• 用户体验提升 100 倍。

• 最终会推出付费层。唯一原则：GitHub Store 只对我们实际需要成本的功能收费——存储、带宽、计算、监控。任何在你设备上运行的内容永远免费。后端是开源且可自行托管的。关于原因的独立文章即将发布。

如果你看到这里——请尝试一下。如果它帮到了你，就给它加星。如果没有，请提交 issue。如果你是发布 APK 或桌面安装包的开发者，请认领你的商店页面（免费，敬请期待）。如果你是某个地方的青少年，正考虑发布项目：那就直接开始吧。Play 商店可以等你，GitHub Releases 已经触手可及。

— Usmon (@rainxchzed)

github-store.org · GitHub · Discord · Sponsor