Comment by gumby | Hacker News Reader

Comment by gumby | Hacker News Reader

Parent Full thread

> I'm sure Apple would love to lock down Macbooks the same way they did for iDevices...

I really don't think so. The Mac has a different history and use case and is heavily used within Apple, among other important places.

The incentive for Apple to do this would be what: do extract a little more revenue from their smallest-volume OS? As you say, part of its use case is the fact that you can just download and run code on it. That's a small and decreasing percentage of users, but those users are important too.

I'm glad there's no sideloading on my phone and ipad (of course I can always run my own code when I want to). It means my parents have stable platforms to use. And I'm extra glad that restriction doesn't apply to my mac.

I like how the design language of the watch is influencing the ios and macos devices. Unlike the stupid experiments on the phone, there isn't a lot of room on the watch for "flat" interfaces: space is at a premium and contrast is an important factor.

I'm also glad that for almost the first time new features are rolling out to i devices and macos at the same time. Usually it was mobile first, then grudgingly macos.

>The incentive for Apple to do this would be what: do extract a little more revenue from their smallest-volume OS?

I think that's only part of the picture. Yes it would boost their services business, but Macbook/iMac users are a small part of the picture these days. It's smarter from a technology centralization standpoint. Why have almost all your products centered around iOS codebase, and then your laptops/iMacs (small % of total devices) on legacy OSX. A better strategy would be, use a single OS codebase, and add layers of functionality the bigger / more pro a device gets. Makes it way easier to advance the software for your entire product line.

Btw, expanding iOS to Macbooks/iMacs does not mean throwing pro / dev users under the bus. They can think of a way to make "iOS-macOS" appealing to devs, by simulating some of the OSX features, like terminal and the ability to write software on-device.

> A better strategy would be, use a single OS codebase, and add layers of functionality the bigger / more pro a device gets.

That is the strategy that they have used since the original phone announcement (Jobs touted it on stage). Supposedly there were two competing phone teams, one built on a mac os X base and one on the ipod s/w. I don't know any of the people involved so I can't say how true that is, but it feels a bit weird to me, like the kind of thing that would have been decided pretty early in the process.

In any case there's a large percentage of common code base between the oses on phone, ipad, watch, tv, and mac (and a bunch of embedded devices too, like the usb-c and lightning dongles for HDMI -- yes you can open a console to those devices if you want).

What I think is great is that a bunch of ios frameworks now work/have equivalents on the macOS. I'm actually pretty happy for the same capabilities to be roughly available across platforms: back in the 80s the hardware I used (lispms mostly) was pretty much all a computing "window" into a common underlying sense of computation. I use the apple devices because they are getting pretty close to that: I can just pick up the device that has the most convenient interface for task X, or if that's not possible, still do task X with the device at hand.

Having said that what sucks is when the mac application is just a lazily ported ios app that doesn't fit the mac UX metaphors. But this release looks like a good step forward in that regard.

I'm not sure if I recall correctly but I thought the ipod-based iphone was more to have some of the engineering teams contribute to certain parts without expanding the number of people that needed to know the top secret parts.

Reply on news.ycombinator.com