为 Mac OS X 重新设计 iPad 应用程序的步骤？
对于一个应用程序来说，从 iPad 应用程序到 Mac 应用程序需要将哪些通常预期的用户可见设计习惯改变，即提供基本相同的功能，至少看起来相当 Mac OS X 原生？
用户通常期望的一些更改可能包括：
将“设置”按钮和“信息”按钮移至“首选项...”和“关于...”的菜单选项
将“设置”视图和“信息”视图或弹出框移动到它们自己独立的“首选项”和“关于”窗口，而不是主窗口中的视图。
为常用按钮添加一些菜单项和菜单键（如浏览器中的前进和后退按钮）。
支持箭头键滚动任何自定义视图项。
支持鼠标悬停以显示帮助弹出窗口或动态菜单。
如果应用程序支持“文档”，则允许一次打开多个文档，每个文档在各自的窗口中打开。
还有什么？一个简单的通用 2D 游戏所需的最小更改是什么？
添加说明：
请注意，我不认为将具有相似外观、位置和行为的类似 UI 类重新编码为 NS 类（例如 UIButtons 到 NSButtons）是一个重大变化。这些变化对用户来说几乎是不可见的。
目标是尽可能少地进行更改，以便购买应用程序 X 在 iPad 上执行 Y 操作的用户可以购买应用程序 X 在 Mac 上执行 Y 作为 Mac 应用程序，但学习曲线尽可能接近于零。但似乎需要进行一些更改，否则该应用程序看起来就不是 Mac 应用程序（例如，缺少“关于...”菜单项会显得有点奇怪。）
What commonly expected user-visible design idioms need to change from an iPad app to a Mac app for an app, that is to provide basically identical functionality, to seem at least reasonably Mac OS X native?
Some of these changes, commonly expected by users, might include:
Move the Settings button and Info button to Menu selections for Preferences... and About...
Move the Settings view and Info view or popover to their own independent Preferences and About windows instead of being views in the main window.
Add some menu items and menu keys for commonly used buttons (like the forward and back buttons in a browser).
Support arrow keys for scrolling any custom view items.
Support mouse-over for help popups or dynamic menus.
If the app supports "documents", allow more than one document to be open at a time, each in their own windows.
What else? What's the minimum change required for a simple generic 2D game?
Added clarifications:
Note that I do not consider re-coding similar UI classes to NS classes (for instance UIButtons to NSButtons), with similar look, positions and behaviors, to be a significant change. Those changes are pretty much invisible to the user.
The goal is to change as little as possible so that a user who purchased app X to do Y on an iPad might purchase app X to do Y on their Mac, as a Mac application, but with as close to zero learning curve as possible. But it seems that some changes need to be made, or the app would not seem to be a Mac app (for instance, a missing About... menu item would seem a bit strange.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
你已经偏离轨道了。考虑将其添加到您的列表中：
You've gone off the rails right there. Consider adding this to your list:
我们在同一条船上，面临着同样的问题。
我们的结论是从一个“新鲜”的真实 Mac 应用程序开始，并使其看起来相似，即使用相同或相似的 UI 组件和图形。该应用程序应以其他方式开发，就好像没有 iPad 版本一样。
首先，很多用户没有有 iPad 版本。这些用户期望得到一个成熟的 Mac 应用程序，而让它在任何方面都感觉像 iPad 是没有意义的。
其次，如果Mac应用程序只是iPad版本的纯粹克隆，没有任何附加价值，那么来自iPad版本的用户会感到被剥夺了。想想从 iPhone 到 iPad 的第一次转变——再次为纯粹的高档产品付费是令人沮丧的，从长远来看可能会损害您的业务。
首先设计一个全新的简化用户界面，然后考虑可以重用和制作类似的内容。功能可能在一个方向或另一个方向上有所不同。无论如何，您的模型代码应该在所有地方都有效。
We are in the same boat and faced the same question.
Our conclusion is to start with a "fresh" real application for Mac and make it look similar, i.e. using the same or similar UI components and graphics. The app should be otherwise developed as if there was no iPad version.
First, there will be many users that don't have the iPad version. Those users expect a full-blown Mac application and it doesn't make sense to make it feel iPad in any way.
Second, users coming from the iPad version will feel ripped of if the Mac app is just a pure clone of the iPad version with no added value. Think of the first transitions from iPhone to iPad - paying again for nothing but pure upscales is frustrating and might harm your business in the long run.
Starting out designing a fresh streamlined UI and then think of what you can reuse and make similar. Functionality may differ in one direction or the other. Your model code should work in all places anyway.
不完全是您问题的答案，但请查看 Chameleon。它本质上是
UIKit到 Mac 的端口。它由 The Icon Factory 创建，旨在让开发人员能够轻松地将他们的 iOS 应用程序移植到 Mac。 IIRC Twitterific 使用 Chameleon 移植到 Mac。Not exactly an answer to your question, but take a look at Chameleon. It's essentially a port of
UIKitto the Mac. It was created by The Icon Factory to make it easy for developers to port their iOS apps to the Mac. IIRC Twitterific was ported to the Mac using Chameleon.以下是我从 iPad 应用程序创建 Mac 应用程序并使其被 Mac 应用商店接受的方法。
忽略了完全重新设计应用程序的建议（用户相当喜欢 iPad 设计）。
创建一个 Mac 应用项目并包含所有 iOS 源代码的一个分支。
手动重新编码所有 UI 元素及其相应的 NS 元素。将它们调整为 Mac UI 指导尺寸。检查当调整主窗口大小时它们是否全部显示在某个合理的位置。删除了仅限 iPad 的委托，例如旋转处理程序等。这导致了全新的视图控制器代码，但几乎所有代码都只是其他范例的并行翻译。
将视图坐标设置为翻转，这样就不必为任何 Core Graphics 绘图例程重新计算 Y 坐标。 （模型和 CG 绘图代码几乎是直接移植的，没有任何变化，除了窗口大小的比例因子等。）
从主窗口视图控制器中删除设置和帮助视图。实现一个首选项窗口 xib 和一个帮助窗口 xib，并将所有设置和首选项视图和控件放在那里。添加一个顶级控制器来显示/隐藏 3 个窗口。
添加一些带有热键的菜单选项，以实现用户可能想要在不触及鼠标/触控板的情况下点击的等效 UIButton 操作。
添加一个credits.html 文件。
向图标设计添加轮廓形状和透明度蒙版，然后填充到 .icns 文件中。
将一个窗口屏幕截图填充到更大的所需尺寸。
So here's what I did to create a Mac app from an iPad app, and have it accepted into the Mac App store.
Ignored the suggestions to completely redesign the app (users reasonably liked the iPad design).
Create a Mac app project and include a branch of all the iOS source code.
Manually recode all the UI elements with their corresponding NS elements. Resize them to Mac UI guideline sizes. Check that they all show up in some reasonable place when the main window is resized. Deleted iPad only delegates, such as rotation handlers, etc. This resulted in completely new view controller code, but almost all the code was just a parallel translation of the other paradigm.
Set the view coordinates to flipped so the Y coordinates won't have to be recalculated for any Core Graphics drawing routines. (The Model and CG drawing code pretty much ported straight over without change, except for scale factors for window size, and such.)
Remove settings and help views from the main window view controller(s). Implement a Preferences window xib and a Help window xib, and put all the settings and pref views and controls there. Add one more top level controller to show/hide the 3 windows.
Add some menu selections with hotkeys for equivalent UIButton actions that a user might want to hit without reaching for the mouse/trackpad.
Add a credits.html file.
Add an outline shape and transparency masks to the icon design, and stuff into an .icns file.
Pad the one window screen shot out to the much larger required size.