我做 ToApp 这半年的几件事 — 一个独立开发者的复盘

ToApp 在 2026 年 2 月 22 日发布，6 月 6 日走到 v1.10.0。中间是三个多月的主动开发，加上后面几周写你正在看的这个配套网站的时间。这段时间里，ToApp 从"我自己用着勉强能跑的第一个版本"变成一个被比我预期多得多的用户使用的工具——全程免费、无广告、无需注册、所有数据在用户手机本地处理。

这篇文章是一份复盘。不是营销稿，也不是庆功文——是一次真实的回头看：我做了什么，为什么做这些决定，作为独立开发者做一个网站转应用工具的过程中我学到了什么。我会讲三件事：版本时间线（每个版本到底发生了什么）、关键设计决策及其权衡（为什么本地处理、为什么 WebView、为什么免费）、以及配套网站的 SEO 策略（一个静态营销站如何反哺 App 的下载量）。

如果你是一个想做工具类 App 的独立开发者，或者单纯好奇 ToApp 这样的工具是怎么做出来的，这篇文章是写给你的。

为什么要写这篇复盘

大多数 App 的更新日志止于一个版本号和一串功能列表。这对记录"改了什么"够用，但解释不了"为什么"。为什么 ZIP 本地打包——这个现在 ToApp 的核心功能——要等到 v1.9.1 才出现，发布三个月之后？为什么所有其它网站转应用工具都在云端打包，ToApp 却坚持本地处理？为什么 v1.10.0 之后我决定暂停更新？

这些问题重要，因为答案揭示了塑造一个产品的权衡。更新日志告诉你上线了什么，复盘告诉你没上线什么、差一点上线什么、以及什么只是因为用户一直问才上线。对独立开发者来说，更新日志和真实故事之间的这道缝隙，才是大部分真正的工作发生的地方。

还有一个自私的原因：写这篇逼我诚实地看过去半年。一个人开发的时候，没有人给你做复盘会，你只能自己给自己写。

时间线：从 2 月到 6 月

下面是完整的版本历史，但我按我实际记得的方式组织——不是一串功能列表，而是一串阶段。每个阶段有不同的重点，重点的切换取决于那个阶段用户最需要什么。

阶段一："勉强能跑"（v1.0.0，2 月 22 日）

ToApp 的第一个版本在 2026 年 2 月 22 日上线。v1.0.0 的更新日志写得异常诚实："Had the idea to build this myself, so started development and released a barely usable first version"（自己有这个需求，所以动手做了，发布了一个勉强能用的第一版）。这不是营销话术——这就是字面意思。我想要一个工具，能把一个网站变成 Android APK，不需要我配置 Android Studio、不需要注册开发者账号、不需要折腾 Gradle 构建。市面上没有免费、本地、在手机上能做这件事的工具。所以我自己做了一个。

v1.0.0 只做一件事：输入网址，得到 APK。没有本地文件支持，没有多页面导航，生成的 App 里没有暗色模式开关。但它能跑，并且全程在手机上完成。最后这一点是从第一天起就不让步的约束——我会在设计决策那一段回到为什么。

阶段二：稳定与清理（v1.0.1 – v1.2.2，2 月下旬）

头两周是纯粹的稳定性工作。v1.0.1 修复了主题切换、加了更新日志页面。v1.2.0 加了隐私政策同意流程、反馈功能、WebView 文件下载，以及——对一个免费 App 很重要的——赞助提醒。v1.2.1 修了从二级页面返回列表页的卡顿、加了网页视频全屏播放。v1.2.2 修了暗色模式的一个回归 bug。

注意这个模式：上线后头十天几乎全是修 bug。这是正常的。不管发布前测多少，真实用户总能找到你想象不到的边界情况。独立开发者一定会交付 bug，问题是修得快不快。这个阶段我每隔一两天就发一个修复版本。

阶段三：导航问题（v1.3.0，3 月 3 日）

v1.3.0 是 ToApp 真正开始好用的转折点。头条功能是可折叠的底部导航栏——下滑隐藏，按音量上键唤回。听起来很小，但它解决了一个真问题：底部导航栏会挡住那些不是为 App 设计的网站的内容，用户想要全屏浏览。用音量上键唤回这个设计，避开了和网页触摸交互的冲突。

这个版本还修了两个一直在悄悄出问题的东西：包名自动生成（之前没有正确地从应用名称推导包名）和 APK 签名兼容性（BKS、JKS、PKCS12 多种 keystore 格式）。签名兼容性比你以为的重要得多——签名 bug 意味着生成的 APK 装不上，整个工具就废了。

阶段四：持久化与误报（v1.4.0 – v1.5.0，3 月上旬）

