[译]假如 Mac 上也有 iOS 应用?

简介: 本文讲的是[译]假如 Mac 上也有 iOS 应用?,没有人专门为 Mac 开发应用,Slack 有专门的 iOS 版本,放在 iPad 上的体验非常好,接上 smart keyboard 以后,你会发现还可以方便的使用快捷键。而且,在应用上无限下滑的体验甚至超过了他们本身的网页端
本文讲的是[译]假如 Mac 上也有 iOS 应用?,

假如 Mac 上也有 iOS 应用,世界将会怎样?

没有人专门为 Mac 开发应用,Slack 有专门的 iOS 版本,放在 iPad 上的体验非常好,接上 smart keyboard 以后,你会发现还可以方便的使用快捷键。而且,在应用上无限下滑的体验甚至超过了他们本身的网页端,甚至于我从来没有看到过一个“加载中”的页面。这体验如果能够放到桌面端那是再好不过了,但是他们没有这么做,他们仅仅只是把他们的网页放到了一个 app-launcher 里,这就成了桌面端。

Basecamp 是这么做的,Wordpress 是这么做的,甚至连 Mac App Store 自己,都只是一个 webview 而已。

对于那些所谓的“应用”,我是再讨厌不过了。我理解大公司的选择,他们不喜欢跨平台。设计师们需要专门做设计,QA 需要测试更多的环境,而文职人员们则要费力去翻译那些“原生视图”到更为工业界接受的“页面视图”。那些大公司一直不愿意费力气去替代跨平台的 Html 5 应用也毫不奇怪了。

如果说,还要什么别的原因的话,那就是:这也不仅仅是一个“编译到OS X”的简单工作,你需要雇佣专门的 OS X 开发者,且维护一个新的代码库。

这并不是说大公司抠门。比如 Sketch ,他们也一直没有开发 iOS 的版本,见 引用

We cannot port Sketch to the iPad if we have no reasonable expectation of earning back on our investment. Maintaining an application on two different platforms and provide one of them for a 10th of it’s value won’t work, and iPad volumes are low enough to disqualify the “make it up in volume” argument.

我们不会把 Sketch 移植到 iPad 上面,除非我们有合理期望去赢回我们的投资。去维护一个两个不同的平台,并在其中一个上面付出超过其价值10倍的投入是不值得的,而 iPad 上面的流量少到我们根本不必参与到“尽可能扩大用户”的争论里。

他们认为一个很有效的规避风险的办法就是从试用开始,而我认为还有一个选择就是使得支持 iPad 变成一件简单的事情。你也许会问,“为什么不呢?”

我就直说了:直接把 iOS 应用移植到 OS X 的体验是超级差的,你需要重新设计触摸屏的交互来适应键盘和鼠标的交互。当然也有一些例外,一部分领域的应用是不需要这么做的:假设你请 Pinterest 重新设计他们全是图的界面,他们只需要耸耸肩,然后把整个网站放在一个 webview 里就行了。

iOS 和 OS X 的不同之处

尽管 OS X 和 iOS 共享了相当一部分的底层接口,然而他们在 UI 层面是完全不同的。前者是建立在 Appkit 的基础上的,其历史可以追溯到 NeXT。而后者则采用了 UIKit,那是从 iPhone 的最底层开始写的。

二者甚至连坐标系统都是不一样的,在 OS X 上坐标点在左下方,而 iOS 上面则到了在左上方。

不仅是这样,UIKit 专门为 GPU 设计了渲染加速,每一个 UIView 都有一个核心的动画层(layer)作支持,与 GPU 一同提供了流畅的滑动体验。

但大概是为了支持比较早的版本,这层 layer 到了 Mac 上就变成非必须的了,甚至就算你启用了这个动画层,你也会感觉到他们也是建立在 NSView 上面的。

当然也存在一些重新实现 UIKit 的的库,比如 TwUI 和 Chameleon,后者意在寻求相同的 API。理论上,你可以在不同的平台上共享 100% 的 UI 代码。但实际上,这些框架是往往是费力不讨好的,因为他们都是第三方的。

即便是在 Mac 的开发者中,也有对 UIKit 架构的需求。去年,苹果官方的应用 Photos 就包含了UXKit,而游戏中心则采用了UICollectionView做替代。

我的期望

不要期望现在的 iOS 不经改变就可以运行在 macOS 上面。看看 tvOS 就知道了。

tvOS is derived from iOS but is a distinct OS, including some frameworks that are supported only on tvOS.

tvOS 是 iOS 的一个衍生版本,包含了很多只能在 tvOS 上使用的框架。

那上面也运行 UIKit,刚刚好能够 让你 重写一遍适合 TV 上的交互。

只用写一个包 (Bundle) 就可以了?

TV 上应用的交互方式和触摸屏上的方式差太多了,极有可能到最后,你会得到一个完全不同的设计。

When porting an existing project, you can include an additional target in your Xcode project to simplify sharing of resources, but you need to create new storyboards for tvOS. Likely, you will need to look at how users navigate through your app and adapt your app’s user interface to Apple TV.

当移植现有的项目的时候,你可以附加一个 target 在现有的 Xcode 项目里面共享资源。但是,你得专门为 tvOS 创建新的 storyboards。类似地,你还需要研究用户如何使用你的应用来调整你的应用界面来适应 Apple TV。

即便你可以把 tvOS 应用和 iOS 应用放在一个 Bundle 里面,缺点(eg. 过度耦合)也大过优点。我知道不少的 iOS 的开发者都后悔发布了 iPhone/iPad 上通用的应用,因为二者的联结太紧密。很多时候,倒不如把那些共享的代码放到一个框架(framework)里面。

鉴于此,如果想要在 iOS 和 Mac 之间移植,情况也是类似的。如果苹果能使 Mac 和 iOS 的用户体验更相似一些,你很可能可以把 Mac 和 iOS 应用放在同一个包里。

对于开发者而言,一个应用意味着一份 Bundle ID,这使得共享不同设备之间的信息变得更简单。这所有一切的目的,都是为了简化在新平台 (macOS) 上开发与iOS 应用相应的(桌面)应用的流程”

那需要下载的文件的大小呢?一边是运行在 x86上面的,另外一边是运行在 ARM 上的,所以需要把两个不同的架构编译到同一个二进制源码里面,类似于Mac 开始采用 intel 的时候的方案 fat binaries。不过,iOS9里,Apple 引进了App Thinning, 所以你只用下载你所需要的平台上的源代码就可以了。

界面惯例

在 iOS8里,苹果加上了“trait collection”和一些别的属性,允许你查看平台的细节。现在的Interface Idiom 属性包括了 iPhoneiPadTV, or CarPlay。你可以查看这些惯例,看那些视图是可用的,比方说 popover 就只在 iPad 上有。

理论上,你可以限制一些 Mac 的特性,使其符合 Mac 惯例,比如浮动调色盘。

沙箱

2011年苹果添加了 sandboxing 到 OS X 里。理论上,你“可以”通过这个功能移植 iOS 应用到 OS X上面。

解决更大的屏幕和页面

那坐标系统呢?—— 如果你使用自动布局,就不用担心了。别的情况,你可以用相对布局来取代那些写死的坐标,就好比是 CSS 一样,其实并不是很复杂。

下面的这个例子里,每一条蓝色的线都是一个规则,只要这些规则是有意义的,自动布局就会帮你处理剩下的问题。

再也没有(0,0)点了,你可以毫无顾忌的改变窗口的大小。

不幸的是,很多应用都写死了坐标值。除了 UIKIt 以外, Apple 都要抛弃掉坐标系统了。如果你把它和 Appkit 应用链接到一块的话,你就得到了已有的坐标系统,而指望在同一个应用里统一 Appkit 和 UIKit 的坐标系只会把一切弄得一团糟。

避免写出巨大尺寸的 iPhone 应用

那那些可憎的拉伸的 iPhone 应用呢?他们已经在用 Size Classes 来解决这个问题了,它鼓励你考虑屏幕资源来设计,而不是考虑硬件资源。它的每一个维度可以是“紧凑的”或是“普通的”。比方说,iPhone 的宽度是“紧凑的”,而全屏的 iPad 应用的宽度则是“普通的”。

比方说你正在使用 Facebook,你希望在屏幕的一边能够一直看到更新的话题,而你的屏幕上还空了一大块。你可以把它设定成“普通的”宽度。那为什么要这么大费周章,而不是简简单单的看一下这是不是一台iPad呢?这是因为只需要把应用从“普通的”宽度切换到“紧凑的”宽度,就可以让用户方便的开启多任务模式了。

Mac 也可以做类似的事情,当窗口小于一定阙值以后,就可以改变窗口的类型。

越早实现越好

这五年来,每一次 WWDC,我都在想,“是时候了。”,对于此,我的 Outlook(日程表)已经从“渴望的事情”到了“无可避免了”。

