想想市面上有多少 WordPress 封装应用，这确实很有意思。
@Aa7 我一时想不出具体优势，但很乐意听听大家的想法。你提到“以用户而非管理员为中心”的思路很明智，这一点我特别认同。
或许，提供白标发布服务可以作为一个切入点？我之所以这么说，是因为曾经有个人在做这件事（名字我一时想不起来了），但现在已经停止了。
或者，我们可以基于对移动端主题的 UX 拆解来从头构建。我注意到，在我的论坛上，有少数人禁用了移动端主题，直接使用桌面版……这或许是一个线索。
此外，谷歌有时也会抱怨某些触控区域太小。
苹果在执行其政策方面确实一直不够一致。
那么，首先你会在整个应用中重构前端吗？我认为你严重低估了这方面工作的复杂性和工作量。
此外，每次 Discourse 发布不兼容的更新时，你都需要：
那么这需要多长时间呢？我猜可能从一天到三周不等？如果你恰好去度假了，也许需要五周？
在此期间，根据你的流程，可能会出现以下情况：
a) 论坛无法更新，可能暴露安全问题
b) 用户无法通过应用使用论坛
我认为这行不通。
我认为这是我们需要解决的主要问题——找到那个能让苹果批准这些封装应用的关键功能，然后采用封装方案。
我知道我之前说过应用更新会随后推出，但新版本的开发是公开进行的。任何调整都可以与这些变更同步进行。此外，Discourse 的代码库已经相当成熟。如果它像 Talk 那样年轻（这并非完全可比的案例），其 API 频繁变动，我想我可能就不会考虑它了。
至于如何察觉变更并保持更新，我认为这是一份全职工作。
我还没有具体估算工作量。我在软件开发领域已有约 13 年的经验——希望我在着手推进这项工作时不会犯下重大错误。
大多数网站运行的是“测试通过”模式，这意味着你总是在追逐兼容性，而不是为发布做准备。
我对 Discourse 的原生应用程序很感兴趣。
这话说得倒是轻巧，毕竟他们连移动 Safari 的推送通知都不支持……
这些“优势”难道主要是针对运营网站/服务的提供商，而不是针对用户吗？当你拥有应用程序时，你的用户会相对更“被动”：他们打开应用，就进入了一个封闭的环境，而不是像在网页浏览器中那样可以随时去往任何地方。他们有一个直接指向你应用的图标，而不是另一个指向你网站的书签（如果他们有的话，或者也许他们迟早会忘记你的网址）。此外，即使用户有一段时间没有打开应用，只要安装了应用，通常还可以接收推送通知。
这很微妙，确实也有论点认为情况并非如此，或者说不使用应用也能实现几乎同样的效果。但在最初，难道不是提供商在推动用户安装他们的应用（即使这些应用并未真正给用户带来什么好处），而不是用户主动要求的吗？（用户随波逐流，逐渐习惯了这种方式，也许现在他们开始要求使用应用，即使他们并不清楚具体原因。也许他们现在觉得这样更方便了。）
我认为是这样。
我目前使用的是官方的 Discourse 应用，想不出它缺少什么（除了我所在站点以及其他几个站点的推送通知）。我很喜欢它。
我真正想要的另一件事是让它显示我们社区的名称和标志，原因如下……
在我的情况下确实如此。人们发现单一用途的设备用起来很愉快。在手机上，你可以通过打开一个应用将其变成单一用途设备。
没错。真是让人恼火。
所以是数据分析。这并非坏事。
抱歉，我没明白。能请你解释一下吗？
出于好奇，你运营的是哪个论坛？谢谢。
请允许我进一步阐述 @Stephen 所说的内容。
作为一名插件开发者，我可以告诉您，保持代码与核心版本兼容并非易事，需要周密的策略。插件通常与“测试通过（tests-passed）”分支保持同步。您也可以选择更新较慢的分支，但这意味着您的客户也会如此。这当然没问题，但您需要在每个稳定版发布后预留时间来更新您的应用。这将是一项繁重的工作，并可能导致客户更新出现显著延迟。
与插件类似，在核心发生重大变更后，您始终面临功能失效的风险。
您提到 Discourse 核心是稳定的。或许比初期更稳定，但请您仔细查看代码仓库，它确实在不断演进（尽管其中很多变动可能来自 Web 应用）。只需看看每天的提交数量，或者查看开放中的 PR（拉取请求）数量。以 Topic.hbs 这一个文件为例，您打算如何跟上它的变化？甚至官方也警告不要对 Discourse 核心进行分叉，原因正是这一挑战。而您计划的是原生重写？
您会只使用他们的 API 吗？如果是，那没问题。但您如何实现那些流行的插件？其中一些插件包含显著的视觉改动，大多使用 JQuery 或插件出口（plugin outlets）进行“猴子补丁（monkey-patching）”，如果您转向原生开发，将无法复用这些。您打算用原生代码重新实现这些功能吗？
插件只是冰山一角。您提出的方案 presumably 涵盖了所有前端用户功能的完整范围。所有这些都需要测试和测试用例。令人惊叹。
您的团队规模有多大？同样，请查看有多少开发者在向核心提交代码。再加上在范围内的插件作者群体，这为您提供了衡量挑战规模的另一个指标。
您的开发速度必须与 Discourse 的发布节奏相匹配（！），否则您的客户会感到自己被新功能所拖累。
您需要为投入的每一小时提供正当理由，并通过收入收回成本（这当然没问题，我们需要养家糊口，和所有人一样）。
但无论如何，我认为您可以尝试实现一个演示版本。我建议从“仅仅”核心应用开始。这将很快让您体会到任务的艰巨性。或者，只需统计您需要支持的所有 API 调用数量。
我相信您已经考虑过所有这些。我并非要泼冷水，但您提出的是一项极其繁重且持续不断、毫不留情的艰巨工作。
不如先看看官方应用，看看您能在此基础上做些什么？
公平地说，我认为如果这是一个原生代码应用，而不仅仅是网站的“简单”WebView 封装，这应该不是问题。
确实如此，目前已有大量原生实现的 Web 应用案例。例如 Facebook（尽管其 Web 应用表现糟糕）。
完全原生的实现可能并不存在风险。
他们真正针对的是那些“封装”式的应用。我已编辑了帖子。
我也曾考虑过开发一个完全原生的应用程序（我是一名 iOS 开发者）。我会基于 Discourse 的（公开？）HTTP API 来构建。请问该 API 的稳定性是否有保障？或者它是否采用了某种版本控制机制，以防止旧版应用程序意外失效？
已投入原生应用的社区可以跟随我们的慢速分支（即“稳定版”）。此外，我们很少更改 API，它们非常稳定。
该应用可以基于 Discourse REST API 构建，该 API 应该相当稳定。这样一来，它可以采用任意想要的 UI/UX 设计，甚至可以与网页版不同（这可能更好，也可能更糟）。如果应用作者选择其他方法（我不确定这是否可行），就会遇到您所描述的痛点。
是的。外观不同但保持一致性，可能会受到部分人的好评，但前提大概是这是一款可以添加多个实例的应用（就像官方应用那样）。然而，这并不是许多人所关心的。试想一下，如果你的网站自定义应用与网站本身的风格完全不同，那肯定不合适。
此外，我难以想象会有人对一个不支持其网站所有功能的应用感到满意。因此，插件的问题从一开始就显现出来了。
我同意，这可能是棘手之处。如果不支持插件，原生应用最终可能看起来比 Web 封装版本更差。一个合理的初步方案是支持最流行的插件，并随时间推移逐步增加对其他插件的支持。