v1.4.0 加了新版本自动检测——App 启动时检查更新，一键下载。功能不大，但对不会主动查更新日志的用户来说体验提升明显。

v1.5.0 比更新日志看上去更重要。两件事：第一，手机安全软件把 ToApp 生成的 APK 误判为恶意软件（a.gray.BulimiaTGen.h，一个误报）。我用官方签名、代码混淆、资源优化解决了这个问题。如果你好奇为什么 ToApp 生成的 App 不像其它一些网站转应用工具那样触发安全警告，原因就在这里。第二，v1.5.0 加了完整的存储支持：Cookie 持久化和 IndexedDB。这意味着生成的 App 终于能记住东西了——登录态、缓存数据、App 状态——而不是每次打开都重置。

阶段五：真正的浏览器行为（v1.6.0 – v1.7.0，3 月中旬）

v1.6.0 是个小版本（赞赏列表），但 v1.7.0 是又一个实质性进步：生成的 App 现在可以请求浏览器级别的权限——摄像头、麦克风、定位、文件上传。这正是让 ToApp 从"包一个静态站"扩展到更多场景的关键。v1.7.0 之后，你可以做一个真正调用设备硬件的 App，而不只是展示网页内容。

阶段六：重头戏——本地文件打包（v1.8.0 – v1.9.3，5 月）

更新日志里 3 月中旬到 5 月初有一段空白。这段空白是真实生活——我能投入的时间有限，而下一个功能是最难做的。v1.8.0 在 5 月 8 日上线，带来一批体验改进（关闭下拉刷新、生成 App 内的相机上传、对话框稳定性、项目排序）。

v1.9.1，5 月 31 日，是改变 ToApp 身份的版本。ZIP 本地文件打包在这个版本上线。v1.9.1 之前，ToApp 是一个网站转应用工具——你给它网址，它给你 APK。v1.9.1 之后，ToApp 同时变成了一个离线 App 构建器：你可以给它一个本地 HTML/CSS/JS 的 ZIP 包，它会打包成一个不联网也能独立运行的 App——一次真正不需要服务器的 ZIP 转 APK 转换。正是这个功能让"零基础开发你的第一个 App"那篇教程成为可能——没有本地文件打包，就没法把 AI 生成的 HTML 转成 APK。

v1.9.3，6 月 2 日，加了边到边手势导航适配——让生成的 App 在新版 Android 的手势导航下感觉更原生。

阶段七：暂停（v1.10.0，6 月 6 日）

v1.10.0 在 6 月 6 日上线。这个版本的更新日志写得非常直白："由于经济和时间原因，ToApp 在此后很长一段时间内不会更新。"这不是营销决定，也不是战略转向。这是一个诚实的承认：我没法在不burnout的情况下维持之前的开发节奏，而 App 的收入也不足以支撑它需要的时间投入。

我不会假装这个决定容易做。但这是对的决定。因为太累而测试不充分就发一个有 bug 的版本，比暂停更糟。所有历史版本仍然在更新日志页面提供下载，FAQ覆盖了常见问题。

几个关键决策的"为什么"

只列功能的复盘不诚实。更重要的是塑造这些功能的决策——我做的权衡、我选择不做的事、我拒绝妥协的约束。下面是定义 ToApp 的四个决策。

决策一：本地处理，不做云端打包

这是塑造其它一切的决定。我所知的其它网站转应用工具——AppsGeyser、GoNative、WebIntoApp、AppMySite——都在云端打包。你把网址或文件上传到他们的服务器，他们的服务器构建 APK，你下载结果。ToApp 不这样。所有打包都在用户的手机上、在 WebView 里完成，不需要联网。

权衡如下：

• 成本：云端打包意味着服务器成本，总有人要为构建服务器付费。通常这个"人"是用户——通过订阅、广告，或者卖他们的数据。本地处理意味着我零服务器成本，这也是 ToApp 能永久免费的原因。
• 隐私：云端打包意味着你的网址、HTML 文件、图标、包名配置全部要离开你的设备。本地处理意味着这些东西永远不离开你的手机。对打包企业内网站点或个人文件的用户来说，这是"能用"和"绝对不行"的差别。
• 速度：本地打包更快。没有上传、没有排队、没有下载——生成只要几秒，不是几分钟。
• 功能迭代速度：这是代价。云端打包允许开发者服务端热修复，不需要用户更新。本地处理意味着每个修复都要用户下载新 APK。这是 ToApp 更新节奏后期变慢的部分原因——每个版本必须扎实，因为我没法远程打补丁。

如果重做 ToApp，我会做同样的选择。对一个本质上是"把你自己的内容装到你自己的手机上"的工具，隐私和成本的优势大于迭代速度的代价。

决策二：WebView 架构，不是 React Native 或 Flutter

