iOS Apps on macOS, part 2

It’s still coming. What does it look like?

Mark Gurman’s new peice in Bloomberg about iOS apps running on macOS is bringing back all the logistical speculation about how the hell this is going to be positioned by The Fruit Company.

App Developers’ first concern is, of course, the app economy. Will they be able to double sales by offering a macOS version? Is it worth it to put in the effort to create a macOS version if people don’t use the macOS App Store?

People are making this calculation already with UIKit/AppKit. You can share some amount of code between codebases currently but there are fundamentally different ways to structure your app that you have to think about, it’s not trivial to understand how to work with both.

Real UIKit compatibility on macOS would swing this cost/value calculation significantly to the benefit of listing your app on Yet Another Platform and certainly get more apps listed on a macOS App Store. The assumption here is that for most folks keeping up-to-date on the latest iOS APIs, your app can be listed on the macOS App Store after you’ve recompiled it with a new version of Xcode.

Of course developers will approach it from a literal cost perspective as well, knowing that Apple wants you to offer iOS / macOS / tvOS apps in one bundle:

But that’s sidestepped by the large amount of work Apple has been putting into subscription types and options on the App Store in just the last few months. If you can get $5 a month from users rather than $10 once, that’s a big incentive to hire some extra help to maintain another version of your app, especially if the unique platform cost is relatively low.

The real question is whether Apple can design a system where that’s a good user experience on the mac. There’s some mention of touch/tap controls being similar across the two platforms, but this hasn’t exactly been a limitation in the past. Apple laptops have had large, multitouch trackpads for years and the option for the same large format, quality multitouch trackpads on desktop Macs as well.

Hardware

I know jack shit about how hardware gets made so get ready for some baseless speculation on what could happen here (i.e. the vast majority of Apple journalism).

One other component that is relatively new here is that new Macs could contain an Apple-designed ARM A-series processor to run these iOS apps. Developer-wise, it would sidestep the requirement that apps be recompiled before they work on the mac — as far as I understand, your current bitcode works well between ARM variants but would have to be recompiled for amd64.

But that doesn’t make a lot of sense as a requirement for iOS-on-macOS. The iMac Pro just shipped sans any general purpose ARM processor and it squarely targets developers who need beefy machines for multi-core Swift name demangling.

What could happen, however, is that a new Macbook One gets shipped with just a single Apple A12 chip and is designed for folks who have light processing use cases, i.e. people who would love running a bunch of single-purpose iOS apps on a Macbook. Want great battery life? Just run the iOS apps.

The obvious question then would be: why have both? These two machines are essentially the same: