iPhone 应用程序：Web 应用程序还是本机应用程序？
我计划为我们的在线网络应用程序创建一个 iPhone 应用程序版本。我对 iPhone 应用程序开发还是个新手，所以我不知道是选择 iPhone 本机还是在 iPhone 浏览器上运行的 Web 应用程序。
这个要求实际上是非常基本的。 iPhone 应用程序需要提交数据并从 Web 应用程序也使用的数据库中获取数据。用户对网络应用程序具有相同的访问权限，只是我希望这一点特定于 iPhone，因为使用网络应用程序和 iPhone 应用程序的用户体验会有所不同。我也有兴趣在苹果商店销售该应用程序。
根据您的经验，对于这种需求，iPhone 原生还是 Web 应用哪个更好？构建在 iPhone 浏览器上运行的本机 iPhone 应用程序和 Web 应用程序有哪些缺点？另外，我是否只能使用 Objective-C 来构建本机 iPhone 应用程序？或者还有其他框架吗？
请对我温柔点，我不是要挑起一场口水战。
I am planning to create an iPhone apps version for our online webapps. I am still new to iPhone apps development so I don't know whether to choose iPhone native or a webapps that runs on iPhone browser.
The requirement is actually pretty basic. The iPhone apps need to submit data and get data from the database that is also used by the webapps. User would have the same access to the webapps, only I want this specific to iPhone, as the user experience would be different using a webapps and iPhone apps. I am also interested to sell the application on Apple store.
Based on your experience, what would be better for this kind of requirement, iPhone native or webapps? What are the drawbacks building a native iPhone apps and webapps that runs on iPhone browser? Also, am I only limited to Objective-C to build a native iPhone apps? Or is there any other framework for that?
Please be gentle on me, I am not starting a flamewar.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
你可以鱼与熊掌兼得。
您可以通过使用
UIWebView实例轻松混合 Web 和本机应用程序，例如在 Cocoa/Objective-C 代码中实现性能敏感的部分，并在需要重写的部分中插入 WebKit 视图，这些部分太耗时，无法重写为本国的。如果您想要 App Store 分发，您甚至可以将整个 Web 应用程序包装在本机包中 - 请参阅 PhoneGap。
您还可以开发纯粹的 Web 应用程序，如果用户将您的页面添加到其主屏幕，该应用程序看起来不会像通过 Safari 启动 - 请参阅jQTouch.
缺点：
Web 应用程序可能不如本机应用程序快，尽管借助 HTML5 离线支持和特定于 WebKit 的扩展（例如过渡和动画），您可以走得更远。确保使用触摸事件 - Safari 延迟
onclick。很难让纯网络应用感觉像正确的本机应用程序。例如，移动 WebKit 不支持复制顶部导航栏所需的
position:fixed，并且 Web 视图的滚动速度与表格视图不同。它是可以修复的，但需要大量 JavaScript。优点：
发展迅速。当我必须在 UIView 中复制应用程序时（InterfaceBuilder 仅适用于半固定布局），我真的很欣赏 CSS/HTML 对于复杂布局的有用性。
你可以避免苹果公司突然讨厌和禁止另一件事。如果他们从 AppStore 中删除您的应用程序，您可以让用户通过网络访问它（Google 通过 Voice 和 Latitude 应用程序做到了这一点）。
将网络应用程序移植到 Android 和其他设备（WinMo、HP Pre、最新的 BlackBerries 等）上更加容易。Apple 排名第一，但其关注度与市场份额并不成正比。其他人正在迎头赶上。
如果你选择原生，
你必须按照苹果的方式来做：Objective-C 和 Cocoa（你可以用纯 C 或 C++ 来完成部分应用程序）。关于这个主题的教程和书籍有很多，所以我不会在这里重复。只是一些随机的建议：
plist 尽管是“原生”iPhone 格式，但并不是客户端-服务器通信的最佳选择。即使按照 XML 标准，XML plist 也具有很高的开销，并且二进制 plist 的生成和调试可能会很痛苦。 JSON 实际上更快，通常更容易使用。
如果您只获取少量信息，
NSConnection只会使事情变得复杂。您只需在通过performSelectorInBackground:启动的方法中使用[NSData dataWithContentsOfURL:]即可。UITableView滚动时不会发送通知。如果您希望在表中延迟加载图片，请使用回调加载并设置它们。You can have the cake and eat it too.
You can easily mix web and native app by using
UIWebViewinstances, e.g. implement performance-sensitive parts in Cocoa/Objective-C code, and insert WebKit views in parts which would be too time-consuming to rewrite as native.You can even wrap whole web app in native package, if you want App Store distribution — see PhoneGap.
You can also develop pure web app that won't look like it's launched via Safari, if user adds your page to his home screen — see jQTouch.
Drawbacks:
Web apps may not be as fast as native application, although with HTML5 offline support and WebKit-specific extensions like transitions and animations, you can get pretty far. Make sure you use touch events — Safari delays
onclick.It's hard to make pure web app feel like proper native application. For example mobile WebKit doesn't support
position:fixedneeded to replicate top navigation bar, and web views have different scrolling speed than table views. It's fixable, but requires ton of JavaScript.Advantages:
Rapid development. I really appreciated how useful CSS/HTML is for complex layouts when I had to replicate apps in
UIViews (InterfaceBuilder is OK only for semi-fixed layout).You're insured against Apple suddenly hating and banning yet-another-thing. If they remove your app from AppStore, you can let users access it via web (Google did this with Voice and Latitude apps).
It's easier to port web apps to Android and others (WinMo, HP Pre, latest BlackBerries, etc.) Apple is number #1, but its mind-share isn't proportional to market share. Others are catching up.
If you choose native
You have to do it Apple's way: Objective-C and Cocoa (you can do parts of application in plain C or C++). There's plenty of tutorials and books on the subject, so I won't repeat them here. Just some random bits of advice:
plists, despite being "native" iPhone format, aren't the best for client-server communication. XML plists have high overhead even by XML standards, and binary plists might be pain to generate and debug. JSON is actually faster and usually easier to work with.
If you fetch only small bits of information,
NSConnectiononly complicates things. You can simply use[NSData dataWithContentsOfURL:]in method launched viaperformSelectorInBackground:.Notifications are not delivered while
UITableViewis scrolling. If you want lazily-loaded pictures in your table, load and set them using callbacks.如果您想在 iTunes App Store 上拥有应用程序，则必须使用 Objective-C 编写该应用程序。
以下是 iPhone OS 4.0 开发者协议的引述，摘自 Daring Fireball。我已经突出显示了最相关的部分。
这当然不适用于 OS 3.1 或 3.2，目前尚不清楚一旦 OS 4.0 发布，Apple 是否会追溯删除任何使用此类工具的现有应用程序。理论上，如果你设法在 4.0 发布之前推出该应用程序，而且你很幸运，那么也许你可以利用 PhoneGap 之类的东西，但此时花时间使用这些工具似乎是一场很大的赌博。
也就是说，Objective-C 确实不难学，它的主要语法是
[someObject doSomething];或[someObject doSomethingWith:thisObject];我掌握的很少网络开发知识，所以我不能谈论它的优点或缺点，但如果你在网络应用程序中设置了所有内容，你可能想要倾向于上面提到的混合选项或纯粹基于网络。If you want to have an app on the iTunes App Store you must write the app in Objective-C.
Here is a quote from the iPhone OS 4.0 developer agreement as pulled from Daring Fireball. I have highlighted the most relevant section.
This of course does not apply to OS 3.1 or 3.2 and it is currently unknown if once OS 4.0 comes out Apple will retroactively remove any existing applications that have made use of such tools. In theory if you manage to get the app out the door before 4.0 comes out and you get lucky then perhaps you could make use of something like PhoneGap, but it seems like a really big gamble to spend time using those kinds of tools at this point.
That said, Objective-C really isn't that hard to learn, it's primary syntax is
[someObject doSomething];or[someObject doSomethingWith:thisObject];I have very little knowledge of web development so I can't speak to it's merits or disadvantages, but it you have everything set in a web app you may want to lean toward either the hybrid option mentioned above or going purely web based.Noah 提到的 PhoneGap 绝对是您可以进行 HTML+javascript 开发并仍然打包的路线它用于分发，以及利用 iPhone 的许多出色的本机功能。
其余的全部取决于您尚未共享的一些元素。您希望 UI/搜索的响应有多快和流畅？在这种情况下，Web 应用程序的延迟（甚至超过 3G）可能会鼓励您寻找替代方案以在本地更快地呈现它（使用所有本地的，甚至 Objective-C）。
其他地方，听起来不像是在你的道路上，寻找你可能想要直接做 Objective-C 的地方是围绕动画的更重的图形和操作（尽管 javascript + Canvas 和 HTML5 让我成为一个骗子）那里），使用相机和/或麦克风记录多媒体，或需要相当大量的密集处理的东西。最后一个问题实际上是您可以在哪里以及您想完成这项工作吗？在服务器上（典型的 Google 风格选择）还是在设备上？
PhoneGap, which Noah mentions, is definitely a route you can take to do the HTML+javascript development and still package it for distribution, as well as taking advantage of a number of the great native features of the iPhone.
The rest is all dependent on some elements that you haven't shared. How fast and smooth do you want the response from the UI/Search to be? That's a place where the latency of a web application, even over 3G, might encourage you to look for an alternative to present it faster locally (using all local, or even Objective-C).
The other places, which don't sound like they're in your path, to look for where you might want to do Objective-C directly are heavier graphics and manipulations around animation (although javascript + Canvas and HTML5 are about making me a liar there), using the camera and/or microphone to record multimedia, or something that requires a reasonably large amount of intensive processing. And the last is really a question of where can you and do you want to have that work done? On the servers (typical Google style choice) or on the device?