ToApp 生成的是混合应用——原生 Android 外壳通过 WebView 渲染网页内容。我本可以做一个生成 React Native 或 Flutter 应用的工具，那样生成的 App 会有更原生的手感和更好的性能。我没有，原因很简单：WebView 是唯一能让用户把任何网站或 HTML 文件转成 App 而不需要重写一遍的架构——ToApp 所做的 HTML 转 APK 转换，用 React Native 或 Flutter 都不可能在不重写的前提下实现。

如果你有一个 WordPress 博客、一个 Hexo 静态站、一个手写的 HTML 作品集、或者一个 AI 生成的单页工具，你没有 React Native 代码——你有的是 HTML。WebView 是把现有内容打包成 App 而不完全重写的唯一方式。这是 ToApp 的整个前提。切换到 React Native 或 Flutter 生成器，意味着告诉用户"先把你网站重写成 React Native 应用"——这就违背了初衷。

代价是 WebView 应用永远不会像真正的原生应用那样流畅。动画可能卡顿，复杂页面滚动可能掉帧，某些设备 API 需要额外的桥接。对 ToApp 的使用场景——个人工具、博客外壳、企业站点、离线小工具——这是可以接受的。对一个高性能游戏或一个复杂的社交应用，不可接受，ToApp 不是合适的工具。

决策三：永久免费，无广告，无需注册

ToApp 免费、无广告、不需要账号。这不是一个"核心功能免费、高级功能收费"的 freemium 模式。所有功能都免费。决定很简单：本地处理意味着没有服务器成本，没有服务器成本意味着我不需要向用户收费来覆盖基础设施——这也是 ToApp 能永久作为免费 APK 生成器存在的原因。唯一的持续成本是这个网站的托管（一个 Cloudflare R2 存放 APK，一个静态站放这些页面），可以忽略。

代价是"永久免费"意味着没有收入流来支撑持续开发。这是 v1.10.0 暂停更新的真正原因——不是因为我失去兴趣，而是因为免费工具付不起房租。关于页面的赞助按钮有帮助，但它覆盖不了时间投入。如果你是一个考虑同样模式的独立开发者，提前知道："永久免费"是对用户的承诺，也是对未来的自己的约束。不要轻易做这个承诺。

决策四：不上 Google Play

ToApp 生成的 APK 是标准的 Android 包，可以提交到 Google Play，但 ToApp 本身不在 Play Store 上架，我也不建议用户把他们生成的 App 上架到那里。原因是 Google Play 对基于 WebView 的应用审核政策相当严格——很多壳应用被拒或下架。作为独立开发者去对抗这个审核流程，不值这个时间。

所以 ToApp 通过这个网站分发，生成的 App 由创作者直接分发（sideload、内部分发、分享 APK 文件）。这对 ToApp 的实际场景够用：个人工具、给家人的礼物、企业内部应用、原型。这些都不需要 Play Store。如果你确实需要 Play Store 上架，ToApp 不是对的工具——这是一个诚实的回答，不是我想掩盖的局限。

你可以对比 ToApp 和其它网站转应用工具，看看这些决策相对其它选项如何。

配套网站与 SEO 打法

这是复盘里我在别处没见人讲过的部分，也是对其它独立开发者最有用的一节。大部分 App 的更新日志和个人博客都跳过它。但对一个没有营销预算的免费工具，配套网站不是锦上添花——它是唯一的获客渠道。下面是这个站怎么结构化的，以及为什么。

站点架构

ToApp 网站不是一个单页落地页。它是一个内容站，按目录组织，每个目录有明确的 SEO 目的：

• 首页——以转化为目标的落地页。3 步讲清楚 ToApp 做什么、展示截图、放下载按钮。目标是头部词"网站转应用"和"免费 apk 生成器"。
• FAQ——回答用户实际会搜的问题。每条 FAQ 都用 FAQPage schema 标记，用于富摘要。覆盖长尾查询，比如"webview 应用怎么隐藏底部导航栏"。
• 术语表——解释底层概念：WebView、APK、PWA、混合应用、网站转应用。每个术语页目标一个定义类查询，并回链到首页和 FAQ。这建立"网站转应用"主题集群的权威性。
• 使用场景页——六个页面，一个场景一页：博客转应用、企业官网、电商、作品集、离线应用、开发者。每页目标一个具体意图（"把我的博客做成 App"、"离线网页应用生成器"），并链接到下载。
• 对比页——四个页面，ToApp 对比 AppsGeyser、GoNative、WebIntoApp、AppMySite。覆盖对比阶段的搜索流量（"toapp vs appsgeyser"、"gonative 免费替代"），转化那些正在选型的用户。
• 博客——长文内容，做教程、故事、概念讲解。这是漏斗顶端的内容，吸引那些还没在搜"网站转应用"、但在搜"开发第一个 App"或"html 打包 apk 教程"的用户。
• 更新日志——版本历史。给老用户建立信任，同时覆盖那些在搜"ToApp 还在维护吗"的用户。

