Archive for December 20, 2017

Wednesday, December 20, 2017

Apple Rumored to Combine iPhone, iPad, and Mac Apps to Create One User Experience

Mark Gurman (Hacker News, MacRumors):

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. That’s a lot more work. What’s more, Apple customers have long complained that some Mac apps get short shrift. 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 substandard. With a single app for all machines, Mac, iPad and iPhone users will get new features and updates at the same time.

Apple currently plans to begin rolling out the change as part of next fall’s major iOS and macOS updates, said the people, who requested anonymity to discuss an internal matter. The secret project, codenamed “Marzipan,” is one of the tentpole additions for next year’s Apple software road map.

This has long seemed like an obvious thing for Apple to do, but I’m not sure it’s good for the Mac platform. The 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 one. The downside is that I don’t want to be using lowest common denominator iOS ports. I like using a Mac because of the apps that really take advantage of what the desktop has to offer. I’m continually annoyed by the apps that essentially put an iOS-style interface in a window and don’t support standard Mac conventions or features. I 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 bugs. Having two classes of Mac apps would not be good, but AppKit going the way of Carbon would be even worse.

Steve Troughton-Smith:

macOS 10.14 Toasterfridge

To quote from my piece, with a unified app platform between iOS and macOS, iPad apps would have a migration path to the desktop, and legacy desktop apps to iPad — both platforms could evolve & grow as one, and not one at the expense of the other.

Opening the macOS floodgates to iOS developers is going to be a huge shot in the arm (unintentional pun); it could make a big difference to Apple’s inability to give macOS the development attention iOS gets. We know they need this! Photos on the Mac is a UIKit port using UXKit!

Marco Arment:

If there’s any truth to this, it’s going to make a lot of Mac developers pretty mad (and depends a lot on implementation details), but I’m definitely in favor of it and pretty excited for the potential.

Mike Rundle:

Whoa. Looks like “native Mac apps” that are thin wrappers around websites will be dying soon if we can just run the iOS version native on our Macs. Huge ramifications for this.

Jeff Johnson:

Developers say, “Yay, now we get Mac for free!” But the reality is customers are saying the exact same thing.

Update (2017-12-20): Michael Love:

Also, the release of this story compels Apple to either a) unequivocally deny it or b) work like hell to get it ready for next summer; who’s going to invest any more time in a Mac app with this waiting in the wings?

Heck, it even makes me a bit reluctant to buy macOS software with it unclear whether that will be abandoned + replaced by iOS ports under this new regime.

Paul Thurrott:

Today, Apple invented UWP apps. Psyched!

Jeff Johnson:

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

Alasdair Allan:

I do worry that in the transition to ‘universal’ apps we’ll loose functionality that currently exists on the Mac side. The infamous example of Apple’s own Keynote app, where the Mac app lost a bunch of functionality to harmonise it with the iOS version, seems like a warning shot.

Jeff Johnson:

The irony is that Mac sales are as high as ever, despite lagging hardware updates. People like the Mac and are buying Macs. It’s not in any sense an endangered or dying platform. It’s wildly successful.

The Mac App Store is suffering, yes. The best Mac apps have left the store, or were never in the store in the first place. That’s a problem with the store, not a problem with the Mac.

Max Seelemann:

I fear radical degradation of macOS’ usability. But maybe also a chance to kill f***ing Electron apps.

Update (2017-12-22): Gus Mueller:

There’s an easy solution for updating the Mac version of Twitter to have the same features as its iOS peers. Twitter has to care enough to update it. That’s it. It’s not as if there needs to be massive engineering efforts put behind it. It’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 it. Tweetie for the Mac, which Twitter for the Mac is based on, was built from the ground up by a single person. All Twitter had to to was maintain it. And Twitter, Inc. couldn’t be bothered.

And we see the same behavior from other vendors happening on the iPad where a shared framework already exists (Instagram being the prime example).

Craig Hockenberry:

What if this is all about getting iPhone-only apps to run at iPad (and, by the way, Mac) screen sizes?

The technology to create Universal apps has been around for many years now, yet there’s still a surprising lack of adoption.

You can literally flip a switch and make it “work”.

It’s a lot of work to make your app design & layout work on a wide variety of screen sizes. Adding macOS to this situation isn’t going to make less work.

I speak with a bit of experience here: we built a macOS app with a UIKit framework developed by @BigZaphod.

Even with familiar classes and frameworks, it wasn’t easy to make a macOS app from an iOS source base.

Our second attempt, which used separate UI presentation layers for macOS and iOS, but with and a common data model, was actually simpler to implement and resulted in a better app.

Brian Webster:

I could imagine a system that might work somewhat like the Carbon/Cocoa integration that Apple provided in the early OS X days, where you could do things like embed a Carbon view in a Cocoa view, mix Carbon and Cocoa windows in the same app, and so forth. There would still be some work to do for iOS devs to make their apps work well on the Mac, but I think this might be a good middle ground similar to Carbon, where 80% of the work is already done for you, and you’d just need to handle the extra hooks in order to have your iOS components behave inside a Mac environment.

