我会尽我所能把这个问题作为一个可以回答的问题，而不是作为讨论的开始。
我的问题的本质是，根据您的经验，是将您的网站的移动网络版本开发为一个单独的应用程序，使用您的网站作为API，还是在为您的网站提供服务的同一个Rails应用程序中进行开发？
我目前正在计划如何实施它，下面是我认为每一个的优点/缺点。
移动web的独立应用程序
- 优点
- 性能：现有网站的开销更少=性能更好
- 占地面积更小：更易于组织和更清洁的应用程序
- 去耦合：将迫使我们为台式机/移动设备构建服务
- 不利因素
- 子域：必须使用m.thredup.com，这样移动流量才能路由到单独的应用程序
- 会话管理：必须处理多个应用程序/域上的身份验证
- 地方发展更难：为地方发展提供的另一项服务
- 分支机构管理：新代码要求web应用程序+移动应用程序有单独的分支机构
移动web的相同应用程序
- 优点
- URL计划：能够在桌面+手机上使用相同的URL（更容易共享）
- 会话管理：能够使用现有的用户会话
- 更快的实现：更短的项目时间线，因为所有后端逻辑都已经到位
- 下行
- 代码膨胀：为我们已经很大的Rails web应用程序提供更多代码
如果我们要在现有的应用程序中开发移动web，以下是我们渲染移动视图的方法-http://scottwb.com/blog/2012/02/23/a-better-way-to-add-mobile-pages-to-a-rails-site/
如有任何见解，我们将不胜感激。
如果你设计网站，让你可以对任何设备使用相同的代码库，让它智能地适应你的设备，并根据样式表或渲染/非渲染的运行时选择为每个设备呈现最重要/有用的内容/功能，那么你十有八九会过得更好。请记住，与6年前不同的是，今天你对移动设备的主要担忧不是缺乏处理能力，而是不同的屏幕大小和不同的输入。
一般来说，移动用户不希望看到你网站的残缺或剥离版本。他们希望看到您网站的可用版本。可用性的含义各不相同，但它通常意味着最频繁的功能非常容易访问，而更模糊的选项则隐藏得更低，或者可能没有优化。可用可能意味着你给它们提供了与桌面上完全相同的功能，但在移动设备上表现得更好。或者你在手机上删掉了一些毫无意义的东西。但是，如果您将其设置为必须维护两个代码流，或者一个很早就分支的代码流，或一个根本不同的应用程序，那么您将使自己更加困难。这需要更多的测试，更多的编码，以及更多的破坏可能性。
我们遵循这种方法，它对我们非常小的开发团队非常有效——我们已经成功地使用了它，这样我们就可以使用相同的代码库为不同的客户运行两种不同的实现——一种是非常复杂的桌面优先UI，另一种是一个非常精简的移动优先应用程序：
- 假设所有设备都将访问相同的URL
- 假设90%的设备优化将使用CSS媒体查询完成，7%将使用jQuery技巧完成，3%将在早期使用浏览器检测完成
- 构建您的应用程序，以便通过代码（ApplicationController？Rack Midleware？中的逻辑）轻松启用/禁用各个UI组件或模块。我们通过将单独的"小部件"放在部分中来实现这一点，这些部分被检查小部件的启用情况（在Rails.config中或作为侧ApplicationController中的实例变量）包裹，这样我们就可以关闭是否将相应的HTML返回浏览器
- 使用CSS媒体查询不仅可以设置字体和宽度的样式，还可以重新排列菜单/功能和其他UI项，使它们能够处理所需的不同形状因素
一般来说，如果你要为移动设备构建一个经过编译的应用程序，并且要使用设备的UI库而不是服务器上生成的HTML来完成UI的繁重工作，那么API-for-mobile方法将对你最有用。再者，如果您选择使用Backbone.js或Angular.js等方法来处理前端显示器，那么使用API专用方法可能也是一个很好的架构。但你会更多地走出Rails。
在我看来，最重要的信息是"为什么？"，你需要考虑你的预算、工作时间表和截止日期。
如果你使用类似Matthew James Taylor的出色布局的液体布局，它将根据可用的屏幕大小调整大小。我认为需要移动特定模板的唯一原因是为了提供特定的css样式，使你的视图看起来更像移动应用程序。
我不认为性能是个问题。如果你有来自现有网站的性能开销，并且你正在为移动设备设计这些性能问题，那么为什么不为非移动设备也设计这些问题呢。即设计具有液体布局的移动站点，并使其也适用于台式机/平板电脑观看。这可能是一个很好的机会来重新设计整个网站，以提高性能。
我看到你真的有两个选择取决于预算和时间尺度
1） 设计一套全新的模板，同时使用液体布局设计性能问题，以期随着时间的推移将现有布局切换到新布局
2） 重新设计现有的模板和功能，使之成为一个移动友好的网站。
无论哪种方式，你的台式机和平板电脑用户都会受益，但你能走多远取决于你的截止日期和预算，选项1是短期内更便宜、更快的方式，选项2是长期内更便宜和更快的方式。在我看来，如果不为移动用户和台式机/平板电脑用户提供相同的模板，你就会对某个人不利，因此为所有用户提供尽可能好的体验。
这确实是项目经理的决定。
更新-基于评论
在这种情况下，我会开发一个单独的仅限移动设备的应用程序。我甚至会考虑使用替代技术来直播更新的数据。Rails Live Streaming和Node.js.之间有一个很好的比较
无论你是否选择引入新技术，通过为移动用户提供一个单独的应用程序，你都将提供终极的移动体验，并能够完全专注于此。
我不认为不同的域名对SEO来说是一个太大的问题。你应该能够利用现有的可见性从主网站和一个单独的移动域名，你很可能会提高你的SEO排名，而不必做太多额外的推广。
我想你已经对最好的前进道路得出了自己的结论，我能给你的最好建议是告诉你多给自己一点思考时间，让你选择的解决方案变得坚定，我相信如果是正确的，你会"感觉"正确。
没有人比你更了解你的业务，如果不参与项目和业务，就不可能说出什么是最终的最佳选择。