SEO 逻辑：主题集群，不是关键词堆砌

这个站围绕主题集群模型构建。核心主题是"网站转应用"——把一个网站或网页文件变成 Android App 的行为。站上每个页面都服务于这个集群：

• 首页目标头部词。
• 术语表目标定义类查询，建立主题权威性。
• 使用场景页目标具体意图查询。
• 对比页目标漏斗底部的决策查询。
• 博客目标漏斗顶端的教育类查询。

内链是刻意的。每个页面都链接到首页、FAQ、术语表、下载区。术语表页面互相链接并回链首页。博客在正文中链接相关术语（你在这篇文章里已经看到过几个这样的链接）。这形成一个密集的内链图，帮助搜索引擎理解站点结构，并在页面之间传递权重。

多语言：中英文 + hreflang

这个站完全双语——中文在 /，英文在 /en/。每个页面都有 hreflang 标签指向两个语言版本，x-default 设为英文。对一个像 ToApp 这样的工具，这不是可选项：用户基数在中英文用户之间分裂，正确服务两种语言意味着搜索覆盖面翻倍。

代价是维护成本——每个页面存在两个版本，改动要做两遍。这也是为什么我把页面数量控制在可承受范围。新增一篇博客意味着写两遍（你正在读中文版，英文版同时存在）。但 SEO 收益显著——中文和英文搜索市场基本不重叠，同时覆盖两个市场意味着潜在触达翻倍。

结构化数据：每页都有 Schema.org

站上每个页面都有 application/ld+json 结构化数据。首页用 SoftwareApplication 和 HowTo schema。FAQ 用 FAQPage。术语表用 CollectionPage 和 ItemList。博客用 BlogPosting、BreadcrumbList，教程还用 HowTo。你正在读的这篇文章用 BlogPosting、Article 和 BreadcrumbList。

结构化数据不直接提升排名，但帮助搜索引擎理解页面内容，并启用搜索结果中的富摘要。对一个和大厂竞争的小站，富摘要是显著的可见性收益。光是 FAQPage schema 就让 ToApp 的 FAQ 条目在多个查询下显示为可展开的富结果。

真正带来下载的是什么

诚实地说。首页转化最好——带着下载意图落到首页的用户，转化率很高。但首页不是流量最大的页面。有机流量的大头来自长尾：FAQ 条目、术语表定义、使用场景页，以及现在的博客。

对比页特别有价值，因为它们覆盖决策阶段的用户——搜"appsgeyser 替代品"或"gonative 免费替代"的人已经决定要一个网站转应用工具，只是在选哪一个。这是高意图用户，而一个诚实地讲清楚权衡的对比页（ToApp 免费且本地，但功能比付费替代品少）比一个假装 ToApp 在所有方面都更好的对比页转化率更高。

写在最后：关于暂停与未来

ToApp 是暂停，不是放弃。App 仍然能用，网站仍在更新（这篇文章就是证据），更新日志页仍然列出每个版本供下载。暂停的是 App 本身的主动功能开发。

我想诚实地说为什么。作为独立开发者做一个免费工具，只有两种情况下可持续：要么你有其它收入来源覆盖生活费，要么工具本身产生足够的支持（捐赠、赞助、付费层级）来支撑时间投入。ToApp 有慷慨的支持者——App 里的赞赏列表是真的，我感谢上面每一个人——但它覆盖不了一次认真的更新周期所需要的时间。所以我暂停了，而不是发一个测试不充分的东西。

接下来呢？我不知道。我有一个想加的功能清单：生成 App 里更好的离线缓存、更多导航样式、可能加一个项目分享系统。但我不会承诺一个我守不住的时间线。诚实的答案是"等我有时间和资源，我会回来做"。在那之前，ToApp v1.10.0 是一个稳定、可用、免费的网站转应用工具，做它说要做的事，而这个网站会继续讲怎么用它。

如果你是 ToApp 用户在读这篇文章：谢谢。这个工具有足够多的人在意、一直用、一直问功能、一直报 bug、一直发反馈——这是它能走到这一步的原因。如果你是独立开发者：希望时间线、设计决策和 SEO 那几节对你有用。做你希望存在的东西。能免费就免费。诚实地讲权衡。需要暂停的时候就暂停——互联网上充满了本该诚实暂停、最后却变成弃坑的项目。

这就是复盘。六个月，十四个版本，一次暂停，和一个仍在生长的配套网站。感谢读到这里。