火星锅

Mark Gurman本周在Bloomberg有一个有趣的故事,但问题始于标题本身:“Apple计划结合iPhone,iPad和Mac应用程序来创建一个用户体验”。

Gurman可能没有写出标题,但它甚至没有意义iOS没有鼠标光标的概念,只能在触摸屏设备上运行MacOS不支持触摸屏设备,需要鼠标指针“一种用户体验”既不可能也不可取事实上,Apple的这种努力几乎肯定不是跨平台的应用而是跨平台构架对于开发人员这是开发者新闻,而不是用户新闻。

GURMAN:

Starting as early as next year, software developers will be able to design a single application that works with a touchscreen or mouse and trackpad depending on whether it’s running on the iPhone and iPad operating system or on Mac hardware, according to people familiar with the matter.

Developers currently must design two different apps — one for iOS, the operating system of Apple’s mobile devices, and one for macOS, the system that runs Macs这是更多的工作What’s more, Apple customers have long complained that some Mac apps get short shrift[...]

Apple is developing the strategy as part of the next major iOS and macOS updates, said the people, who requested anonymity to discuss an internal matterCodenamed “Marzipan,” the secret project is planned as a multiyear effort that will start rolling out as early as next year and may be announced at the company’s annual developers conference in the summer.

Gus Mueller,优秀的设计师和开发人员橡子,写道Gurman报告中的一篇优秀文章

I feel like this article from Gurman could have been reduced down to: “We think Apple might some day have a shared UI framework for iOS and MacOSApple could even create some sort of cross store bundling or a single store with a single binary for all platforms when using this framework (even though there’s nothing stopping Apple from doing this today)That sounds neat and wouldn’t it be cool if all platforms also used the same processor to boot? This may or may not happen starting next year, and it could very likely be canceled as wellApple declined to comment on our sensational story.”

What about the crux of the article, that Apple is working on a shared UI framework between iOS and MacOS? I wouldn’t find it surprisingI could also see it being written completely in Swift (though personally I’d rather it be in Obj-C for maximum interop with existing frameworks).

But history is filled with cross platform UIs and write-once run-anywhere dreams他们都没有变得异常伟大。

我对Mueller的唯一狡辩是“其中没有一个变得非常棒”对于一次写入/随处运行的应用程序框架的描述过于慷慨他们中的大多数是可怕; none of them are good或者至少没有一个是好的,从真正原生的Mac和iOS应用程序的好处来看 - 这不是每个人的观点,但肯定是Apple的。

要让iPhone应用程序在iPad上运行良好,需要做很多工作这就是为什么你仍然会看到仅限iPhone的应用程序即使有良好的新跨平台Mac / iOS框架,也会有办法将iPhone应用程序带到Mac的工作量要比带到iPad的工作要多今天的工作量将比现在少,但仍远远超过支持iPad。

在较高的层次上,本机Mac应用程序的用户界面是使用名为AppKit的框架编写的。AppKit在20世纪80年代后期追溯到NeXTStep今天AppKit的NeXTStep根源仍然如此普遍,开发人员在为Mac编写Cocoa应用程序时使用的类名仍然以“NS”为前缀。

当Apple创建iOS而不是移植AppKit时,他们有效地点击了重置按钮并创建了一套名为UIKit的全新框架。AppKit适用于Mac,UIKit适用于iOS(现在是tvOS)UIKit是一个新的开始 - 简而言之,是一种“if we could do it all over again, what would we do differently?“接受AppKit结果得益于数十年的经验教训和不必要的行李丢失。

仅列出AppKit所具有的众多差异之一NSColor,UIKIt有的UIColorNSColor和UIColor具有相同的用途,但它们并不相同在平台上指定整个用户界面永远不会像Mac和iPhone那样根本不同指定颜色之类的东西可能是。

我从来没有见过有人争论将AppKit带到iOS自从iPhone的第一个SDK出现以来,已经有很多电话要求将UIKit带到Mac上Guilherme Rambo去年写了这样一篇文章,“UXKit和为什么'UIKit for macOS'很重要“:

The painfulness of working with AppKit is killing the Mac platformThere are some really awesome iOS apps out there which would benefit a lot from a macOS counterpart, but their developers simply can’t cope with the burden of developing for both, so they choose the one that’s most popular (hint: it is not macOS). Instead, people are making crappy web-based apps, shoving them on a .app with hundreds of megabytes and calling them “macOS apps”.

I didn’t believe it would be possible to have a single UI framework for iOS and macOS, but I changed my mind when I saw how UIKit works on tvOSThink about it: it’s the same framework, but with a different visual language and functionality added/removed based on the needs of the platform:

  • UIKit on tvOS has facilities to work with the remote control, controlling focus and the parallax effect that is ubiquitous on the platform.

  • UIKit on iOS has touch input, gesture recognizers, toolbars and navigation bars

  • UIKit on macOS would have window controllers, contextual menus and statusbar items

