, 31 tweets, 6 min read Read on Twitter
1/ Mac/OSX on ARM: What might it mean? What are the options? Is this really that complicated?

I have thoughts :-)

tl;dr IMHO, end to end, this is a lot more difficult than many seem to be saying.
2/ Obvious answer, and one that seems to be most often touted, is porting OS X to ARM gives Apple a best of both worlds product: power of “professional” Mac + app ecosystem of iOS (ARM). Why not!?!

In tech, almost nothing claimed best of both worlds is. (eg Android on ChromeOS)
3/ Primary issue in thinking this way is to think of the worlds being combined using their current expressions of features/benefits.

This fails to ask both “what problem is being solved” (design, product manager) and what constraints get added in the process (engineering).
4/ Dive in and consider 5 approaches, named as follows:
• Extreme Port
• Middle Weird
• Middle Frustrating
• Middle Crazy
• Extreme New

Each has pros/cons. Many will try to find a middle between any two—that’s the nature of lists of options. Building such is hard.
5/ Extreme Port. OS X is literally ported to ARM hardware. For olds, this is the 68K->PPC->IA transition all over again.

Straight-forward. This simply let’s Apple be totally integrated. ISVs simply recompile and module IA oddities things work.
6/ What is the value prop? Mostly, we find out which ISVs are willing to even do a “recompile” for that random utility downloaded years ago—fewer of those than one might think. Touch doesn’t happen this way, if you’re wondering. Virtualization doesn’t work. Legacy mulation? 🤔
7/ Here you don’t get any of the benefits associated with ARM devices like extreme battery life, cost, touch,…

IA OS X has many positive attributes generic Windows PC lacked (standby, quality over time, instant on, gfx) so ARM offers _little_ in that regard. Pretty 🔑 point.
8/ Middle Weird. Port while introducing a new library, call it Marzipan, that works on iOS as well—today a subset of AppKit & UIKit. Apps have a new look, new controls/metaphors. Primary design is to adjust to either touch or mouse w/o ISV effort.
9/ There is some appearance of developer strategy and value prop. But what do consumers get? None of the benefits of iOS+ARM and new type of weird app.

Apple can do a great “x-platform” library, but still just that. Unless Apple says “this is the future for all ISVs”.
10/ This new library must carry a lot of weight and have a really big value prop—it has to get phone developers focused on using it.

Here, unlike Windows, iOS is super healthy ecosystem that one does not want to “break”, “fragment”. Windows had flatlined years earlier, OSX too.
11/ Plus as with Extreme, once code is downloaded and run (even with 🔐 such as defaults on OS X today) the platform will still have a level of risk/fragility that can’t be overcome simply because you can always add evil “kernel mode” code to devices.
12/ Middle Frustrating. Port but now only run apps certified in a new store. Up til this option, an escape valve existed for techies to put any code on the device they wanted.

Now could this store be only Marzipan apps or would it allow some OS X apps? Doesn’t matter, really.
13/ It is so close but so far for techies—frustrating. Almost like it has a consumer value prop, but it would mostly just be annoying. You’d find out nothing you (techie) needs will be in the store—Chrome?. It likely won’t signal “use Marzipan” so there won’t be new, or old apps.
14/ Middle Crazy. Middle of the road approach is to port OS X but now make big enhancements, in particular add touch support. BUT this doesn’t support just magically make touch work in existing apps only in new Marzipan apps. Crazy you say?
15/ Many will say I am wrong but touch just doesn’t work on legacy apps except for some browsing (tapping links) or occasionally moving a file.

This is what we learned in w/touch on Windows 7 and why touch on desktop is more myth than reality. (come @ me w/anecdotes)
16/ Real issue w/ adding touch is how costly it is to the OS— massive work to define a touch interaction model. That’s why you want touch only for new apps designed for touch—you can’t shoehorn touch into apps that didn’t know touch existed. Touch *isn’t* a mouse, nor vice versa.
17/ Even if you define that model (which is a new API), then you need ISVs to update apps. The Mac ecosystem is like the Win32 ecosystem—just isn’t a a lot of active development, especially big commercial apps people care about as creatives (for example). Opportunity cost is big.
18/ BUT all along what people *value* on a Mac is doing all their existing “pro” work (and apps like Chrome) w/desktop metaphor and mouse. That audience is 300M worldwide including Windows PCs. It isn’t growing (except population sort of). This option requires a new desktop.
19/ You can even start to ask if this option introduces some ability to run iOS apps unchanged (tons of h/w issues: sensors, screen size, etc.)

After all—the one thing everyone wants is to use Instagram on their Macs. Many say this comes for “free” moving to ARM. It doesn’t.
20/ BUT this option is getting closer to a future where there is a new value proposition. The Mac starts to evolve to have a new value proposition where it runs a new type of app and has touch, but is a “laptop” form factor that has synergy with your phone. That leads to…
21/ Extreme New. Port OS X to ARM but run new Marzipan apps and new iOS apps. Wait, this is just iOS...see what I did there!!

Originally iOS was OS X “ported” to ARM with a ton of code #ifdefed out. It seems we’re back where we started from.

That’s how these discussion go.
22/ People want to run iOS apps but they also want to run their existing OS X apps. ISVs dont want to do work everywhere but can’t stop doing work on iOS to support a relative niche platform like OS X, especially not if the work is massive like supporting new touch.
23/ Techies/programmers *love* bootstrapping. It signals success—once platform can host development environment then it is real.

Nothing could matter less in this whole topic. This is product development for 4B ppl, not computer science for 20M pros in s/w.
24/ So technically:

• What apps run and where?
• Does Mac ARM support touch and where?
• How does this impact the healthy iOS ecosystem?

Then business:
• How much does a device cost and how profitable is it? What does it replace or does it add to the lineup?
25/ Adding a big new product to a lineup has a high cost in terms of complexity if Apple needs to articulate what runs where and why—especially relative to ChromeOS (“everything”) and Windows (only one platform) not to mention trying to incr support for Watch, TV, future…
26/ My caveat for all of this. Apple owns the whole stack end-to-end. They in fact have 100% flexibility to do anything they would like. It is just a matter of risk:
• Risk to perceived customer value
• Risk to engineering
• Risk to developer ecosystem
27/ For example, Apple could treat this all as an opportunity to create a new device like TV and Watch where developers have a new type of iOS App to create. This would be “Extreme New” and really iPad++. That doesn’t solve legacy Pro, but is a future ;-) You know, clamshell iOS!
28/ Root of all this is asking:
• What problem is being solved for customers?
• What opportunity is created for Apple?
• What constraints (tradeoffs) get introduced in solving that problem(s) and tapping into that opportunity?

Discuss // END
PS/ This is the post we did to describe porting Windows to ARM at the OS level. Of course iOS did all this work already but a decade+ ago. Many know more than me about the state of trying to backmerge all that. blogs.msdn.microsoft.com/b8/2012/02/09/…
29/ Been interesting how many believe an ARM-based Mac doesn’t need Touch and ARM is mostly jettisoning Intel.

That’s an extreme view of porting with finite customer benefit. Moving to Intel brought Apple into a big ecosystem but now Apple is its own. That could end like PPC??
30/ While Ax is insane and amazing, the design constraints for mobile v laptop are different. The “single-threaded” nature of Apple’s product process could be stretched to both leverage and advance to provide the “power” that Mac customers presumably want from macOS (on ARM).
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to Steven Sinofsky
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Follow Us on Twitter!

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!