其实苹果公司比任何人都更渴望让 Sketch 这样的应用运行在 iOS 上面。比如说 iOS 上的 Lightroom , 它却不支持“RAW”格式,这对专业的摄影师来说 iPad “pro”就是个笑话。而对比微软的 Surface,上面则运行了真正的lightroom。

看起来,Apple 像是放弃了 OS X。他们没有雇佣更多的 AppKit 的开发者,而 Mac 的 App Store 多年来就是破烂不堪了。那么如果他们终于决定放弃旧的平台转而将所有的资源注入到一个(iOS与macOS)统一的平台上会产生怎样的效果呢?

这五年来,苹果改变很多,iOS 7 显示了他们愿意打破传统。Apple Watch 显示他们愿意承担风险。为什么不呢?他们在2010年就开始在 “Back to the mac” 上承担风险了。

他们说,在 WWDC2016 上 OS X 会被重命名为 macOS,今年会是时候了吧。

译注: “Back to the mac” 是苹果在2010年的一项活动,那次发布了Mac OS X Lion,并且介绍了苹果如何期望把 Mac 平台和 iOS 平台统一起来。本文在图片里的标题也是“Back to the mac”





原文发布时间为:2016年07月06日

本文来自云栖社区合作伙伴掘金,了解相关信息可以关注掘金网站。
目录
相关文章
|
2月前
|
iOS开发 开发者
苹果iOS App Store上架操作流程详解:从开发者账号到应用发布
很多开发者在开发完iOS APP、进行内测后,下一步就面临上架App Store,不过也有很多同学对APP上架App Store的流程不太了解,下面我们来说一下iOS APP上架App Store的具体流程,如有未涉及到的部分,大家可以及时咨询,共同探讨。
|
2月前
|
开发者 iOS开发
iOS应用上架详细图文教程(上)
App Store作为苹果官方的应用商店,审核严格周期长一直让用户头疼不已,很多app都“死”在了审核这一关,那我们就要放弃iOS用户了吗?当然不是!本期我们从iOS app上架流程开始梳理,详细了解下iOS app上架的那些事。
|
2月前
|
Swift iOS开发 开发者
iOS 应用上架流程详解
iOS 应用上架流程详解
|
2月前
|
Android开发 iOS开发 UED
appuploader   iOS 应用自动发布
appuploader   iOS 应用自动发布
|
3月前
|
存储 监控 iOS开发
iOS应用崩溃了,如何通过崩溃手机连接电脑查找日志方法
在iOS应用开发过程中,调试日志和奔溃日志是开发者必不可少的工具。当iOS手机崩溃时,我们可以连接电脑并使用Xcode Console等工具来查看日志。然而,这种方式可能不够方便,并且处理奔溃日志也相当繁琐。克魔助手的出现为开发者带来了极大的便利,本文将详细介绍其功能和使用方法。 克魔助手会提供两种日志,一种是实时的,一种的是崩溃的。(由于崩溃日志的环境很麻烦,目前只展示实时日志操作步骤)
|
3月前
|
存储 iOS开发
iOS 开发,如何进行应用的本地化(Localization)?
iOS 开发,如何进行应用的本地化(Localization)?
122 2
|
3月前
|
算法 iOS开发 UED
iOS如何进行应用的性能优化?
iOS如何进行应用的性能优化?
41 2
|
2月前
|
Linux 数据安全/隐私保护 iOS开发
如何使用 Xcode 打包导出 IPA 文件并进行 iOS 应用内测,无需支付苹果开发者账号费用?
如何使用 Xcode 打包导出 IPA 文件并进行 iOS 应用内测,无需支付苹果开发者账号费用?
|
3天前
|
存储 编解码 JSON
利用SwiftUI构建高效iOS天气应用
【4月更文挑战第21天】 在本文中,我们将深入探讨如何运用SwiftUI框架打造一个响应迅速且用户友好的iOS天气应用程序。我们将重点放在利用SwiftUI的声明式语法简化界面开发,并通过结合Core Location和Networking APIs实现实时天气数据的获取与展示。文章将详细阐述整个开发过程,包括API集成、数据模型设计、用户界面布局以及动态适配不同屏幕尺寸的策略。
|
1月前
|
安全 数据安全/隐私保护 虚拟化
iOS应用加固方案解析:ipa加固安全技术全面评测
iOS应用加固方案解析:ipa加固安全技术全面评测
37 3