今天任何事情都在“杀死Mac平台”,这有点夸张。Mac正蓬勃发展但毫无疑问,维护并行iOS和Mac应用程序的工作要比现在更多对于许多公司来说,本机Mac应用程序的优先级低于本机iOS应用程序也是如此。1

Gurman引用Twitter作为一个例子

For example, while the iPhone and iPad Twitter app is regularly updated with the social network’s latest features, the Mac version hasn’t been refreshed recently and is widely considered substandardWith a single app for all machines, Mac, iPad and iPhone users will get new features and updates at the same time.

最后一句中的“意志”是天真的如果Twitter可以以某种方式从他们的iOS应用程序生成“Mac应用程序”而不需要任何努力,那将是一个糟糕的Mac应用程序没有人想在他们的Mac上的窗口中运行iOS应用程序充其量,维护Mac应用程序所需的工作量比现在要少 - 但不能保证Twitter能够做到这一点,无论它比今天容易多少。

Gus Mueller

There’s an easy solution for updating the Mac version of Twitter to have the same features as its iOS peersTwitter has to care enough to update it而已It’s not as if there needs to be massive engineering efforts put behind itIt’s not as if the road hasn’t already been explored and the server APIs already exposed (which they must have done for the iOS version)They just need to put some effort and care to itTweetie for the Mac, which Twitter for the Mac is based on, was built from the ground up by a single person所有Twitter都必须维护它And Twitter, Inc. couldn’t be bothered.

关怀最终是什么使真正的Mac应用程序Mac应用程序关心细节,关心Mac的做事方式MacOS和iOS之间没有任何共享框架可以让iOS开发人员关心在Mac上正常运行。

Apple的Mac Photos应用程序主要使用名为UXKit的私有框架实现,该框架在很多方面都是UIKit for Mac对UXKit感到好奇,Rambo想出了如何使用它创建应用程序

但最有趣的是UX-prefixed类Most of them are implementations of UIKit controls on top of AppKit. There’s UXLabel, UXCollectionView, UXNavigationController, UXViewController and much moreTo see for myself whether I was right, I decided to try and build a really simple app using UXKit.代码可以在我的Github上找到This app lets the user search for photos on Flickr and select them to see a bigger version, really simple.

While working on the app I noticed that it felt like I was working on an iOS app[...]

I think a developer who is familiar with UIKit would have no problem making macOS apps using UXKitFrom what I know, the only apps that use UXKit currently are the macOS Photos app and the Pricing app (the one used at Apple Stores).

我对整个情况的关注是,即使这一切都是真的 - 如果Apple确实在为iOS和MacOS创建类似UIKit的跨平台框架,这些框架的存在会刺激更多的开发人员和公司创建Mac应用程序 - 它不会不可避免地导致创建Mac应用。

就我而言,即便是苹果公司在这方面也做得不够适用于Mac的照片是我使用过的最糟糕的Mac应用之一我喜欢iCloud Photo Library同步在我的所有设备之间同步拥有数千个(实际上是数万个)照片和视频,知道它们都在Apple的服务器上备份,这是一次很棒的体验在充当照片和视频的存储库方面,适用于Mac的照片效果很好。

但就像一个好的Mac应用程序而言,它没有甚至像Mac一样简单而基本的东西就像拖放一样在照片中被搞砸了当您将图像拖出图片时,您几乎必须首先放入Finder,然后在将新文件复制到Finder之后开始新的拖动,然后才能将其放入许多上下文中开发人员Ilja A.我最近抱怨这个

For almost a year now you cannot drag images from Photos to Safari, and in extension every other macOS application that uses WebViews, like our own GarageSale and many other 3rd party apps that work with images.

Imagine that: The default image handling app on the Mac platform cannot communicate via drag & drop with the default browserAnd that’s been going on for almost a year nowOn the desktop platform that used to excel in drag and drop!

Not a day goes by without frustrated users in asking our support team why GarageSale cannot receive drags from Photos.

当主照片窗口在后台时,尝试将图像拖出照片它不起作用您需要先激活窗口,然后拖动Any other file manager-type app on the Mac allows drags to be initiated from background windows.2 3

现在试试这个:双击并按住照片中的图像,然后拖动(也就是说,双击图像但在第二次点击时不要放开按钮。)在适用于Mac的照片中,这会启动拖动那太疯狂了双击,按住和拖动是如何在列表中创建多个项目的选定范围 - 双击的项目是选择中的第一个项目,您拖动的项目将添加到选择中在非列表视图中(如Finder中的图标视图),双击并拖动不执行任何操作。

除了非标准之外,当您只想打开图像时,这种特殊行为可能会妨碍,因为适用于Mac的照片不允许滞后双击期间指针移动大多数Mac用户都不会注意到这一点,但是当您双击Mac上的某些内容时,鼠标指针可以在第一次和第二次单击之间轻微移动使用触控板时,这种轻微的移动尤为常见,但也可能会出现鼠标您没有注意到,因为结果始终是您的意图在没有滞后的Windows早期版本中,双击感觉很脆弱,即使不是不可靠,因为第一次和第二次点击之间的轻微鼠标移动会导致双击尝试无效因此,使用适用于Mac的照片 - 尝试双击照片中的图像但无意中在点击之间移动鼠标指针,您最终开始拖动而不是打开图像如果你在尝试在照片中打开图像时感到笨拙,那不是你的错 - 这是Apple的。

并且不要让我开始使用Photos中的一些键盘快捷键要从详细视图中打开的图像返回到缩略图列表,Esc(Escape)键不起作用 - 您必须使用空格键这个的捷径也可能是Esc-发誓- 空间吧,因为即使几年后,我也不能习惯它。

这就像是适用于Mac的照片是由iOS开发人员创建的,他们曾经看过Mac,并说:“当然,我们可以做到这一点。”

再次,我使用照片 - 但只是尽管它的Mac界面很糟糕对于这样的论点,照片是一个糟糕的海报孩子,因为Apple应该让只有iOS经验的开发人员更容易创建Mac应用程序。

长期的Mac开发人员Michael Tsai(作者)EagleFilerSpamSieve有类似的担忧

This has long seemed like an obvious thing for Apple to do, but I’m not sure it’s good for the Mac platformThe upside is that we’ll get lots of ports of iOS apps where previously there was no Mac app or only a poor quality Web-based oneThe downside is that I don’t want to be using lowest common denominator iOS portsI like using a Mac because of the apps that really take advantage of what the desktop has to offerI’m continually annoyed by the apps that essentially put an iOS-style interface in a window and don’t support standard Mac conventions or featuresI also worry that bifurcating the platform with UXKit and AppKit apps will inevitably mean that Apple will focus less on enhancing AppKit, while at the same time doubling the surface area for bugsHaving two classes of Mac apps would not be good, but AppKit going the way of Carbon would be even worse.

Jeff Johnson, on Twitter

There seems to be a big cultural divide between iOS developers who came from the Mac and iOS developers who didn’tMany in the latter group are OK with destroying the Mac, and that’s very frustrating to me.

还有约翰逊(这条推文是好线程的开头):

Something that crystalized for me yesterday is how afraid many UIKit developers are of AppKitWhich is unfortunate, because the similarities vastly outnumber the differences.

简而言之,Apple的目标应该是让开发人员更容易创建出色的Mac应用程序,并且Mac和iOS应用程序兄弟姐妹更容易共享代码Apple的目标不应该是让iOS应用程序以稍微修改的形式在Mac上运行变得更容易我认为认为Apple正致力于单一的统一操作系统是荒谬的在这方面希望的最好理由是最近加倍Apple在专业Mac硬件上的努力iMac Pro不是为运行iPhone应用而设计的。4


  1. 许多公司的优先顺序是(1)原生移动应用程序,(2)网站,(3)原生桌面应用程序优先级(1)和(2)有时会被翻转,但原生桌面应用程序通常排在第三位其中一个原因是 - 作为一般规则 - 只有Mac用户关心本机桌面应用程序,甚至只有一些Mac用户So for most companies and services, they never even get around to a native Mac app, because the website running in a desktop browser tab is “good enough”我可能列出几十个 - 也许几百个 - 的例子,但是在我的头脑中,想想OpenTable和Yelp等服务原生移动应用程序,桌面网站Facebook全面关注移动应用,但我敢打赌,他们甚至都没有考虑为Facebook或Instagram构建原生Mac应用程序。

    然后是推特当Twitter获得了Loren Brichter的Tweetie,他们不仅拥有我认为最好的原生Mac Twitter客户端,而且最好的和最具前瞻性的Mac应用程序之一,期间首先,他们让它萎靡不振他们用一个没有Tweetie的魅力或吸引力的彻底改写取而代之,现在它已经到了今天令人惊讶的地步,他们甚至保留了他们的官方Mac客户端Clearly they think Mac users should use their website. ↩︎︎

  2. 好吧,iTunes似乎没有但过去常常And if you’re taking your UI cues from iTunes, you’ve got bigger problems. ↩︎

  3. It’s also worth pointing out that iPhoto, which Photos effectively replaced on the Mac, also did some really weird shit with double-clicking (iPhoto would open an image on a double-click’s second mousedown event, rather than waiting for the second mouseup — gross), drag-and-drop (you couldn’t drag from iPhoto when it was in the background, and keyboard shortcuts (same thing as Photos, where space bar, rather than Esc, is the shortcut for going back from an image’s detail view to the list of thumbnails)So it’s quite possible that some of my complaints about the non-idiomatic Mac-like-ness of Photos for Mac are not the result of it being made by iOS developers unfamiliar with the Mac, but because they copied bad ideas from iPhoto. ↩︎︎

  4. Well, except for running them in the iOS Simulator, which it does with aplomb. ↩︎︎