大家好，我从事原生移动应用开发已有约6年时间，主要为 iOS 和 Android 平台构建应用，例如 Texties，其中一些应用已拥有数百万用户。
我想了解一下 Discourse 论坛所有者对原生 iOS 和 Android 移动应用的兴趣。
这很可能是一个通用型应用，用户只需输入主机名并登录即可使用（而非白标定制版本）。但关键在于它是原生应用，支持几款热门插件，并具备推送通知功能。
我希望能投入时间，为愿意支付年费以通过此类应用访问其论坛的论坛所有者开发这些应用。但我不确定是否有足够的论坛所有者对此感兴趣，从而使该项目在经济上可行。
大家怎么看？如果您运营着一个 Discourse 论坛，您是否愿意为您的用户付费购买一款原生移动应用？
仅供参考，我已与这里的某位版主沟通并获得许可在此发布此内容。
我有兴趣，只要年费对我来说合理就行。
“也许”
在将拟议的原生应用与现有的支持推送功能的浏览器封装代码进行比较时……
原生应用对最终用户有何优势？据我所知，网页版本质上是一个通过网页交付的应用，一旦代码被缓存，运行速度会非常快。我可以作证：我自己在飞机上的 Wi-Fi 环境中，发现 Discourse 社区几乎是唯一可用的服务。
此外，让用户手动输入 URL 对于付费产品或服务而言，在 UI/UX 上是一个重大失误。
对我而言，最关键的是要弄清楚原生应用能为最终用户带来哪些实实在在的、可感知的优势。
是的，非常期待原生应用。我认为可以使用 React Native 来实现。目前有一个为 Discourse 构建的 React Native 应用（https://github.com/pmusaraj/discourse-mobile-single-site-app），但它本质上只是一个包装器，并未通过 JSON API 进行交互，因此无法带来真正的移动应用体验。
这与官方 Discourse 应用有何不同？如果它能带来显著优势，我可能会有兴趣。
谢谢——我确实看到了 OneSignal 的版本，做得很不错。我可以从中借鉴一些关于推送集成的思路。
在经历了与 Cordova 和 React Native 相关的痛苦体验后，我目前的做法是原生开发应用（即在 iOS 上使用 Swift/ObjC，在 Android 上使用 Java/Kotlin），因为这样某些事情更直接明了。像 RN（以及新兴的 Flutter）这样的方案看起来非常棒，我希望有一天能够实现“一次编写，到处运行”——但目前 RN 尚未提供足够的效率。
这只是我个人的看法。有些人非常喜欢 RN。我也承认，原生开发同样存在一些问题。
我会在另一条回复中尝试阐述为何我认为原生应用优于封装方案（或引用一些外部资料），其核心在于原生应用的响应速度和动画效果通常更加流畅，用户体验也更佳。我知道“更好”是一个主观概念，但我会尽力寻找一些示例来说明这一点。
我同意——要求用户输入网址才能访问他们的论坛，这并非最佳体验。
我主要是从话语社区成员的角度来思考。他们的话语体验会有多大提升？会是翻天覆地的变化吗？这对他们来说真的重要吗？最后一个问题至关重要。
就我而言，我赞同你指出的那些普遍理由，倾向于使用母语。
但当我想到我的社区时，我会考虑这在优先级、投资回报率（ROI）等列表中会排在什么位置。
值得深思。
开发原生应用是否意味着需要复制 Discourse 的所有功能？如何跟进更新？是否支持插件？
我猜，大多数非托管在 Discourse.org 上的网站都会对 iOS 推送通知的优势感兴趣。
我以为上述白标“包装”应用中已经支持了 iOS 和 Android 的推送通知？我们只需要添加推送服务提供商的代码即可。
如果我能在我自托管的实例上通过官方 Discourse 应用接收推送通知，那对我来说倒是个新消息。
啊，我指的是使用白名单版本的情况。在 Discourse“官方”应用中，我从未考虑过这一点。
你好，
是的，但必须是一个支持我们 Discourse 论坛插件的白标版本，并且需要随 Discourse 的更新而保持同步。
问题在于，我们无法在不添加 Web 应用尚不具备的功能的情况下，让苹果批准白标版本。而他们认为推送通知不足以构成开发一个应用的充分理由——仅仅为了一个论坛！太让人恼火了。
这是个非常好的问题。我希望 Discourse 的 API 版本管理遵循语义化版本规范（这也是我需要核实的一点之一）。这样一来，当 Discourse 发布不兼容的更新时，应用程序的更新也必须随之跟进。
相比之下，跟进那些不会破坏 API 的增量功能更新则不那么关键。显然，我需要保持定期的更新节奏以应对这类情况。
我认为支持最流行的插件（例如 Discourse 官方托管服务提供的插件）是一个起点（也是理所当然的）。
对于不在该列表中的插件，我认为我们可以随着需求人数的增加逐步添加支持。我猜存在一个阈值，超过该阈值后支持某个插件就变得势在必行。目前我还不知道这个阈值具体是多少。也许如果某人有很强的理由需要在应用中使用某个冷门插件，我就能优先为其开发支持。
我不这么认为——我的意思是，我认为它不会包含供管理员管理站点的功能。它主要应支持普通用户参与论坛活动。
我认为这些观点都很中肯。仅仅成为原生应用本身并不能满足用户（或希望向其用户提供该应用的管理员）的需求。我想了解的是，如何利用原生应用固有的优势来创造价值。其中一些优势在封装方案中也可能很容易实现。
我意识到，在某个阶段，只有将产品交到少数人手中，才能判断其是否值得继续推进。原生开发是实现推送通知、更优的触控目标和响应速度、动画效果、导航以及更贴近其他移动应用风格的布局等功能的途径。
我原本希望能了解哪些功能是必须具备的，哪些插件最受欢迎，同时也想向论坛所有者提出同样的问题：哪些因素会让原生应用对您来说物有所值？
你的论坛安装了哪些插件？你可以私信发给我列表。我很想知道。
@jtbayly 假设苹果允许您为白标应用采用推送通知的封装方案。这对您来说是否足够？那么上述提到的 OneSignal 分支是否对您来说也足够好？