I am interested in battery efficiency, raw cpu and graphics performance and do not care to do low level tinkering on my Mac.
I do expect it to be much more open to tinkering than iOS, but I also welcome the litany of security measures introduced so far and caution when it comes to executing wild code that affects my privacy.
I realize this puts me further in with trusting Apple to make good compromise decisions on what is possible and the hoops they create for developers on Macos, but I trust they will mostly make the right call for me.
It’s certainly been better than when I’ve had to deal with windows over the past decade.
You may not, but many do. Those many may actually be a small minority, but it would really suck for those folks.
At the end of the day, sometimes I need to run random x86/64 executables and there isn't any way around that. I could deal with a performant virtual machine.
USB to ethernet dongle.
Little Snitch.
Karabiner.
Hammerspoon.
NTFS read/write driver.
I really doubt they will all remain working but the dongle is hardware.
Personally, after 13 years of Macs any computer I'm buying in the near future are going to be Linux based because of the current trajectories Apple have decided to take.
Just insight from a different community I guess.
None of that is a compelling enough reason to switch, when the OS is the primary reason I jumped ship to Macs in the first place.
It's not just about being able to run this or that app, but the overall comfort of my everyday work environment, while still giving me the room to occasionally step out of my comfort zone on lazy afternoons.
As long as macOS retains the ability to run emulators, I think I'll be fine with its growing number of security-based restrictions.
However, whenever I have occasionally peeked back in on the state of Windows (the last time being a year ago, to run some games), it still had many of the same annoyances, frustrations and archaic encumbrances that made me wish for a better world and try out Macs around 10 years ago, and I still don't agree with the overall philosophy of Microsoft (as I perceive it.)
Apple/macOS remains the "lesser evil", at least for me.
That being said OSX running on a higher specced ipad pro CPU could be really awesome but I don't think that is what will happen.
There are several code editors for iOS https://duckduckgo.com/?q=ios+code+editor and Apple has even published an own app for students to learn coding called Swift Playgrounds https://www.apple.com/swift/playgrounds/ - it isn't a full-blown code editor, but it clearly allows you to write and run code.
And that is ignoring cloud/browser-based code editors. That execution model (write code local, run in the cloud) makes sense with mobile devices which have limited power supply. I personally don't want to spin up several docker containers on my iPhone ;)
But other people might? Especially if it not a phone but a 12.5 inch iPad that is supposed to be more powerful than my 5-year-old dev laptop (and has more RAM too).
> It is allowed to write code on iOS
Great, so you can pen&paper your code like in the 1960s. In the 21st century, writing code includes being able to run the compiler/interpreter on your terminal to debug as well.
iOS is system build mostly for content consumption and designed for non-technical users. As such it has to be protected from both external threats (malware etc) and users themselves (social engineering, phishing protection).
macOS is for me my workbench for content creation and I want it to protected from external threats but I do not want it to be protected from me. Even having to go into System Preferences and typing in my password to run unsigned apps since 10.12 is driving me crazy.
When is comes to privacy, today everything is web app anyway. And to be honest I would feel my privacy would be much more secure if I could run latest version of uBlock Origin in Safari, but I cannot.
For native apps I want to decide if I trust them or not. The only new thing I would love to see in macOS is easy blocking of internet access for particular apps.
Does right clicking and hitting "Open" not work anymore?
One day, they might switch Mac to ARM. But I don't see that in the short term.
Notarization is not “mandatory”. You can still turn it off.
The seemingly gradual lockdown of macOS – mandatory "notarization", moving system files to a read-only volume,
So now it’s a bad thing that rogue apps can’t destroy your system.
and disallowing kernel extensions in the future
And they developed a way to do the same thing and improve system stability.
For how much longer? I'm not asking facetiously, the trends across the entire industry are quite obvious at this point.
> So now it’s a bad thing that rogue apps can’t destroy your system.
It's a bad thing that modern "security measures" somehow consistently manage to be as restrictive towards user freedom as possible. Methods that would accomplish the same user protection without resulting in a walled garden or vendor control of the device are somehow never selected for.
I'm sure there are no ulterior motives at play here though. /s
A key difference between the Mac and iOS. https://developer.apple.com/videos/play/wwdc2019/701/
This same panic has been going on since 10.6 with the introduction of the Mac App Store. How do you propose that you would be able to develop software on the Mac if you had to sign your executable every time that you recompiled it?
It's a bad thing that modern "security measures" somehow consistently manage to be as restrictive towards user freedom as possible.
So what would be the financial motive for Apple to force signing of apps and allow them to be outside of the App Store? What would be the financial motive of making system files readonly or introducing DriverKit to increase stability. Do you really want third party kext to be “free” to crash your entire system?
I think they would be crazy to do it and don't really expect them to anytime soon but they clearly could. The financial motive is exactly the same as the iOS App Store: get 30% of all app sales revenue and make the OS more secure.
Also, they don’t get 30% of all app sales. All of the biggest non game money makers either allow you to purchase subscriptions and content outside of the store or force you to.
And rightfully so! How is this not an obvious trend to you?! It isn't just Apple, it's cell phones and tablets with unlockable bootloaders, Windows S-Mode, Samsung Knox, Firefox extension signing that can't be disabled, and a great many other examples. It's the trend that's alarming, not the specific way macOS is configured right now.
> How do you propose that you would be able to develop software on the Mac if you had to sign your executable every time that you recompiled it?
By paying the Apple tax for a developer license and then just... signing your code every time you compile it? You already have to do this for Firefox extension development if you don't bother to run a dev or unbranded build. Alternatively, just run your (unsigned) compiled code in a VM.
> So what would be the financial motive ...
The financial motive is the glaringly obvious walled garden! It's the vendor's control over the device you purchased!
> Do you really want third party kext to be “free” to crash your entire system?
Obviously not; that is a bad faith interpretation of what I said previously. There are ways to ensure user security that don't remove control of the system from the end user. These options are consistently not chosen, by more or less all the major manufactures. I believe that the motives for such behavior are quite obvious.
You really think after selling computers for 43 years Apple is not going to allow people to compile programs without signing every time you compile?
How do you propose they are going to lock down scripting languages and programs built with .Net Cord and Java? Are they going to disallow any code on the Mac that’s built on top of a VM?
The financial motive is the glaringly obvious walled garden! It's the vendor's control over the device you purchased!
So are they now going to lock down outside vendors from creating whatever the new equivalent of kext are without paying a fee?
bad faith interpretation of what I said previously. There are ways to ensure user security that don't remove control of the system from the end user.
You mean by allowing advanced users of the Mac to turn off safeguards- exactly what they are doing now?
Btw, a lot of developers are saying that moving away from kernel extensions will make it easier to build Hackintoshes not harder.
While this is certainly technically possible, I think this presumption -- which I see a fair amount around HN -- is at the least somewhat dubious. There's an extremely crucial difference between the Mac and the iPhone/iPad that this argument downplays at its peril: the iOS ecosystem has never been open in this way; the Mac ecosystem has been open in this way for over three decades. Customers do not tend to react well to having things taken away from them.
What's the cost of not just individual users but whole companies moving off the Mac platform en masse? What's the cost of a press firestorm so intense it'll make the butterfly keyboard shitshow look like free passes to Disneyland? Are you sure so many users would just docilely acquiesce to "guess I'll have to re-buy all my software all over again, herp de derp?" Because for this plan to make sense, Apple needs to sell a whole, whole, whole lot of software to make up for every single person who decides this is the straw that breaks the camel out of the habit of buying $2500 laptops every three or four years.
The bottom line is that I don't think attempting to lock the Mac down to the point the iPad is locked down makes business sense. (I'm not convinced keeping the iPad locked down makes business sense in the long run, either. But that's a different post.)
If that's Apple's trajectory, why did they things like Hypervisor.framework (much more recent than 10.6's introduction of the App Store), which allows one to make unprivileged virtualization solutions, that can run any OS/application?
To me, it their motivation seems two-fold: (1) they want to carve out a niche for security and privacy. People are willing to spend a lot of money to avoid the data grab of Facebook, Google et al. And people are willing to spend money on a system that focuses on security. So, Apple have invested a lot in hardware security (T2) and software security (sandboxing, read-only system files, mandatory kext signing, user-space drivers).
And, yes (2) they probably also want to funnel more and more through the Mac App store for profit. The thing is, they can make macOS a walled garden system, while keeping the back door open for advanced users. My dad is protected by the Mac App store, application bundle signing, notarization, and sandboxing, he is not going to boot in recovery mode and run csrutil in the command-line. While I can in the use csrutil to lower protection a bit to be able to run DTrace. In other words, I don't believe that they want to or need to turn macOS in a complete walled garden: 90% of the users does not want to or cannot disable security measures, while at the same time keeping the csrutil around keeps the other 10% happy.
---
I think the more serious danger for macOS was negligence. With key execs primarily using iPads and glacial development of macOS, the most imminent danger seemed to be that macOS developed into nothing else but an SDK/IDE for iOS development. But after the last WWDC, I am mildly optimistic that they have woken up.
One cannot have security while allowing apps to do whatever they feel like.
Being able to do that isn't just a nice thing to have, it is a downright mandatory ability any computer must have.
I rather have the inconvenience of using them, even if they don't prevent accidents.
Not being able to install any software you want on a device you own is not a small inconvenience cost, it is a great artificial limitation meant to take control away from the user and put the user at the mercy of the vendor who can then use it for other user hostile actions (e.g. forced obsolescence, a common tactic in the example of gaming consoles brought before).
And especially in this case, any "better" outcome is really small and short term (the user being unable to do much with their own device means they are also unable to install unwanted software) whereas the larger picture outcome is user hostile - a gradual loss of control and ownership to the goods you are paying for.
I rather have a store than a background application taking machine resources, to ensure that applications are safe to use and do not expose my computer contents to the world when connected.
Thankfully i'm not one. But that doesn't make me blind on such schemes.
Also that background application you mention, even though it isn't necessarily needed in all cases, it is still a better solution than a locked down system since it is under the user's control.
You're more likely to get seriously scammed in a browser than by an actual malware/virus.
https://www.autotrader.com/car-news/new-general-motors-featu...
As consumer, app stores are more than proven.
I cannot parse this, what do you mean?
> As consumer, app stores are more than proven.
I do not have any problem with app stores as long as they are not tied to a locked down OS. See Steam or any Linux repository front-end as an example of app stores that do it right.
But yeah, it's still a choice and Apple is not one of them.
One cannot have a general purpose computer while preventing apps to do whatever they were designed to do.
I don't want random applications to access $HOME just because they feel like it.
If the application was designed for accessing $HOME given its purpose, then I as user, will gladly authorize it.
As developer, and someone that in the past dealt with games and mobile development like J2ME and Symbian, I don't see a big issue going through app certification processes.
That's why Nintendo not putting a browser on Switch
It's appalling an entire WWW browser would be necessary for connecting to certain Internet access points, but that's the current state of things.
In any case, someone has already achieved arbitrary code execution through it, but it was sandboxed anyway.
Also this is an orthogonal issue, the console wasn't designed to have security exploits to start with.
At this point?? Here's my blog post from nine years ago, almost to the day. http://drupal4hu.com/future/freedom
> Microsoft can [...] make it so that any new app needs to be sanctioned. Apple, obviously can easily follow or even do it before Microsoft.
While it might not be mandatory for users, it is for software which is supposed run seamlessly on every Mac, isn't it?
In the mean time, people have already developed ways to run OpenGL code atop Metal. A lot of game developers have already started to move their code to either Metal or these OpenGL-compatible shims in order for compatibility with iOS, so a lot of the adoption has already begun.
Metal seems much more compelling anyway, the Apple lock-in notwithstanding (even that is not so bad considering you can still target 4 rather popular device categories with Metal.)
In fact had Apple not chosen to go with OpenGL ES on iPhone back when they released it, OpenGL would be pretty meaningless nowadays.
The few people buying NeXTSTEP computers for graphics programming were doing it due to Renderman, not OpenGL.
So if you want to write code that uses SIMD instructions depending on whether they are available, you need to use Apple math libraries, which is super messed up.
How it'd work - ARM SoC expands on what the T2 does today, except it now runs all system threads, any ARM native user space apps, and maybe specialty fixed function blocks that Apple throws on those chips (e.g. media encode). Meanwhile the Intel chip is a co-processor for any x86 specific user space apps, and it otherwise doesn't touch drivers or any system things.
The market would be segmented with ARM chips at the lower end (MacBooks), and ARM chips with Intel co-processors at the higher end (15" MacBook Pro, iMac, iMac Pro, Mac Pro). This is equivalent to how integrated v discrete GPUs are segmented today.
Over time the ARM chips get faster and faster as Intel inevitably blunders, and more and more code is rewritten as native ARM code, so that after several years the need for x86 is significantly reduced, maybe only existing as thunderbolt eCPU boxes and/or Mac Pro. And by around MacOS ~10.23 in 2026, x86 is sunsetted because remaining use cases are so minimal.
That's not really Apple's style, at least not under Steve Jobs ;). You just throw the old architecture under the bus, provide some emulation to make Microsoft and Adobe catch up, all developers have to adapt and build fat binaries or get left behind.
Apple can do this, since no one has a strong expectation of backwards compatibility anyway.
Of course, ARM might not be competitive enough yet for Mac Pros. So they'll probably start with the MacBook Air or 12", require every developer that submits to the Mac App store to build universal binaries, and have some partners (probably Microsoft) that will provide support on day 1. For a chunk of the MacBook Air audience the architecture will be irrelevant, since they do Office, browse the web, and send e-mails. So, if they get a laptop with significantly better battery life doing that, it will sell. Once the Air has prepared the software market, go up the product line after 1-2 years.
I like the Intel co-processor idea, but Intel CPUs are relatively expensive. So, they'd have to jack up prices, while going ARM directly would increase their margins at the same price points.
fwiw, the reason I think the co-processor idea is likely is that Apple has recently re-committed to the Mac and specifically some niche use cases therein (thus they can't fully ditch Intel), and that they're already shipping an A10 equivalent in Macs today (the T2) so not that hard to go a bit further into the water. Also, in single core perf its possible the ARM chips would exceed most Xeons they ship, which clock lower in favor of more cores.
Agree if Apple had its way and could pick its markets perfectly, they'd have slowly shed niche use cases in favor of the highest margin markets (which is mainstream not pro), and thus at the appropriate moment dumped Intel and gone all-in on ARM. However, they're seeing the traditional pc market only moves so fast, there's many many pro niches they didn't really consider enough, and those niche Mac users really do have a lot of indirect value to Apple's brand. Emulation wouldn't cut it for those users - it'd only work if Apple saw ditching those markets as an acceptable tradeoff.
Intel CPUs are expensive but so are GPUs, and they'd only be bundled in the higher end machines - nothing that's below $2500-3000.
Well, that's my hunch anyway.
In theory it seems you could be able to convert "on the fly" from multiple high level instruction sets to a singl low level microcode.
Not sure it's a good idea tho.
Security is fine as long as the user is in control. The problem is that very often companies make decisions that take away control from the user with "security" as a "but think of the children" blanket excuse.
If they had no incentive for macOS to be locked down then they wouldn't have any incentive for iOS to be locked down either.
Also i never said that laptops will be made into appliances, i said that they'll be locked down like iOS. You can still do a lot of things on iOS but all of them need to things pre-approved by Apple and a lot of the things you cannot do on iOS is because of its form factor - something that can be addressed with the form factor of a laptop.
If anything i think you may have already fallen victim to the artificial separation that Apple has introduced between laptops and tablets: why doesn't it make sense for laptops to be limited whereas it makes perfect sense for tablets and phones to be limited? It doesn't. There is no reason why iOS has to be limited just like there is no reason for laptops (and desktops) to be limited, it is just that this is how phones and tablets were introduced to the mainstream audience and how the mainstream audience has come to accept and expect them.
Regarding the MacOS platform though: I don’t think they’ll get rid of the ability to add binaries to a user’s home directory much like it is now. It’s a development and productivity platform that doesn’t abstract its Unix underpinnings like iOS does.
But I'm not so much of a zealot to think that if they do do something underhanded like lock down MacOS to a completely unusable outside of Apple ways to not go to a different platform. Until then I will stick with them for sure.
Also Android is not wild-west freedom, the entire idea behind "side-loading" (which is not available everywhere) is a sign to that - or even worse, the inability to gain root access to your own device. If you want an example of such freedom, it would be something like what you see on desktop systems such as Windows or Linux (though Windows 8 and later did piss in the pool with their Metro/UWP efforts).
macOS can become a development and productivity platform while at the same time being locked down. For example you'd be able to install Xcode and even a (user-only) Unix command line environment that will autosign any executable you create for use only on your own machine and a few preapproved others. AFAIK this is how it is already done with iOS devices, except Xcode doesn't run there (but that is mainly an issue with API availability, not it requiring anything that couldn't be provided on a locked down macOS). Since this would require an annual developers' fee, it'd make any source-based releases impractical outside of developers and even that only for as long as you pay that fee (again see iOS: it isn't like you cannot download some iOS program in source code form and install it on your own device, but to do that you need to pay Apple for the privilege).
I don't mind what CPU my Mac runs on, but I am worried about how long I'll be able to play older games, run the occasional Windows/Linux software, and dabble in OS hacking or low-level tinkering to add custom features, on the same machine.
The seemingly gradual lockdown of macOS – mandatory "notarization", moving system files to a read-only volume, and disallowing kernel extensions in the future* – has generated some concern where before I used to just trust Apple to know what's best for everyone.
I welcome the extra security as long as we can manually bypass it if we really want to, but I warily wonder if the move to ARM Macs will come with a macOS that is almost as locked-down or "sanitized" as iOS.
* As mentioned during this WWDC's Platforms State of the Union.