Colin Cornaby:

What if it’s not a layer on top of AppKit and UIKit, but a layer underneath?

Classes like NSImage and UIImage could be refactored to have a common ancestor, maybe just named Image. When you create an Image you get the platform specific version under the hood, but you can ignore that and work with Image’s shared cross platform functions. When you need something only currently available on the Mac, like image representations, you just downcast your image to an NSImage, and you have all your AppKit functionality back.

Pierre Lebeaupin:

[The] Bloomberg article completely downplays the prerequisites, on the desktop side, of an unified OS.

Rui Carmo:

Even though this makes sense, I have [a] strong feeling it will result in the dumbing down of the macOS user experience to a degree where it will be untenable to use for serious purposes.

Stephen Hackett:

It may look like this is the downfall of the Mac as a platform, but in reality, this may be a life raft into the modern era. It’ll take years to discover which is true, but if it means a Mac ecosystem with more options when it comes to good apps, that’s a win.

Riccardo Mori:

So, Apple keeps stressing the user interface differences between Mac OS and iOS hardware, and the next step could be ‘universal’ apps!? You can see this is a bad idea from miles away. The last thing Mac OS needs are dumbed-down iOS-ported apps.

Daniel Rubino:

Microsoft’s UWP will be hitting the three-year mark in late 2018, right around when Apple’s first attempt at app unification may debut.


These tools combined make Windows 10 an OS that can live anywhere, on any device, with any screen size, running any processor. With UWP, the apps can run on all those devices with only minor changes. […] Apple has some of this with shared components between iOS and macOS, but its app story is very far behind. Apple has not – to our knowledge – taken any steps to unify its UI across macOS and iOS.

See also: Under the Radar, Matt Birchler, Ben Lovejoy, Dave Verwer.

Update (2017-12-23): John Gruber (tweet):

“One user experience” is neither possible nor desirable. The truth is that this effort by Apple is almost certainly not about cross-platform applications but instead cross-platform frameworks for developers. It’s developer news, not user news.


There is a lot of work involved getting an iPhone app to work well on an iPad. That’s why you still see iPhone-only apps. Even with good new cross-platform Mac/iOS frameworks, there would be way more work involved to bring an iPhone app to Mac than there is to bring to iPad.


Caring is ultimately what makes true Mac apps Mac apps. Caring about the details, caring about the Mac way of doing things. No amount of shared frameworks between MacOS and iOS can make iOS developers care about doing things properly on the Mac.


My concern with this whole situation is that even if this is all true — if Apple is indeed working on creating cross-platform UIKit-like frameworks for iOS and MacOS, and that the existence of such frameworks would spur more developers and companies to create Mac apps — it wouldn’t to the creation of good Mac apps.

Even Apple, much to my concern, has fallen short in this regard. Photos for Mac is one of the worst Mac apps I use. […] It’s as though Photos for Mac was created by iOS developers who saw a Mac one time and said, “Sure, we can do that.”

I take the details of the Marzipan story with a grain of salt, considering that Gurman also told us that Swift would be ABI stable for version 2.

Update (2017-12-28): See also: Accidental Tech Podcast on some of the problems with Photos, which is probably the best of Apple’s ported iOS apps.

Daniel Rubino:

UWP is not a "write once, deploy everywhere" model, though in some ways it can be used as such. Nor is it only about phones, which apparently are on the sideline now for Microsoft. UWP is about building a next-generation app platform that can quickly adapt to new hardware paradigms, whether it is Windows Mixed Reality, traditional PCs, tablets, mobile devices, or your living room.

Joe Cieplinski:

No doubt about it. Thousands of previously iOS-only apps will end up on the Mac barely altered with bad UI on day one. […] Here’s the thing: People who care about good software will find the good stuff. People who care to make good software will make the good stuff. There aren’t many people in either group. And there never will be.


There are some apps, however, built with universal storyboards that take full advantage of iPad. The problem here isn’t the tool, but rather the people using the tool. The same will be true for Marzipan apps.


I suspect more developers will go the non-universal route this time around. And given this is not a simple matter of screen size, as it was on the iPad, a port of an iOS app to the Mac, even using Marzipan, is going to take quite a bit of time. It will be a while, in other words, before the pressure from other developers gets extreme to start selling your existing app as universal.


It stands to reason that after Marzipan gets released into the wild, both UIKit and AppKit will be on “borrowed time.” Just as Cocoa replaced Carbon, eventually Apple will very likely want all apps to be written using Marzipan.


If Apple only has to maintain one framework for adding new features to iOS and macOS, it’s less likely to leave the Mac out of new APIs. That means no longer waiting a year or more to get the same interesting cool new features we see on iOS.

See also: Accidental Tech Podcast.

Update (2018-01-01): Todd Ditchendorf:

Languages: same (Swift/ObjC)
IDE: same (Xcode)
Standard lib: same (Foundation)
User Interface lib: extremely similar (UIKit vs AppKit)

