WordPress のラッパーアプリが数多く存在することを考えると、これは興味深いですね。
@Aa7 利点を思い浮かべるのに苦労していますが、皆さんのアイデアを聞くのはもちろん歓迎です。ユーザーと管理者への焦点を絞っている点は賢明だと感じます。
もしかすると、ホワイトラベル出版サービスを提供することが、この分野への入り口になるかもしれません。かつてそれを手がけていた人物（名前は思い出せませんが）がやめてしまったからです。
あるいは、モバイルテーマの UX 解体分析から構築する方法もあるかもしれません。私のフォーラムでは、いくつかのユーザーがモバイルテーマを無効にして、デスクトップ版をそのまま使っていることに気づきました。それがヒントになるかもしれません。
また、Google は過去に、タッチ領域が小さすぎるという指摘をしたこともあります。
Apple は確かにポリシーの執行において一貫性がありませんでした。
まず、アプリ全体でフロントエンドを再構築するのでしょうか？そこで行う必要がある作業の複雑さと量を見積もりが甘すぎるように思います。
そして、Discourse の非互換なアップデートがあるたびに、以下の手順を踏む必要があります。
これにどれくらいの時間がかかるでしょうか？1 日から 3 週間でしょうか？もし休暇中なら 5 週間かかるかもしれませんね。
その間、プロセス次第では以下のどちらかの状況になります。
a) フォーラムをアップデートできず、セキュリティ上の問題に晒される可能性がある
b) アプリを通じてフォーラムを利用できない
この方法はうまくいかないと思います。
これが解決すべき最大の課題だと思います。Apple がこれらのラッパーアプリを承認させるための「銀の弾丸」となる機能を見つけ出し、その上でラッパーアプローチを採用する必要があります。
アプリのアップデートが続くと言いましたが、新しいリリースの開発はオープンに行われています。そのため、これらの変更と並行してあらゆる適応が可能になります。それに、Discourse は成熟したコードベースです。API が頻繁に変更される Talk のような若いプロジェクト（直接比較できるわけではありません）であれば、検討しなかっただろうと思います。
変更点に気づき、最新情報をキャッチアップすることについては、それはフルタイムの仕事だと考えます。
作業量の見積もりは特にしていません。ソフトウェア開発には約 13 年携わってきましたので、具体的なステップを踏んで進めていくことで、大きな誤りを犯さないことを願っています。
多くのサイトではテスト通過が前提となっているため、リリースの準備ではなく、互換性の追跡に追われることになります。
Discourse のネイティブアプリに興味があります。
それは、彼らがモバイルSafariのプッシュ通知を提供していないことを考えると、皮肉な話です…
その「メリット」は、ユーザーよりもむしろサイトやサービスを提供する側にあるのではないでしょうか？アプリを持っていると、ユーザーは少し「囲い込まれた」状態になります。アプリを開けば、どこへでも自由に移動できるウェブブラウザではなく、閉じた環境の中にいることになります。ブックマークとしてサイトを保存する（もし保存していれば、あるいはいつか URL を忘れてしまう可能性もありますが）代わりに、直接アプリへ繋ぐアイコンがホーム画面にあるのです。また、アプリをインストールしていれば、ユーザーがしばらくアプリを開いていなくてもプッシュ通知を送れるという利点もあります。
これは微妙な点であり、それが事実ではない、あるいはアプリがなくても同様のことを実現できるという反論も確かにあります。しかし、当初はユーザーがアプリを求めていたのではなく、提供者側が自社のアプリをインストールさせようとしていたのではないでしょうか（実際にはユーザーにほとんどメリットをもたらさない場合でも）。ユーザーはその流れに乗り、いつしかこのやり方に慣れ、今ではなぜか分からないながらもアプリを求めているのかもしれません。もしかすると、今はそれが便利だと感じているのかもしれません。
そうだと思います。
現在、公式の Discourse アプリを使用しており、（私のサイトや他のいくつかのサイトへのプッシュ通知を除き）不足している機能は思い当たりません。気に入っています。
本当に望んでいるのは、コミュニティの名前とロゴが表示されることです。その理由は…
私の場合もそうです。人々は単一目的のデバイスの使いやすさを好みます。スマートフォンでは、アプリを開くことでそれを単一目的のデバイスにすることができます。
その通りです。腹立たしいことです。
さて、分析。悪いことではありません。
申し訳ありませんが、意味がわかりません。詳しく説明していただけますか？
気になったのでお伺いしますが、あなたはどのフォーラムを運営されていますか？ありがとうございます。
@Stephen が述べた内容を補足させてください。
プラグイン開発者としてお伝えしますが、コアとの互換性を保つためにコードを最新に保つことは簡単な作業ではなく、慎重な戦略が必要です。プラグインは通常、テストがパスしたブランチに合わせた形で維持されます。より遅いブランチを選ぶことも可能ですが、その場合、クライアントもそれに合わせて遅れることになります。それは問題ないかもしれませんが、安定版リリースのたびにアプリを更新するためのリードタイムが必要になります。これは非常に多くの作業となり、クライアントへの更新に大きな遅延をもたらす可能性があります。
プラグインと同様に、コアに大きな変更が入った後に何かが壊れるというリスクは常に存在します。
Discourse コアは安定しているとおっしゃいますが、確かに初期に比べれば安定しているかもしれません。しかし、リポジトリを注意深くご覧いただければ、それは変化していることがわかります（その多くは Web アプリに関するものかもしれませんが）。1 日にコミットが何件行われているか、オープンになっているプルリクエストの数をぜひ確認してみてください。Topic.hbs という 1 つのファイルだけでも、それをどうやって追いかけていくかを考えてみてください。この課題のために、Discourse コアのフォークを推奨しないという警告さえあります。しかも、これはネイティブでの書き直しになるのでしょうか？
API のみを使用するのでしょうか？それなら問題ありませんが、人気のあるプラグインの機能を実装するにはどうするのでしょうか？それらの多くは、JQuery を使ったモンキーパッチやプラグインアウトレットなどによる大幅な視覚的変更を含んでおり、ネイティブ化すればそれらを再利用できなくなります。それらをネイティブコードで再実装するのでしょうか？
プラグインは氷山の一角に過ぎません。あなたが提案しているのは、おそらくすべてのフロントエンドユーザー機能の完全な範囲です。これらすべてをテストする必要があります。テストケースも必要です。ただ驚きです。
そして、あなたのチームの規模はどれくらいでしょうか？再び、コアにコミットしている開発者の数をご覧になってください。さらに、対象となるプラグイン作者の人口を加算してみてください。それがこの課題の規模を測るもう一つの指標になります。
Discourse のリリースペースに合わせた速度（！）を維持する必要があります。そうしなければ、すべてのクライアントが新機能から取り残されていると感じ始めるでしょう。
あなたが費やすすべての時間を正当化し、収益で回収する必要があります（それは当然です。私たちと同じように、生活を支える必要があります）。
いずれにせよ、デモを目的としてこの実装に取り組んでみることをお勧めします。まずは「単に」コアアプリから始めるのがよいでしょう。これですぐにこのタスクの規模がどれほど大きいかを実感できるはずです。あるいは、サポートが必要な API 呼び出しの数を数えてみるのも一案です。
もちろん、これらすべてについてすでに考慮されていることと思います。悲観的なことを言いたいわけではありませんが、あなたが提案しているのは、継続的かつ容赦なく厳しいレベルの膨大な作業量です。
公式アプリを見て、それで何ができるか検討してみてはいかがでしょうか？
公平を期して言えば、単なる Web サイトの WebView ではなく、ネイティブコードで実装されたアプリであれば、これは問題にならないと思います。
その通りです。ネイティブ実装のWebアプリの例は数多く存在します。例えばFacebook（ただし、同社のWebアプリはひどいものです）がそうです。
完全にネイティブで実装されたアプリは、おそらくリスクにさらされることはないでしょう。
彼らが狙うのは「ラップされた」アプリです。投稿を編集しました。
ネイティブアプリの完全な実装についても検討しました（私はプロのiOS開発者です）。Discourseの（公開されている？）HTTP APIをベースにしたいと考えています。APIの安定性やバージョン管理について、古いアプリバージョンが予期せず動作しなくなることを防ぐ保証はあるでしょうか？
ネイティブアプリに投資しているコミュニティは、スローブランチ（通称「安定版」）をフォローできます。また、API は頻繁に変更されず、非常に安定しています。
このアプリは、比較的安定しているはずの Discourse REST API をベースに構築できるでしょう。その場合、アプリは独自の UI/UX を採用でき、Web アプリとは異なるデザインにすることも可能です（これが良くなることもあれば、悪くなることもあります）。もしアプリの作成者が他のアプローチを選んだ場合（それが可能かどうかはわかりませんが）、あなたが説明しているような問題に直面することになります。
はい。見た目は違っても一貫性があることは、一部の人が肯定的に捉えるかもしれませんが、それは公式アプリのように、1 つのアプリに複数のインスタンスを追加できる場合に限られるでしょう。しかし、多くの人が求めているのはそれではありません。あなたのサイトの独自アプリのスタイルがサイト全体と全く異なっている状況を想像してみてください。良いことではありません。
また、サイトのすべての機能をサポートしていないアプリに対して、誰が満足するでしょうか。そのため、プラグインはすぐに問題となり始めます。
同意します。これが厄介な部分になる可能性があります。プラグインがサポートされていない場合、ネイティブアプリはWebラッパーよりも見劣りする結果になるかもしれません。最初の段階では、最も人気のあるプラグインをサポートし、時間とともにサポート範囲を広げていくのが妥当でしょう。