native 和 RubyMotion 生成，不是一样原生的吗？没理解意思。谁来讲讲。

我又迷惑了，现在看意思好像是都是用 RubyMotion，只是一部分是本地控件，一部分是 webview。

#3 楼 @Rei 有些东西必须用原生的 oc 来实现，这部分用 RubyMotion，这样说你可明白？

#4 楼 @shiren1118 这是一种可能，“page stacking behavior and navigation menus”不像是 RubyMotion 实现不了的东西。

The word native here is opposite to webview. native does not mean use Objective-C

In other words, RubyMotion is native

我猜作者的意思是，相对于一般的 app，Basecamp for iPhone 的核心部分是在 WebViews 里的，只有 page stacking 和 navigation menus 等是用 UIKit 来实现的。换句话说，project 和 discussion 等视图是直接用 html 来实现并通过 WebView 来展现的（这个其实只要用一下 app 就能判断出来）。

如 6 楼所说，这里的 native 是相对于 webview 来说的。但 WebView 也是 native 的，只是 WebView 里加载和显示的内容是 html 而非 naitve 的：）

如果完全用 native 来实现是怎么做的呢？现在放 WebView 的地方，按需求放上各种 UIControl，具体点来说，头象可能会用 UIImageView，显示的人名、讨论内容等会用 UILabel 或是 UITextView，用户输入内容的地方会用 UITextView。写过 iOS 应用的开发者都知道，要用这种方式来展现 Basecamp 那样丰富的内容，代码实现起来是非常耗时间精力的，而且有个致命的问题：要修改布局或修复 bug 非常麻烦，做完之后还要等待漫长又无法预估的审核期。

而 WebView 里加载的 html，对于 Basecamp 这样的 app 来说显示是在 server 端生成的。app 上架后，这些核心功能可以象 web app 一样随时改进并发布。37Signals 在 AppSotre 上要做的，就是把整体性能、bug 等控制好，并完善 page stacking 和 navigation menus 等功能（个人认为这个 app 做的非常棒，它的 page stacking 的方式其实并没有脱离 Path、Facebook 等带动并流行起来的侧边栏的使用方式，但 stacking 外观以最后划出时斜掉下去的效果都相当舒服漂亮）。

我个人认为，这个 app 的好坏跟是否使用了 RubyMotion 是没有直接关系的。一是，既然大部分功能是在 WebView 里完成的，那么在 App 端实现的代码量应该不是太大。二是，作者如果之前不是用 Ruby 的话，在这里选择 RubyMotion 在生产力上不见得会有多少提升（作者也提到在调用 Cocoa API 的时候，他们一般遵循 Objective-C 的习惯而非 Ruby 的）。

@ashchan 还是你讲的比较清楚。这样，完全可以作为一个成功范式了。