It’s not clear to me that a write-once-run-anywhere toolkit across iOS (touch) & Mac (WIMP) more unified than this is actually desirable.

Google Maps’s Moat

Justin O’Beirne (via Paul Rosania, Hacker News, Reddit):

Similar to what we saw earlier this year at Patricia’s Green in San Francisco, Apple’s parks are missing their green shapes. But perhaps the biggest difference is the building footprints: Google seems to have them all, while Apple doesn’t have any.


But what’s most interesting is how fast Google is making these buildings.

Just two years after it started adding them, Google already had the majority of buildings in the U.S. And now after five years, it has my rural hometown—an area it still hasn’t Street View’d (after 10+ years of Street View).


And this building-generation process seems automated to such a degree that buildings sometimes appear on Google’s map before roads do[…]


So Google seems to be creating [shared Areas of Interest] out of its building and place data. But what’s most interesting is that Google’s building and place data are themselves extracted from other Google Maps features.


The challenge for Apple is that AOIs aren’t collected—they’re created. And Apple appears to be missing the ingredients to create AOIs at the same quality, coverage, and scale as Google.

Explanation of HomeKit Vulnerability

Khaos Tian (tweet):

HomeKit didn’t check the sender of remote message before processing the request, which ended up allowing potentially anyone to remotely control HomeKit accessories in the home.


Of all the messages you can send to HomeKit daemon, there are some really interesting ones. There is one message that will let HomeKit on watchOS to reply with a list of home identifiers, along with the public and private key that used to encrypt home data and communicate with accessories to the sender. Once an attacker got the reply, it’s game over for HomeKit. With pairing identity and private key, the attacker can trick HomeKit into thinking him as the owner of the home, even after Apple fixed the messaging issue.


Those message mishandling issues were discovered back in late October, and was disclosed to Apple’s product security team the next day I found it (Oct 28). I got ONE email (on October 30) from Apple’s product security team saying they are investigating it through the entire November. During that time, I sent multiple emails (Oct 31, Nov 2, and Nov 16. Additionally there was one sent to Federighi on Nov 27.) to try to ensure the engineering team understood the issue but no reply at all. I observed that Apple deployed the watchOS server fix so I assumed they just being typical Apple not replying people (hello radar 🙃), so I thought the engineering team should have sufficient understanding of the issue and hoped they properly fixed the issue with iOS 11.2. But then iOS 11.2 officially released, while they did fix some issues in my report, they didn’t do a full security audit to ensure all messages are being handled properly, and instead they introduced a new message which makes the whole attack a lot easier 🤦.


So I ended up reaching out to friend at 9to5mac and turned out Apple PR channel is much more responsive than product security, from them reaching out Apple PR to Apple come up with a temporary fix all happened with 48 hours. No wonder nowadays people just throw security issues on Twitter right? What a world we live in.

Khaos Tian:

They declined my request to get an invitation to join their bounty program since they think me involving the press to have them fix the issue voided the qualification for the invitation ¯\_(ツ)_/¯ We’ll see how it goes.

Previously: HomeKit Vulnerability Allowed Remote Access to Smart Accessories Including Locks.

Patterns for Working With Associated Types

Benedikt Terhechte:

The first solution for the archetypical problem is also a really simple one. Instead of enforcing Equatable on your custom protocol, you can simply require your full fledged, final, types to conform to the Equatable protocol instead of your custom protocol.


As you can see in the example above, using Self as a method parameter or using Self as a property type automatically introduces an associated type (like we saw with Equatable, earlier).

The most helpful note here is that once you use a method instead of a property in order to return something of type Self you will not opt in to an associated type[…]


The idea here is that you define two protocols that share common methods. Only one of those protocols contains associated types, the other does not. Your types conform to both protocols. This means that you can use the normal protocol as a type for all situations. If you, then, need to use the parts of the type that only affect the associated type, you can do so by means of a runtime cast.

Apple, CALEA, and Law Enforcement

Matthew Green:

Nick contends this is a serious weakness in iMessage; I agree. This problem can arise in iMessage because of the way the iMessage protocol has been set up. Neither the sender nor the receiver has a way of knowing if any others are in the communications path because Apple provides no way for Alice or Bob to check. Other end-to-end encrypted systems have been designed to prevent this problem. WhatsApp or Signal, for example, both provide users a way to check if there is a man in the middle (see here and here respectively). This is a security weakness of the iMessage protocol and should be fixed.


There’s another way that Alice and Bob’s encrypted communication can be eavesdropped upon. Because iMessage allows multiple devices on a single account, Apple could add the FBI as a second “virtual device” to Bob’s account.


If Apple was to change its technology to be able to surreptitiously add a device to the account—that’s the way the wiretapping would work—it would have to deactivate the warning system. (Otherwise the bad guy would know he’s being tapped.)

The real question is not whether Apple can do this. (The answer is yes.) The real answer is whether Apple can do this in a way that doesn’t disrupt the system for everyone else and destroy their security. That’s far from clear.