Apple's switch to PowerPC which gave them a performance lead over Intel for five years and kept them competitive for another five or Apple's switch to its own ARM Core designs which have given them a 12-24 month performance lead over the entire Android ecosystem?
Bear in mind that Apple dominates the high-end desktop / laptop market, both in market share and profit share* which could put a huge dent in Intel's economies of scale for high end consumer CPUs.
* I'm assuming these figures omit servers. Also, there was a lot of noise in around 2009 saying that Apple had over 90% of the high-end PC market, but I've not seen more recent figures one way or another. Given that PC prices seem to have, if anything, slipped, I doubt it's gotten worse for Apple (and goodness knows the tech press loves any statistic that makes Apple look bad).
He is referring of course to the PowerPC architecture. It did not have a performance lead over Intel for as long as you suggest. Even when it had a lead, it wasn't that big. (I bought the best G5 when it came out, so it's a painful memory)
The problem with switching to a different architecture is that if it falls behind Intel, people will say "not as fast as a PC." If you stay with Intel and it falls behind, people say nothing. It's risk vs. no reward.
Except apple has demonstrated they can design cpu’s that outperform the (android) competition. Who is to say they can’t make ARM cpu’s that genuinely outperform intel? Intel hasn’t executed all that well lately anyway.
The trade offs for a SoC are different than for a desktop machine, and to a lesser extent a laptop. The desktop is where we'll feel the most pain. I wouldn't be surprised if they cancelled the Mac Pro entirely.
It would surprise me, because they made a big public show of recommitting to the Mac Pro last year.
If they had any doubts all they had to do was say nothing -- which is their strong preference -- and it would have remained clear that the Mac Pro was dead.
Making a strong "trust us, we're working on it" statement and then canceling would be a pretty bad unforced error. Not impossible, but with their top-down, forward-looking decison-making process it seems very unlikely to me.
Given the failure of ARM in the datacenter Apple would be pulling something off that no other semi manufacturer has. It's not impossible but just very unlikely.
It's much more reasonable that they'll do a "best effort" in the high end space but it won't be comparable to a Xeon. You can see the iMac Pro as a prelude to that. A beefy machine to be sure but not what you'd expect for top of the line.
It really depends on what exactly Apple is intending to do, which we just don't know yet.
But if they really are committed to the Mac Pro (and if this rumor is essentially true), then they must be planning something pretty extraordinary:
1. They actually have a solid plan on how they are going to make CPUs competitive with Intel Xeons over the next ~2-4 years.
2. They're planing on a bifurcated line, where some Macs have Apple CPUs and some have Intel CPUs... presumably with different architectures. I guess 2b. would be that the Apple CPUs will actually be x64 compatible.
It all seems pretty crazy, but Apple has done this kind of thing before, and done it rather smoothly. I guess time will tell.
The simplest explanation is that they aren't that committed to the high end. They don't make any money there and they've proven with their actions it is not a priority. A few quotes to the contrary don't change the fundamentals of what they've been doing.
Being able to go toe to toe with low-power areas says little about being able to compete against full-power areas, and vice versa. Intel is a laughing stock when trying to compete in low power areas even though they dominate full power. ARM is the only choice in low power outside of a few Chinese chips and Samsung's Exynos, but yet ARM hasn't made a dent in full power applications. The two areas do not scale as easily as they sound.
Intel has been iterating their design decades longer and was in stiff competition for much of that time period. They will be hard to catch in the desktop/laptop space for anyone starting with a cell phone CPU.
ARM has not had real competition in their market, most chipmakers are licensing ARM tech, so they should be easier to catch up to, which Apple has done (with a healthy dose of borrowed ideas from ARM).
You're right, for some reason I was thinking Exynos wasn't ARM based because it wasn't Qualcomm- not sure why. That takes the list of ARM competition down to just the Chinese offerings, unless I'm mistaken about that.
You do realize Exynos and the Apple A-series are both ARM processors. They didn’t “borrow” ideas from ARM, they licensed the IP and are fundamentally just better implementations of the base line IP with a few things added on.
I don't know where all this conjecture is coming from. Have you seen benchmarks of apple A11 chips? They have some of the best CPU technology in the world now. They are competitive with low end Intel chips already while using significantly less power.
Before they went to Intel, they were at the mercy of Motorola, which couldn't keep up with Intel.
The problem Apple had with Motorola was that Motorola couldn't get the chip yields they needed at high clock rates.
The problem Apple had with IBM was that IBM didn't care enough about power efficiency to make the chips viable in laptops. They also weren't that interested in fast iterations of incremental improvements.
When the G4 first game out, it was far, far ahead of x86. Apple offered it at 350, 400 and 450 MHz but shipped maybe a few hundred or a few thousand at 450 MHz and a few tens of thousands at 400 MHz. Those computers blew the Pentium out of the water. Intel eventually caught up and passed them purely on manufacturing ability.
Then the G5 came out, which was a beast of a processor. But it never came out for mobile, and IBM only upgraded the speed once or twice before Apple went for Intel.
PowerPC (with the backronym Performance Optimization With Enhanced RISC – Performance Computing, sometimes abbreviated as PPC) is a reduced instruction set computing (RISC) instruction set architecture (ISA) created by the 1991 Apple–IBM–Motorola alliance, known as AIM. PowerPC, as an evolving instruction set, has since 2006 been named Power ISA, while the old name lives on as a trademark for some implementations of Power Architecture-based processors.
Apple was always their own world, their "openess" came from almost closing doors around 1994 and with NeXTSTEP they played the same game as NeXT did, pretending to be open to get UNIX devs into the platform.
Now that they have the upper hand, they are free to go back to their old ways without much considerations about opennesses.
With the PC sales declining and most OEMs following back to the old ways of integrated computers, before of PC components revolution, I guess most regular users will use follow along.
If the macOS/iOS developers still can get their share of the cake, most things will hardly change, although they might loose those that only use macOS as a pretty UNIX.
The question is how relevant are those sales currently.
Nah... back then single thread performance mattered a lot. Today most users can do most of their work on something with the performance of an iPad.
Apple will not suffer in 2020 from having lower performance than intel. It wont matter. Form factor, screen quality, memory speed, memory size, touch pad, battery life etc will matter so much more.
Multi threading is also so much more common on pro app which require performance. They can just match intel by using more cores. ARM is way cheaper than intel so I don't see how they can lose this game. PPC was an entirely different world.
The mac mini is essentially 1700 days old since they downgraded the processors.
I only have macs because I build apps on them. I buy used and as inexpensively as possible. Using an old i5 for development currently.
I wanted to be an Apple fanboy, but having to rebuy critical software for even point releases because of stability killed that off for me long ago.
Best Apple I've ever owned (beyond my //e) was the Dual Processor Quicksilver. Case opened on the side, you had many upgrade options and it even looked nice (irrelevant to me but I'm sure that matters to some).
ARM will simply be the new PPC. You think things like supporting external graphics cards (yay they just got limited AMD support) and having high end rigs isn't what people want, especially in the gaming community?
My strategy with any apple news: ignore it until its released or said from the horses mouth. Remember the iphones that had clickwheels like ipod rumors prior to the iphone? Thats what I consider this.
The clickwheel iphone "rumor", might have been true. During initial design of the original iPhone, both Scott Frostall (from Mac OS division), and Tony Fadell (from iPod division) were tasked with creation of iPhone. Both groups took their existing software (from iPod/Mac), and tuned it for a phone. Ultimately trimmed down OSX solution won over iPod's evolved firmware.
I was reverse engineering iPod video/classic firmware around 2005/2006, and I do remember seeing references to "iphone".
Sure it might have existed, but that isn't what was released. That version of the iphone might just have been a proof of concept or prototype, but it didn't end up a product.
It's not just feasible for Apple to develop new microarchitecture from scratch. Kalamata will license ARM technology. New microarchitecture takes 6-8 years to develop and it's huge investment even for companies like Intel, Amd and ARM.
Currently only Intel and Amd have high end desktops CPU's. ARM is likely enter as third with ARM architecture that Apple is licensing, but it will have relatively low performance.
Apple will likely take a hit in workstation markets for CAD and image processing application market but they are in the position to gain a lot in more common use cases if customers get better power/performance ratio.
I think I see the questions, but I don't think we can answer them. Will Apple use this as an opportunity to merge MacOS and iOS? What will that mean for developing and distributing software?
It was just a stream of consciousness and I was planning on editing it but got distracted. It also wasn't formatted very well. My mistake.
I'm sure this has been going on for a long time behind the scenes. That is what happened when the PPC -> x86 transition became public. Since Apple has it's own ARM chips/fab, I wonder if ARM is where they are going? It would make sense from a couple different points of view: Lower power use and security. Can there be equivalence between the two architectures, meaning would similar CPUs net you a similar workload?
There is much to like about the iOS app store, but there also is much to dislike. Apple is the gatekeeper here, and if they don't like your app, you are out of luck. That's not the case with MacOS, at least not yet. You can still write what ever kind of app you desire for what ever your client base may pay for and Apple can't really do much to stop you. Merging iOS and MacOS would need to address this.
Finally I use the command line a lot. I don't have access to that on my tablet or phone unless I jailbreak it which has it's own risks with doing so. If Apple decides this is no longer acceptable, that will certainly change my choices for getting work done.
That's a good joke and I laughed, but this seriously understates the power of Apple's ARM chips. They are pretty impressive. To put this on the pizza scale, Apple is a lot further along than any individual pizza maker. They're a strong regional pizza chain, at the very least.
Because they have moved past the easy parts of optimization. Apple's optimizations still have thermal throttling issues (sustained use of an A11 will not beat an Intel chip due to better cooling and IPC).
Compared to other ARM licencees they do beat the pants off of. This is probably why Apple put in a T1 chip and a touch bar in the Macbook Pro and the T2 chip (dedicated power module) in the iMac Pro. They are prototyping the individual pieces with Intel as the main processor so that they can attempt to swap the chip in 2020.
sustained use of an A11 will not beat an Intel chip due to better cooling and IPC
In an iPad profile sure the heat dissipation is very limited. With even a basic passive heat sink (not just a spreader, but actual fins for surface area), much less active cooling like most laptop and desktops use, and the heat profile dramatically changes.
This change was inevitable -- recent A## chips have been just astonishing for passively cooled chips. The state of the art in binary translation, and the support for cross compiling across architectures, makes this a very doable transition.
Intel painted itself into a technological corner, where they have to pursue yields with larger die sizes than AMD. Or, looking at it from the other side, AMD won by steering themselves a course where they could avoid the trap of ever larger die sizes.
Because x86 was technologically mature in the 90s (superscalar, OoO, vector extensions, …) and basically hit its frequency ceiling in the mid-aughts (modern Core-series finally have frequencies beyond what P4 reached back in 2005~2006 but it took a long time).
ARM was nowhere near there (for it had no need to) before modern smartphones. ARM in 2007 was single-issue in-order single-core topping out at ~600MHz.
Standard math failure. It's the same with programming languages. I never trust anything that got a "2x" speedup because if a gaping optimization like that exists, it's likely not ready for prime time.
Single threaded CPU performance improvements are pretty much tapped out at this point. Process improvements have slowed to a glacial crawl (compared to the past), clockspeed can't really increase much while maintaining the ability to be air cooled, and IPC is mostly mined out. Intel probably has the best processor cache in the industry, and adding more just isn't yielding much for general purpose applications (can't really speak about multi-tenant environments or other specialized applications).
I'd guess, but I don't know, that Apple's performance growth is coming from two places:
1. More multi-threading. Moble chips in general have been getting more parallel over time. It's pretty easy to construct synthetic benchmarks that benefit from this; it's less easy for general purpose applications, although they are coming along.
2. The GPU is improving. It seems like there is a lot of headroom here to improve. Apple's GPU is almost certainly substantially better than Intel's. This isn't really a huge problem for Intel, because for people who care, they can always get a discrete GPU. Super powerful GPUs can be very impactful for certain applications, but they just don't have general applicability.
In general, I'm pretty skeptical that Apple's CPUs are improving in the necessary areas to enable them to switch their pro lines. Moving over their Air and Macbook products to in house chips seems pretty straight forward.
Steve Jobs mentioned in interviews what a hell of a job his teams did in the initial change to x86 and the immense work it required.
I wonder what he'd say in this scenario. Not saying "Steve Jobs would have NEVER allowed this apple is going to shit", simply wondering if the effort required to move to x86 should be essentially discarded (depending on the implementation)
Edit: I agree with the replies, they are a good reminder to me of the sunk cost fallacy
Honestly I think Jobs would’ve been all for dropping x86. They also derived an immense amount of value from the effort to move to x86, so it’s not like it was wasted.
In the x86 transition, Apple was discarding the previous effort which had been required to move from 680x0 to PowerPC, and that seems to have been the correct choice.
The effort to move to x86 has paid off tenfold already in the ~10 years since the transition. They now need another effort to sustain the Mac, or whatever comes next, for another 10 years.
It's also worth noting that the OS they migrated was not the one that ran on the bulk of the old ppc system but a relatively new Unix fork that at least at the time was pretty possix compliant.
They could just buy AMD, which is also a rights holder to X86_64 (in fact, they basically “invented” it). Super highly doubt it will happen, but technically possible.
It is not unheard of for licenses to have terms which require renegotiation in the event of acquisition. That might make such an acquisition a mortal threat to x86_64, but not a seamless path to using it.
People here were anticipating this, should be no surprise. Presumably, Intel also knows for some time, but their long-term strategy on how to stay relevant seems unclear. I could imagine them becoming a pure fab-company one day.
Apple does have a good record of moving their OS and software from different architectures. 68XXX to PPC to Intel was not a horrible experience. Having gone through three transitions I don't remember a lot of pain - but maybe I am repressing it!
It is fairly common for newer versions of OS X to break software that worked on previous versions. If you try to use Photoshop 6 on a modern version of OS X it isn't going to work. I think this makes the chip transition less painful because no one really expects their old software to work anyway.
Well everyone (including myself) likes to complain about it, but there is a huge difference in how many OS updates it takes to break a legacy application on OS X and Windows. If we really expected the OS X updates to not break things, we'd move to a different OS.
PS6 used the old Carbon Framework. This was developed as a stopgap to allow developers to transition off of MacOS to OSX in the early aughts. It goes to show how little respect Adobe back then had for Apple and Mac users that Apple ended up purchasing and developing Final Cut Pro and Logic Pro IP.
Microsoft Office was another drag on the Carbon library. They also chose to keep their applications in the old format even though they were told repeatedly from Apple that this thing was going away. Eventually they got their shit together and the Office suite for OSX is a best of show.
Not really an excuse when Windows 10 can run most Windows NT4.0 software, can get to run win3.1 and dos apps (which are different OS, not just older versions).
Userspace GNU/Linux is also pretty bad about this, despite the effort put in by Linux.
A few simple apps here and there is not most Windows app. I keep a windows 98 VM around simply because developers played fast and loose with the security of the OS. They would not be able to do that today. Like a user editable ini file in the windows folder.
Yeah, Windows 98 is a completely different OS from modern Windoes, makes sense that compatibility is not strong. It would be like expecting OSX 10 to run classic Mac apps.
I've been through the PPC to Intel migrations so many times for so many school districts that I'm still fairly amazed at how well it usually went as long as the apps weren't trash.
The biggest issues I ran into was always with the low quality edu based applications. So many of the issues we had with those apps were because they were created in Windows and ported half way to OS X, an old PPC version that did something special that the Intel version couldn't do, or the worst one using a special baked in version of Adobe Flash..
I've been out of the edu game for a while now. I want to say it was the Map Testing system. The school district was using a web based system (something lightning? I can't remember) previously, but the state was mandating the use of MAP instead. The state didn't give the schools any options or much time to prepare for it either. The school district had 70+ schools. I spent a summer fixing / getting that stuff working. (still more fun than iPad deployments)
The app wasn't a universal binary at the time. Which would be fine if the PPC version worked with the PPC machines, and Intel worked with the Intel machines. haha.
*Edit
The windows version did usually work without issues. The OS X version eventually worked once they redid the whole application.
Edit: maybe I should explain a little. We were a educational software developer and doing multimedia titles. We had a home grown multimedia engine which served us well (at the time there weren't alternatives) but Flash came along and at the time they would license the engine as a C or C++ library, which we could embed. This would get us a capable engine with superb integration with the content creation tools.
phew, I was hoping MAP wasn't going to come back to haunt me after all these years, haha.
If your application let students finish what they were doing without randomly crashing and losing everything, then it is leaps and bounds better than the MAP system.
The school had to extend the map testing by 2 weeks just because of how often it crashed and students had to retake it. My coworkers at other school districts in other states ran into the same exact issues. Then on Windows, it had to access a SMB share somewhere to dump data to a flat db... that would get corrupted sometimes when a students application froze up... haha. it was job security though.
> 68XXX to PPC to Intel was not a horrible experience.
Unless you rely on a piece of software that does not receive any updates anymore. Then you're basically screwed. I am rather annoyed that Apple is going to break backward compatibility yet again for no good reason. Intel Mac's perform a perfectly adequate job and Intel couldn't really screw Apple because they are a rather good customer.
Intel already has screwed Apple as far as they're concerned - there have been numerous delays in macs attributed to Intel's chip delays. Apple isn't one to take kindly to holding up a significant product line for an external vendor if they have an alternative.
While it's had a rocky start, Microsoft's starting to push Windows 10 laptops based on ARM chips, so it's definitely not out of the realm of sanity that Apple is interested in doing the same.
Based on this article, it doesn't sound like Bloomberg has enough information to distinguish between Apple being committed to a transition, or Apple developing chips to improve their negotiating position with Intel. It's also very unlikely to happen on such a fast timetable; given the IP situation, it's unlikely Apple could make an x86_64 chip, and any move away from x86_64 is going to require significant work by third parties outside Apple who haven't even heard of the possibility of this happening until today.
And cost. Making something you can license to others and/or sell to 250000 users each year has a completely different cost compared to something you use only on your 20000 machines (source: [1]).
Macs are already overpriced, I don't know how much Apple could sustain an in-house production of proprietary chips without hitting their users; they're probably going to ARM.
I think you might have misread the table at the page you linked. Above the table, it says "Shipments are in thousands of units." According to the table, Apple shipped 20 million notebooks and desktops last year, not 20 thousand.
To be fair, their PPC-on-Intel emulation that let old versions run of apps (and the entirety of OS9, IIRC) was a technical marvel on a number of levels - especially considering the hardware limitations of the early chips.
Mac OS 9 never ran on Intel. That was a separate migration path, where Mac OS X would run a Mac OS 9 VM, but this "Classic" experience never made it past PPC.
On PPC you could either dual-boot or run OS9 (and 8?) apps seamlessly on an OSX desktop, which was pretty impressive.
The seamless emulation of OSX-PPC apps on an Intel processor was extremely impressive though. I remember the majority of stuff working surprisingly well with little slowdown (though this might now be rose-tinted).
Mac OS 9 could run apps written for anything from System 7 onwards, and sometimes even System 6 apps though that was hit or miss. It could even run 68k binaries.
Mac OS 9 inside of “Classic” (the VM that ran OS 9 inside of OS X) wasn’t especially seamless, but what was seamless was “Carbon”, a transitional API that allowed developers to build apps that ran natively on both Mac OS 9 and Mac OS X. It didn’t take nearly as long to port code from OS 9 to Carbon as it would have taken to port to Cocoa, so many early OS X apps were Carbon ports.
If apple uses its own chips, I would assume that they would be aarch64 and not x86_64. Also, Microsoft has some magics for executing x86_64 binaries on aarch64 with good performance, so Apple may have a similar technology. We could end up with another situation similar to the Power->x86 transition that happened back in 2006.
Or it could be nothing. This is a pretty thin article.
> If apple uses its own chips, I would assume that they would be aarch64 and not x86_64. Also, Microsoft has some magics for executing x86_64 binaries on aarch64 with good performance, so Apple may have a similar technology.
They definitely do have OSX running on ARM64, they had OSX running on x86 for years before the switch (in fact they had OSX running on x86 before it even was OSX, NeXT ran on x86, SPARC, PA-RISC and 68k, PPC is the one Apple had to add), they've already gone through two architectural migrations (68k -> PPC and PPC -> x86) and by all accounts the iOS core is very much shared with OSX, it wouldn't make sense not to port OSX along the way.
> they had OSX running on x86 for years before the switch (in fact they had OSX running on x86 before it even was OSX
Although NeXTStep ran on x86, the MacOS build on x86 was John Scheinberg's personal skunkworks project until it became Marklar in 2001 (and then kept under the hood for another four years). Mind, Darwin was always written to be portable, but it wasn't a deliberate strategy to take it to Intel. This time around though, I too reckon that they have already a MacBook running on an A10X in the labs.
What I'm really curious about is what they've still maintained: what they publicly ship now is all little-endian; are they still maintaining any big-endian port? Do they have a big-endian ARM port? Have they preserved the big-endian PPC port?
> Also, Microsoft has some magics for executing x86_64 binaries on aarch64 with good performance, so Apple may have a similar technology.
I'm reminded of the patent-sharing agreement between the two. Or, given MS' diversification, they may be willing to directly license the tech. Making the x64 -> aarch64 translation as robust as possible has benefits for both companies, and they're not nearly the bitter enemies they used to be.
> High Sierra is the last macOS release to support 32-bit binaries
"Without compromise". We'll see what this means later, but most likely it'll mean that macOS won't ship with a 32-bit runtime and you'll be able to download as you do with Java.
> ...Microsoft has some magics for executing x86_64 binaries on aarch64 with good performance...
I was just listening to a Windows Weekly podcast about that, and its limited to 32-bit x86 binaries only, no 64-bit support. They also said its "unusable" for 32-bit apps (in particular Chrome), because you can watch the system drawing the windows of x86 apps on the screen.
Watching the video, they seem to be exaggerating a bit with "unusable", but Chrome does look sluggish, and the startup of "DrRacket" and its window redraw does look very slow too.
Ahh that is a bummer. I only read about the translation stuff when it was first announced, before there was much info on the details.
Edit: After watching the video, that didn't seem too bad. Perhaps it would work well enough on top of a beefier ARM processor? Of course the lack of x86_64 support is another issue that may not have a reasonable solution.
Apple has been trying to chase power users and professionals off of their platform for years. A switch to ARM is an opportunity to rid themselves of the few remaining holdouts and focus 100% on high-end consumer electronics.
I would say that is more about the boxes they use than CPU. The difficulty of adding your own hard drives, memory, graphics cards etc to a Mac is the biggest problem I think.
What pro task, really requires high single thread performance? I imagine Apple could match intel by simply using more cores on their ARM CPUs.
True, I miss the old Powermac towers: Workstation class machines, but with low-end configurations for those of us on a budget. When I was faced with the choice between:
- an iMac that didn't really meet my needs
- a ridiculously unaffordable Mac Pro tower
I jumped over to Linux running on commodity PC hardware.
And what are your processing times like? I use my Mac for video editing, but I have never had any problems doing that smoothly even on much weaker Macs.
Only issue I have on Mac is compiling large programs.
The issue is with live streams of audio or virtual instruments with CPU heavy effects with very small amount of buffering (typically 64 samples @ 48kHz, which is 0.75ms). Also processing of instruments and effects for one track (+ relevant busses) has to be in series so more cores doesn't help a resource hungry signal chain. But of course they do greatly help overall effect/instrument count over many tracks.
Oh good, I see the downvotes are rolling in now (I was concerned after receiving a wave of upvotes yesterday). I've found there is no more reliable method to collect downvotes on HN than to say something critical about Apple.
> significant work by third parties outside Apple who haven't even heard of the possibility of this happening until today
I dunno, I feel like the writing has been on the wall for Apple to switch to their own ARM chips, for 3 or 4 years now. At first it was "yeah maybe someday", but by this point, I'm just surprised they're waiting until 2020. I was hoping the first ARM Macbooks would be this summer. (Really, last summer, if I'm being honest).
Agree this was obviously something that was going to happen. My prediction was 2019 tough. My thoughts was that they probably wanted to get more developers over to using bitcode first as well as ARM being almost at desired performance but not quite there yet.
In 2020 I doubt anyone will see any problems with ARM performance on a desktop or laptop.
I remember Chris Lattner giving some details to bitcode a while ago and according to him it's not possible to recompile an app for a different architecture having only the so called bitcode.
Yeah. There are only three extant architectural license holders (Intel, AMD and VIA) and they're basically in a circular firing squad of patents.
To make their own chips, they'd need to either license from an existing holder (which wouldn't let them tinker unless it was a partnership or they acquired the license) or they'd need to make something so incredibly great the other three would trip over themselves to use it, and bind themselves in the process.
I wonder if "non-transferable" covers tricks like Apple loaning AMD the cash for AMD to buy Apple. Then renaming the new AMD to Apple. Then it would pay itself back for the loans.
I vaguely remember that the licensing agreement between Intel and AMD (Intel licenses x86 to AMD, AMD licenses x86_64 to Intel) expires if AMD gets bought. Apple could renegotiate, but it would not be straightforward, I think.
> If they wanted to go x86 they would just buy VIA?
In theory, but then VIA is a subsidiary of Formosa Plastics Group, so they'd need to either negotiate the sale with an entity with which they've locked horns in the past or buy an entire petrochemical group???
I’m not sure they can for this purpose. I remember people talking about the idea of buying AMD but it’s possible the license terms may say it doesn’t survive a purchase; making AMD or Via worthless for that purpose.
Unless the licensing terms are extremely lopsided, they'd still own AMD64 patents which EM64T is based on, and intel would need to strike a new deal. VIA's situation should be similar, but with other technologies.
Yes. Everything since the Pentium is still encumbered. Intel and AMD have extensive cross licensing agreements. Anyone want to build an x86_64 chip would need to either purchase a company that already had licenses or negotiate with both AMD and Intel.
> It's also very unlikely to happen on such a fast timetable
the article (thin as it is) claims a multi-step transition. Apple almost certainly has a version of Mac OS that can run on their iPad hardware - the transition path that makes the most sense to me is a 12" MacBook that runs essentially the same internal hardware as an iPad pro, and a MacOS that can run iOS apps. There would be a great consumer market for a MacBook that runs iOS apps, and it would serve as a hardware test bed for developers to get their MacOS applications ported over to ARM before transitioning the MacBook Pro lineup away from x86.
>We feel strongly that customers are not really looking for a converged Mac and iPad, because what that would wind up doing, or what we’re worried would happen, is that neither experience would be as good as the customer wants. So we want to make the best tablet in the world and the best Mac in the world. And putting those two together would not achieve either. You’d begin to compromise in different ways.
Of course this is from 2015, and it’s possible they’ve been prototyping for years and think they can overcome the fear of a subpar device.
But as a former Surface Pro owner who now has an iPad Pro, I don’t see that happening. The iPad is immeasurably better as a tablet when you have tablet-oriented software available. And when you don’t, obviously the Surface’s compromise of “have a crappy desktop experience too” is usable if you need to have that option. But it’s not good compared to stuff designed for a tablet.
Similarly, the chunks of Windows 10 that are clearly designed for touchscreens (like the new Settings app) are not great on a desktop compared to the older and still more powerful control panel. More consistent, sure, as any ground-up redo would be, but the information density of things like the Add or Remove Programs list is awful compared to what it was before.
I don’t think Apple is going to make those compromises. They might do a more converged developer backened for Mac and iOS to make it easier to target both platforms, but they won’t shove the frontends together.
Microsoft has been trying convergence for years and have been awful at it, but there are finally some real implemented concepts like modifying the task bar based on tablet/desktop modes.
Realized at scale I still think this strategy could work and with Apple's tight control over the iOS software landscape there is some hope of having iOS as a second-, class citizen on mac OS.
> I don’t think Apple is going to make those compromises. They might do a more converged developer blackened for Mac and iOS to make it easier to target both platforms, but they won’t shove the frontends together.
This, I think, is the most accurate picture of future iOS / Mac convergence. Universal binaries that present either a desktop, tablet, or phone UI based on where they're running.
Microsoft's mistake was trying to converge the desktop and tablet UIs.
They already have one App Store where a single purchase gives you a cross platform app with a different frontend across iPhone, iPad, Apple Watch, and Apple TV.
Unifying the Mac frontend into that ecosystem just seems like the obvious conclusion.
I don't know that they'd strictly be the same executable, but at least as far as the user is concerned they would be the same piece of software. From a developer perspective, multiple UIs built with slightly different flavors of AppKit depending on the UI paradigm, including the Mac which is currently targeted by AppKit.
I don't see it taking over for everything necessarily, but there are a lot of places it would help. Like Paprika Recipe Manager, which costs $5 for the iPhone/iPad universal app, but if I wanted the Mac version it's $30. Part of that is a "because I can" pricing, the market will bear it because there's just not that much competition compared to iOS apps. Another part is "because I have to," it's a much smaller market and a bunch of additional work to make the Mac version, so the price has to cover those costs with fewer users.
If it didn't need a totally separate UI framework, ports like this would take less effort and more apps would do it. Maybe you can't sell it for 6x the cost any more, but a comparatively small amount of work gives you a leg up on the competition.
Twitter is another example. They killed the native Mac client earlier this year and said "For the full Twitter experience on Mac, visit Twitter on web."
They may never release it but no doubt they have it. There are iMacs in Cupertino running macOS on ARM and there are iPads running macOS. During the PPC transition it was pretty obvious that Apple had been building OS X to work on Intel for a while secretly.
Apple has a long history of being strongly against things right up until they actually do them. And i think there's a significant difference between a converged iPad and MacBook, and a MacBook that is still primarily a laptop that runs MacOS, but can run iOS apps as a sort of bonus feature and consolation prize for incompatibility with existing Mac apps.
It's also worth noting that when he said that, Chromebooks didn't run android apps.
Apple did a pretty decent job when they transitioned from PPC to x86_64, it has Rosetta to translate PPC to x86. Microsoft and partners released ARM based Windows Laptops this year that can run Win32 apps in emulation.
What's stopping Apple from shipping Macbooks with a custom SoC that can run existing Apps in emulation until developers can recompile? I would argue that most Air and Macbook owners aren't developers and probably don't have many apps that didn't ship with their system.
Maybe the first few hardware revisions it won't be as performant. Its probably going to be an Armbook that will have the form factor of the Air or the Macbook but with A12 chips. The current A11s are in striking distance for performance.
The current A-series SoC’s were also designed around the power and thermal requirements of a mobile phone. In a laptop or desktop they would have a lot more wiggle room.
It's not powerful/faster that sells chips, it's power and speed relative to envelope. Maybe the iMac pro continues to ship with Xeons, the iMac with Core i5 and i7 depending on configuration.
But compare the Intel Core m3 to the Apple A11, and a completely different story will emerge. The A11 is already comparable to relatively recent Macbooks in terms of performance.
The point is, if we're going to bring up what an 'easy' time Apple has had transitioning from one architecture to another, it's worth remembering each transition came with a big performance jump. This made the new platform desirable and emulation bearable. If they are considering a transition again, 'bearable emulation' is not as much of a given.
While single core performance may not be higher, I could see Apple adding more cores than their current Intel offerings have, and still fall within an acceptable power envelope (thermal, battery life, etc).
I'd expect a huge performance jump when the new ARM-based Macs come out, both in Single-core (they can ramp up the clocks and increase cache and execution units) and Multi-core (they can add more cores to fit new power budgets as well).
The current A11 chips for iPhones are within 10% of Intel's top mobile chips on Geekbench, and within about 30% on their top desktop CPUs.
It's entirely possible for chip architectures to see 2x-3x speeds when moving from mobile power budgets to desktop power budgets.
An Intel Pentium 4410Y Kaby Lake running at 4.5-6 Watts gets about 1800 single-core on Geekbench, while an Intel Core i7-7700K Kaby Lake running at 115 Watts gets 5600 single-core on Geekbench.
> The current A11 chips for iPhones are within 10% of Intel's top mobile chips on Geekbench
No, they aren't. iPhone X's multithreaded geekbench score is 10k. The 15" macbook pro is 15k. That's a lot more than 10%. It's only close if you look at the lower end Intel chips, the dual core ones (which is what Apple ships in the 13" macbook pro).
Those are multi-core numbers, not the single-core numbers.
What do you think is the most important for 250million desktop users? Because the vast majority of them are sitting idle waiting for interaction tasks, like on your system now.
> Because the vast majority of them are sitting idle waiting for interaction tasks, like on your system now.
My dual Xeon E5-2690 v4 regularly loads all its cores and benefits greatly from them, but keep making assumptions by all means.
But if all you want is a chromebook competitor then sure, A11-class works fine. I'm going to guess that the people using Mac Pros tend to care a bit more about just running Chrome/Safari, though. Maybe Apple is just going to completely give up on their historically strong content creation market.
My memory is that the PPC -> x86 jump was due to PPC supply issues and the fact that the PowerPC 970 / G5 was too power hungry for laptops. I could be wrong, but I administered labs of mixed x86 / PPC Macs during the transition and the performance jump seemed just like the normal difference between successive generations.
Keep in mind that while you don’t see much 68k outside embedded these days, you still see POWER in supercomputer rankings, and it also appeared in game consoles.
They were a lot faster, especially the laptops. And that was really the consumer proposition in both cases - you put up with our switch in exchange for a faster, better, stronger computer.
If Apple ends up doing it, the proposition would almost certainly be different and it seems very unlikely it would involve things like running your x86_64 macOS apps on your brand new Mac except three times slower. Thinking about this in terms of previous changes (or in terms of PPC history details) just seems obviously wrongheaded to me.
People assume that everyone who uses a Mac is running Photoshop or developing advanced AI but they're not. There are a lot of professionals using Apple products but they avoid the low end like the plague. Apple is a lifestyle brand these days and much of the user base has no demand for anything beyond the core Apple Apps.
The Macbook Core i3 is barely enough to run Safari or iTunes and Apple could probably replace the CPU without many of those users ever noticing.
Apple's ARM chips compare favorably to the crap that is in most laptops. Those Intel Core i3 6100U or Core i5 6200U chips? The midrange and low end will be greatly served from ARM chips.
They will not compete at the high end against the Core i7s with 6 cores running at 3.8GHz (12 with HT) though.
I guess that Apple would have the resources and knowledge to create an extended ARM architecture that could match x64 in the same power envelope, if they really really wanted.
The market segment isn't that large though so it seems tough to get it done within the laptop budget. Still, it could benefit the other devices and streamline the hardware development, so maybe they think it's worthwhile.
Indeed, we have every indication that Apple can already do both of these things. Go look at Geekbench 4 single-core scores for the current iPhone and iPad vs. the current MacBook Pro. Apple is already beating Intel on speed in a design that uses MUCH less power.
I don't think we can make that assumption here. I would be very surprised if the ARM chips they put in desktops are identical to the ones they put in phones.
For one, the power budget is going to be a lot larger (even for a notebook), and power is roughly equivalent to speed.
4217 for Apple A11 @ 2.4Ghz vs 5683 for Intel Core i7-7700K @ 4.2GHz
Of course, microbenchmarks don't mean much. But the margins are thin enough for users to notice already. Add in more power, more cores, more Ghz, better optimized instruction set, more vertically integrated system, and who knows.
geekbench scores look impressive because they are very very short bursts to prevent power/thermal throttling on iphones, iphones are able to scale up/down preformance wise very quickly, x86 CPUs less so, so what is really being tested is how fast can a cpu jump from idle to full speed.
Geekbench is not at all a reliable benchmark that tells you anything about real preformance.
Its a total farce to suggest that a CPU with a power budget that is 10x to 20x larger, on a modern process, with modern archtecture is somehow just as fast or slower.
It’s true that Apple fumbled 68k —> PPC as far as MPW went but it’s also true that creating fat binaries was a total non-issue with CodeWarrior. Apple had learnt from that mistake for PPC —> x86
The difference is that the x86 chips were so much faster than what they had for PPC, that they could still emulate it without customers feeling like they were going backwards.
Apple spent a lot of effort with each transition trying to make it as smooth for customers as possible while still pushing forward with the new system.
I have no doubt some customers were caused pain by the transitions, and some left the Apple world entirely, but characterizing them as being "fucked over" seems a bit over the top.
If you are changing CPU architecture, you have three options with respect to backwards compatibility.
1) Old programs don't work, because it is a different CPU architecture.
2) Old programs work, but in a VM, so it can't take full advantage of the hardware.
3) Old programs must be recompiled to work on new architecture.
The last one is the preferred option, but is only possible for open source software. If options 1 or 3 are taken for proprietary software, the customer needs to buy a new version of the software.
You go through some mental gymnastics to make it seem like #3 is only possible for open source.
Look - Apple or any other vendor isn't beholden to one CPU architecture. Such expectations breed monopolies - like Intel in PC CPUs.
None of your arguments prove that Apple is fucking over customers or developers. If anything, this opens up the market for newer, more nimble companies that'll fill the gaps left by slow moving, irrelevant apps/software.
I'm looking at it from the point of view of the customer. If I don't have the source code, I cannot recompile the code, end of story. The company that sold the binary executable might recompile it for the new architecture, but they're probably not going to give the recompiled binary away for free. That is why I say that #3 is, for the user, only possible for open source.
I agree that vendors are not beholden to a CPU architecture, but let's not pretend that switching is immediately beneficial to the user. What you call "opening up the market", I call adding unnecessary obsolescence to programs that chose not to add planned obsolescence in the first place.
If anything, I would take this as further evidence that software should be sold as source code, because the utility of mere build artifacts can be taken away.
You can conjure up fictitious reasons, but the manufacturer never guaranteed the buyer that future hardware versions would use the same CPU.
Then there's your contrived reason to obtain source code - another bogus, non-sensical reason that'll never fly with devs.
You always have the choice of staying with an older model, or better, using Linux on your custom hardware. Don't push your socialism/communism on one of the most capitalistic companies on Earth (Apple)
That’s a popular line around here but it doesn’t line up with the reality. When they’ve done architecture changes in the past they’ve reached out to large developers for feedback before committing to the changes being made. The original very OpenStep like OS X did not ship en mass because it lacked a bridge library to support developers and Adobe and others cried foul. That’s how Carbon came about. When 64bit Carbon was shelved some 10 years ago, the “sky is falling” was proclaimed but Adobe came along for the ride and everything was fine. Are Technica did a great write up summarizing both the genesis and end of Carbon development [0]
The PPC transition and Intel Transition both had emulators, fat binary support, and for the Intel transition, early access to developer hardware [1]. I’m not sure how much more you can ask of Apple. The current iOS simulator compiles to native Intel code and then builds for deployment use the appropriate CPU target. The tooling is mature and the execution know.
Apple can certainly do better in a lot of areas, i.e. Swift examples that are either missing or are too old to compile. This is something they’re competent at.
Yep. Just to put this into perspective: tiny NeXT shipped NeXTStep on 4 architectures. M68K, Intel, PA-RISC and SPARC. They had at least two more in the lab, M88K and PPC.
Compiling for different architectures was a checkbox in ProjectBuilder (after you took care of endian issues, once). Much easier than in Xcode today.
My favorite was that they apparently shipped an additional architecture by accident: the developer tools came with one of the aforementioned architectures long after it had been officially dropped.
Creatives who want hardware optimized Adobe apps to continue to be fast will care. I wouldn't count on emulation of vectorized code to work all that well.
Yep, I think people tend to gloss over how smooth these transitions really were. From a creative professional perspective, they were huge short-term PITA until Adobe etc had everything ported over. Also Excel lost VBA support for several years.
At least for me "professional Excel users" sent out stuff that I could not open, and that is not good for the for the platform.
"Spreadsheet macros" were like hot personal computing shit in 1983. Really not good if you cannot create them in 2008.
,
(Few complaints about the current Mac MS Office, FWIW) I'm just saying that breaking old stuff often takes year to fix.
No, I get it. I just think that, in general, people who spend a big chunk of most of their work days using Excel kind of consider anything other than Windows MS Office Excel a non-starter.
Adobe's transition was somewhat rough because they took the Carbon route, and then had to do it again to switch over to Cocoa. I expect that now that all their apps are built on Cocoa, the transition will be relatively breezy.
emulating x86 on ARM with any kind of real preformanceis additionally tricky because the x86 archetechure has very strong memory gaurentees (dosent matter if memory is aligned, dosent matter when in the instruction pipeline you access it, etc) that ARM isnt even close to matching.
Emulating that requires a massive performance hit, because you essentially have to check every single memory access to make sure its not doing something invalid on ARM.
Apple has an architectural license. I would expect that allows them to add instructions (assuming modern ARM still has the concept of instruction set extensions)
If alignment fault checking is enabled (the A bit in CP15 c1 is set), the MMU generates an alignment fault on any data word access if the address is not word-aligned, or on any halfword access if the address is not halfword-aligned, irrespective of whether the MMU is enabled or not. An alignment fault is not generated on any instruction fetch or any byte access.”
From what I've heard, x86 to PPC or ARM emulators are doing dynamic recompiling and instrumentation. It catches the illegal memory accesses and rebuilds the code responsible to add paths with slower code with alignment compensation.
A lot of x86 code is aligned for speed already so it's a pretty safe bet to assume alignment and fix it up if wrong.
Will it be that simple? Apple's own Logic Pro ships with a lot of legacy products from Emagic days. I know they've re-skinned a few with the last couple releases, but I'm guessing a lot of the DSP code is still the same.
As much as Apple made a big deal marketing "Rosetta", behind the scenes it was a product from Transitive called QuickTransit. QuickTransit is gone now, absorbed by IBM. In comparison the 68k to PowerPC emulation was very primitive and slow and mostly appeared to work because of how unbelievably slow 68ks were vs PPC.
The fact that Apple develops and ships hundreds of millions of ARM processors every year, which are widely regarded to be the best ARM processors made, and they design and ship no X86 processors?
That alone doesn't make it "obvious" as applied _to a Mac_, which is a very different kind of device that caters to a different audience that often has special needs. See our other discussion threads elsewhere.
That is what I explain in the link. I saw this move coming two years ago when I wrote that article. I noticed how regular users were using iPhones and iPads for almost everything they do. I noticed how office apps like Pages, Keynote and Numbers worked without any performance issues on iPad.
I concluded ARM was fast enough for 90% of users. Once you don't have the restriction of battery life and small enclosure it is not hard to imagine that Apple could beef up ARM a lot for their desktops and laptops.
Why run multiple CPU architectures when one does the job and is much cheaper?
I've been thinking hard about what kind of workload ARM can't handle and I can't think of anything. Ok... there is one 1st person shooter games. But iOS is a more successful gaming platform than Mac.
> Apple developing chips to improve their negotiating position with Intel
Not necessary. They only need to ship one model of Mac Mini or any small desktop lineup with Ryzen to improve their negotiating position while still being compatible with the existing x86_64 ecosystem.
So no, this is not merely a negotiation jibe. There are definite long-term prospects.
We're already moving to a mobile-first design and approach world. Having those mobile/tablet apps expand automatically to desktop is the next logical conclusion. As an app developer, there is nothing better than write-once-run-everywhere, and the cascading effects of that on the whole Apple ecosystem and future consumer audience is hard to understate. Keeping aside power, efficiency, device prices, opportunity costs and much more.
> significant work by third parties outside Apple who haven't even heard of the possibility of this happening until today.
Definitely not today. Its been speculated for many years now ever since the A4 chips, and its still not official news. Usual "people who don't want to be identified". If or when this becomes official news, most partners would be like about time, because everyone is in one way or another working on convergence and multi-device. Adobe and Microsoft are examples of pivoting many of their desktop businesses successfully to cloud and apps already.
Its easy to succed when you have the monopoly in PC operating systems so success of Win 8 proves absolutely nothing. Touchscreen in PC is about as useful as a waterproof towel
> ... I've always thought this is a bad idea ... A finger is not a mouse
There are no good or bad ideas :) Its all about time, place, knowledge of tradeoffs, execution, business, marketing, taking into account all stakeholders (user is one of them) and everything holistic :)
What you say is true, a finger is not a mouse. But we're now a decade past the release of iPhone, and by this time, the industry in general (and Apple in particular) have deep knowledge about all the tradeoffs involved here. 5 years before and this can be considered a reckless bet that requires a Steve Jobs to pull out. Now, its just natural evolution. Responsive design has been around for even longer, and changing interactions based on screen and form factors is a pretty mature problem domain now.
To be very specific:
- whether its a finger or mouse can be a runtime decision, not necessarily a compile-time or clean-slate/distribution decision for different platforms
- those decisions are already standardized enough based on existing knowledge that you can let the platform/framework (or 3p libraries) handle it out-of-the-box for you and just register multiple possibilities. instead of debating finger vs mouse - think finger and mouse
i.e. different interactions requiring entirely different apps - is not necessarily true for all of them. for a 2D application, some amount of standardization is actually good, otherwise it doesn't really help all the interaction patterns and may instead stagnate them.
I'm also surprised that no one (of significant voice) has voiced enough to pressure Apple to think about their developer user population. Everywhere I go I see devs using mac. I'm sure the reason behind this is 2 folds: supported hardware, x64 + Unix platform. So if they make the transition, say, in 2020, the dev world must be prepared by the end of 2019, I mean, from every toolchain to dev Apps. And this would seem quite a big endeavour, not that devs world moves slowly but the amount of work...
The article doesn't say that Intel will be gone in 2020, just that Apple will be shipping macs with their own chips starting in 2020. It will likely start with one or two models available for devs, then a launch that covers more of the platform.
Doesn't all have to happen at once, and Apple has been though this before in the PPC-Intel switch, which went rather well.
No, the Xcode workflow is set up to make applications CPU-agnostic by default, but there's nothing about the Mac App Store that requires it. The executables are ordinary x64 binaries.
It'd be perfectly valid to write an application for the MAS in x64 assembly, if you want, as long as it's sandboxed and doesn't touch any private APIs.
> third parties outside Apple who haven't even heard of the possibility of this happening until today
This announcement is hardly a surprise. The writing has been on the wall for at least the last 5 years since LLVM replaced GCC in XCode. It became even more obvious when Apple started compiling to "Bitcode" so that they could deliver optimized binaries to devices. What that replacement meant is that it would ease Apple's transition away from any particular architecture - developers shouldn't have to do much if the app is installed from the App Store.
> The writing has been on the wall for at least the last 5 years since LLVM replaced GCC in XCode. It became even more obvious when Apple started compiling to "Bitcode" so that they could deliver optimized binaries to devices.
These weren't clear signs of an upcoming ARM switch:
• Apple has been purging software that's under the GPL for quite a while now, and GCC was probably high on the list since Apple (NeXT) had been bitten by its license before[1].
• The Intel switch in 2006 was extremely smooth even using GCC.
• Bitcode is not enabled on macOS, and even if it were, it's not abstract enough to recompile an x86 app for ARM[2].
It could be that they are just trying to improve their negotiating position. Even if that's true, I'd wager that it is just the short-term contingency of an investment with a long-term view. I bet they have their eye on the end-game.
When I say that, I'm thinking of the old TED Talk by Amory Lovins called "Winning the Oil Endgame". I feel like there's some parallel one could draw between peak oil and process improvements. Intel has slowed down now that it's more difficult to extract increased performance with each iteration. I'm guessing someone at Apple is thinking about where they'd like to be positioned when the well runs dry.
One possibly nice fallout of this would be Intel offering Xeons to consumers to leverage its economies of scale on the server-side for the consumer market (since I believe Apple is the biggest customer for high-end consumer CPUs).
Bear in mind Apple’s own mobile CPUs were also vulnerable to these attacks. The vulnerability was with commonly used architectural features found in many processor designs from different design houses, including both Apple and Intel among others.
> "A decision to go with ARM technology in computers might lend it credibility where it has failed to gain a foothold so far."
> "Apple is working on a new software platform, internally dubbed Marzipan, for release as early as this year that would allow users to run iPhone and iPad apps on Macs"
Two things here:
1) I'm OK with breaking the Intel near-monopoly on x86. I'm not OK with moving to a walled garden where Apple forces you to publish apps through their App Store with a paid dev account, etc. just for the privilege of users on their platform. ARM doesn't necessarily mean this, but it is a different CPU arch. When Apple transitioned to Intel/x86 from PowerPC, Intel processors were performant enough compared to PowerPC processors to provide a pleasant emulated PowerPC environment for applications build for PowerPC. I don't think that a switch to ARM would provide this benefit, and afaik Intel's mobile offerings aren't that far off from ARM efficiency. So what's the benefit? Just vertical integration, I guess? Escaping Intel's backdoors and high prices?
2) iOS apps on OS X. Why? Does anybody want this? The way I see it, web apps are perfectly adequate for the desktop environment when it comes to stuff like checking my bank account or browsing Hacker News. I don't want to deal with a desktop app to do any of the stuff I can currently do via a browser. Is there actually a use case?
3) Given the hellscape of bugs currently present in iOS/macOS, does anybody have faith that Apple is going to be able to navigate a rewrite of macOS on this scale? It sounds like the sort of thing that requires a lot of talent and a lot of focus. Apple has the capital for this, but not the environment, imo.
Seems to me like this could be the nail in the coffin for Macbooks that's been pending since the merger of the macOS/iOS teams and the introduction of the controversial TouchBar/USB-C Pro.
And it’s actually a pre that every iOS app works on multiple architectures. If Apple ever wants to change iOS to run on a different type of CPU it’ll be easy.
iOS Apps on MacOS is a good reason for Apple to incorporate touch screens. Today, they say the trackpad is superior because you aren't raising your hands up to the screen. Touch optimized iOS apps would be a compelling reason to include this feature and motivation for many people to upgrade their MacBooks.
Also, the Microsoft Surface Book Pro has a detachable screen that is a stand alone tablet. What if Apple is designing for an iPad to be the main screen with a base that houses external GPU, battery, keyboard, etc. iPad production ramps up, iPad users can "upgrade" to a full laptop, laptop users are automatically in the iOS eco-system.
I believe it's a T series, though your point still stands. I think I'd personally far prefer a display under the trackpad (though I don't think it's necessary at all) to a TouchBar or a touchscreen laptop. But I think I'm very much in the minority.
You're already scratching the surface: vertical integration, backdoors and high prices, power and battery life optimization, lesser effort for an app developer to publish to all platforms, develop-once-run-everywhere, ...
Looks like you're looking for one "The Reason" - but there doesn't need to be one. If a layperson like you or me is able to provide 5-10 reasons, then its likely there could be 100-1000 reasons internally, and all of them add up.
> 2) iOS apps on OS X. Why? Does anybody want this?
Of course yes. As an app developer and as a consumer - convergence and bringing my apps and data across all platforms is no longer an "optional" thing anymore, its mandatory even for a ToDo list app, or email, or IM and everything else. Web apps suck at power efficiency - see the situation with Slack/Electron/Chrome/others on desktop, especially when it comes to stuff like hardware bound work (video/audio, digital image and movie processing, hidpi wor and much more).
If you don't need all this, and all you need is just a chromebook with a browser, its fine, it has and will keep working. It also ties in to why you're confused "why this is required" in so many ways. You may not be the target audience here.
> 3) Given the hellscape of bugs currently present in iOS/macOS, does anybody have faith that Apple is going to be able to navigate a rewrite of macOS on this scale?
This one answers itself. If a fragmented platform doesn't work and has lots of bugs - then it makes all the more sense to invest all resources in one platform/arch to have better focus and lesser bugs to tackle. Everyone doing rewrites know that there will be short-term pains, but that has to be balanced with the larger picture - otherwise we'll just keep hating new releases but there will be no solutions other than "let's do only bug fixes for next 1-2 years" aka platform stagnation, and users still won't be happy :)
Good point on 1) -- basically, Intel has produced enough problems for a high enough cost that there's reason enough to try alternatives.
On 2)... I hate web apps. Probably much more than your average layperson. Electron is miserable in my experience -- laggy, high memory/CPU user, non-native feel, but I think a web app in a browser is OK. There are really two different use cases I see here.
a) Take TurboTax, for instance. I don't want to download a TurboTax app for my computer. I'd only use it once or twice a year. But it works well in a browser. It's complex enough that a web app is justified.
b) Spotify. It needs to interact with local files, and I usually have it up in the background. A web app doesn't work well for this. Unfortunately Electron doesn't work well for this either.
I think if this is executed well it could be amazing -- what if layouts scale beautifully onto a laptop screen, so I can use an iOS app instead of an Electron app for Spotify/Slack/etc? If this happened, the benefits could trickle down into iOS, making it a more useful platform. On the other hand, layouts might not scale well for larger screens, and iOS apps on macOS could end up neutered and even less useless than a current webapp. Hopefully the former case happens, but lately Apple makes me feel like the latter is more likely.
3) I'm not really convinced that this will reduce bugs. In my experience, combining two pieces of software into one just makes the resulting monolith harder to reason about because it doubles complexity at high levels and increases complexity exponentially at low levels. But maybe that says something about my development skills :)
>So what's the benefit? Just vertical integration, I guess? Escaping Intel's backdoors and high prices?
Yes, and perhaps better power/performance ratio. Possible iOS binary compatibility as well.
It should be an easier transition than from PPC -> Intel, since at that time, most big apps used CodeWarrior and had to transition to XCode along with the architecture move.
If I read that correctly, I don't know where you're extrapolating that Apple is making this move to replace macOS with iOS / a walled-garden where nobody can create apps for Mac except by selling them through the App Store. If Apple wanted to do that, they would just sell iPads and stop selling MacBooks.
As for 2), I think that's a nice convenience - if you're a developer you wouldn't have to to worry about emulation.
> does anybody have faith that Apple is going to be able to navigate a rewrite of macOS on this scale
Is it really that crazy they would rewrite parts of their OS to target a new architecture? A large undertaking sure, but not that ridiculous... This is Apple, not some random startup lol.
Absolutely true-- Apple is, after all, one of the most valuable companies in the world. But I think recent issues in iOS and macOS hint that they might not be one of the most talented software companies in the world. If regular maintenance and feature updates are bringing their OSes to their knees, what will a massive spec change do?
Random, probably not true thought: large portions of their OS developers have been working on this rewrite, hence leading to the "increase" of bugs on macOS right now.
“2) iOS apps on OS X. Why? Does anybody want this? The way I see it, web apps are perfectly adequate for the desktop environment when it comes to stuff like checking my bank account or browsing Hacker News. I don't want to deal with a desktop app to do any of the stuff I can currently do via a browser. Is there actually a use case?”
Right now many new desktop apps are just badly ported web apps wrapped in electron. They are slow and eat a lot of memory as all of their UI is a being rendered in a glorified standalone chrome tab.
This is less about iOS apps on OSX and more about making it easier for the iOS developer ecosystem to build desktop apps.
Right now it’s web teams that are building desktop apps because for most companies it’s too expensive to hire a dedicated desktop team. Even big apps like slack/WhatsApp use electron.
Making it easier for iOS developers to build desktop applications with the APIs they currently use should hopefully lead to higher quality apps.
I avoid installing apps for most sites, but I kind of remember in the early days, anyway, people were just sneaking a Web view in there for most of the functionality in many apps.
If you can build an iOS app, you can build a macOS app too.
Electron apps are not built by iOS developers, but by developers like myself who would rather hit 3 birds with one stone ;-)
And no, nothing would change, except the MacBook will get to be even more shitty. We'll remember fondly the MacBook Pro of year 2015 as the last model that didn't suck.
The best case scenario is that Apple has cooked up some sort of awesome translation layer between the Cocoa Touch APIs and Cocoa, letting iOS apps function almost like native macOS apps. Hopefully this will happen. But I won't let it go past hope.
I think the first step is to produce a GPU that integrates well with Intel CPUs. The next Metal version will need to have even deeper hardware integration while external GPUs support will be a solution for those who need AMD or NVIDIA solutions.
Tim Cook has repeatedly stated that the iPad is "the clearest expression of our vision of the future of personal computing" and Apple only sells around 4M Macs per quarter, while iOS devices dwarf this stat. If their plan is to continue moving users from desktop/laptop devices to their iOS ecosystem, and the software can be transformed to cross between both classes of devices, then it only makes sense to unify the processor architecture as-well. Especially considering the expertise they've brought in-house to accomplish this, and the success they've demonstrated with their "A" service of chips, complemented by some of the specialized co-processors which have begun popping up in their accessories.
I still expect that they'll offer devices in traditional form factors -- laptop-like devices and desktop devices, if the market demands this. But for most users, they don't care what's inside if it let's them accomplish what they're trying to accomplish.
That said, CPUs have gotten so cost effective that it makes possible something which has come in and out of favor for a while, which is a network of devices that do one thing co-operating as a larger system.
So lets say you buy your "iDisk" which is a storage brick that you can put on a short range wireless network. A couple of iPad monitors, a wireless Apple keyboard, and a wireless Apple mouse. You set up this box of stuff and arrange it around on your desk and it is essentially a "single" computer system perceptually which, running a development "app" could work fine for development.
I can't take that seriously without them demonstrating an equal amount of work on the software end of the iPad. I am a huge believer in the potential of the iPad -- I was blown away by the original iWork and even more so by Garage Band, they both demonstrated honest attempts at providing differentiation from the desktop computing model. But then they just kind of ... stopped developing the OS and associated apps. We all forgave them for making iPad iOS just a bigger iPhone iOS at first because they were otherwise firing on all cylinders, but then they proceeded to continue ignoring this OS for over 5 years, only now providing what is in my opinion the absolute bare minimum features to make working on the iPad tolerable (multi-tasking, etc.)
It appears that Apple, at least when it comes to the iPad, is increasingly unwilling to deliver new software that isn't explicitly tied to a new piece of hardware (and thus a hardware sale). We got writing APIs in order to sell $99 Apple Pencils, but never an actual vision for what it would really mean to do professional work on the iPad. And at some point, it stops seeming like there's some master plan waiting to be unveiled just around the corner. The iPad has been around for 8 years and the fundamentals of using one have largely remained the same, the same as the original subpar experience we excused since it was obviously a 1.0 product. The iPad has basically gotten thinner, faster, and gotten a pencil (which don't get me wrong, is great). iPad sales reflect this: iOS DEVICES may be doing amazing, but iPad sales have plateaued or declined repeatedly. Apple seems eternally confused by this, as if they think the product is done. They begrudgingly offer a "new" iPad with older parts and slightly cheaper price as if people just don't get what they're missing.
But what's missing is a message, a message other than "this is obviously the next iteration of the computer, why aren't you buying them even though we hardly update the Mac either?". The message and vision would inspire Apple to lead by example in the software they produce for it.
The last few years of iOS development have arguably added more big features to iPads than iPhones. Split screen, picture in picture, new gestures, drag/drop, new multitasking workflows, Pencil, etc.
Yeah, it felt a little stuck for a while, but iPads are ridiculously more useful and viable as work platforms than they were in the iOS 8/9 days.
More importantly, Apple has clearly demonstrated several times that they want to own a fully locked down platform where they approve any piece of code and collect percentage from every sale.
iOS devices are that - everything from DRM protected hardware to app store apps pays tax to Apple. Users of desktop platforms are resistant to that (Mac App store failed) it's easier to just introduce a larger iPad to push people over.
I don't see why a separate desktop device is needed at all.
Give us a MacOS-like desktop mode. We could connect a mouse and keyboard using bluetooth. We could airplay to a display. Even better, replace lightning with thunderbolt so we can connect our phones to an external GPU.
AMD has the rights to produce x86 compatible CPUs. If Apple were to design the chips but AMD manufactured them on contract, would that avoid IP/licensing issues with Intel?
No. Without an architectural license Apple can't design chips without being sued. They could set up a partnership though, similar to Zhaoxin, a joint venture between VIA and the Shanghai Muni.
AMD does not manufacture anything, they've gone 100% fabless. Their former manufacturing arm had been spun off into https://www.globalfoundries.com, which also absorbed IBM's fab tech.
Yes. I am finding it almost bemusing that people are dancing so delicately around the only rational possibility here: A semi-custom AMD-produced x86-64 CPU, very much like the Samsung-produced A-series ARM CPUs for their phones and tablets. I see zero reason that the next Axxxx chip cant be a rebranded Zen core with Vega GPU and custom Apple IP magic sprinkled in - https://www.amd.com/en-us/solutions/semi-custom
Just because Apple says they are done with Intel and are making their own chips, does not preclude the possibility that they are simply working with a different x86 vendor on a custom/semi-custom design.
I see zero way Apple gets off the x86 architecture in the next few years, simply due to the tremendous software ecosystem that has grown up around the platform since the switch from PowerPC. They would have to offer a dual path for years to get their larger software partners prepared.
That’s a lot of fuss for at best a lateral shift, and a step down in the all-important performance-per-watt metric (Zen and Vega are totally unproven here).
You may be underestimating the possible paths Apple has to a) transition software developers quickly with better tooling, and b) provide sufficiently performant JIT / compatibility layer by sprinkling a bit of x86 compatibility into future A-series chips, and you’re certainly underestimating the value in c) reducing complexity on the software-side.
Apple is already making their own GPU and CPU and throwing all their weight behind that, why would they hop onto the (brilliant but rather unreliable and on mobile totally unproven) AMD train?
That’s assuming Apple manly uses existng core designs from AMD etc and doesn’t significantly contribute improvements for their own systems, to gain advantages over the chips available to their competitors. But surely adding a hefty dose of their own secret sauce would be the only thing that would make such a move worthwhile?
What’s being suggested is not that Apple use AMD designs. It’s that Apple partner with AMD in order to gain licensing cover for their own largely or completely in-house engineered chips.
Hah, now that you mention it does seem like a huge chunk of the community is in high school. When I went to college I just got a real Mac and it is 100x better than the MSI Wind I used to use (though that was a great device too!).
It's actually pretty astonishing how easy it has become to churn out a decent, stable desktop hackintosh. This announcement seems to give them a four or five year lifespan.
While a x86-ARM translator of some sort is certainly possible, keep in mind that Xcode added support for BitCode back in 2015, which means that binaries are uploaded to the App Store in LLVM IR and compiled to the target architecture by Apple. While this will not cover 100% of Mac OS applications out there, it will certainly minimize the effort of porting stuff to ARM MacBooks.
I wouldn't assume that Bitcode is a huge help with this. Per Chris Lattner in the linked transcript, "It's useful for very specific, low-level kinds of enhancements, but it isn't a panacea that makes everything magically portable."
Apple has been preparing itself for independence from underlying CPU arachitecture for a while. In WWDC 2015[1], they announced bitcode. All App submissions to AppStore are compiled to to bitcode. This allows Apple to re-optimize/re-compile your app binary in the future for newer hardware without the need to submit new version of your app to the store.
This allows Apple to switch to intel chip on iPhone, or switch to an ARM chip on MacOS.
> This allows Apple to switch to intel chip on iPhone, or switch to an ARM chip on MacOS.
I think you're assuming way too much. Says Chris Lattner regarding Bitcode, "It's useful for very specific, low-level kinds of enhancements, but it isn't a panacea that makes everything magically portable." [1]
Similar to how Bell Labs Inferno worked. The kernel to user space interface was a register based VM called Dis. The entirety of user space was written in Limbo, the predecessor to Go (Both designed by Rob Pike), which allowed the whole of userspace and thus the bulk of the OS to be completely CPU independant. A JIT kept things speedy and performance penalties were about 30%. So your entire OS stack was CPU independent which allows applications to be written on an X86 machine and then ran on an Arm box with zero recopilation. True write-once-run-anywhere.
I have it built on my raspberry pi B+, Linux 32bit chroot, and there is a prebuilt Windows image available that you unzip and run.
I saw the light when I read the plan 9 intro. And Rob Pike was right, The operating system still maters. In fact, I'd say it's more important than ever in the age of towering software stacks. We live in the distributed internet age but are hamstrung by 60's OS design.
In theory an LLVM-based bitcode-like system could allow Apple to change CPUs and automatically recompile App Store binaries without developer intervention, but their current bitcode system does not support that.
I just checked the app store on my Mac. I have just 1 application installed from the app store: Xcode. Even then that's just because Apple makes me have it installed to have command line tools such as git.
I think it's safe to say that the vast majority of applications (Microsoft Office, games, browsers, text editors, IDEs, etc.) installed on Macs are sourced from places other than the app store.
They are absurdly competent with CPU design. The A series chips are already matching or even surpassing the performance of lower tier Intel chips. Keep in mind these chips were first introduced IIRC in 2011 with the iPhone 4S, are designed to be passively cooled (no fans) and are limited by the battery constraints of iPhones and iPads. They could conceivably 'scale them up' for laptops and desktops and get a significant performance boost.
Keep in mind that the Geekbench benchmark measures the unthrottled performance. Whether the phone is passively cooled or has a 200 TDP Fan strapped to it doesn't matter.
1,136 comments
[ 2.4 ms ] story [ 395 ms ] threadApple's switch to PowerPC which gave them a performance lead over Intel for five years and kept them competitive for another five or Apple's switch to its own ARM Core designs which have given them a 12-24 month performance lead over the entire Android ecosystem?
Bear in mind that Apple dominates the high-end desktop / laptop market, both in market share and profit share* which could put a huge dent in Intel's economies of scale for high end consumer CPUs.
* I'm assuming these figures omit servers. Also, there was a lot of noise in around 2009 saying that Apple had over 90% of the high-end PC market, but I've not seen more recent figures one way or another. Given that PC prices seem to have, if anything, slipped, I doubt it's gotten worse for Apple (and goodness knows the tech press loves any statistic that makes Apple look bad).
The problem with switching to a different architecture is that if it falls behind Intel, people will say "not as fast as a PC." If you stay with Intel and it falls behind, people say nothing. It's risk vs. no reward.
With their focus on iOS vs MacOS, this doesn't surprise me. MacOS will simply die once they port their tools to iOS.
Terrible choice IMO.
If they had any doubts all they had to do was say nothing -- which is their strong preference -- and it would have remained clear that the Mac Pro was dead.
Making a strong "trust us, we're working on it" statement and then canceling would be a pretty bad unforced error. Not impossible, but with their top-down, forward-looking decison-making process it seems very unlikely to me.
It's much more reasonable that they'll do a "best effort" in the high end space but it won't be comparable to a Xeon. You can see the iMac Pro as a prelude to that. A beefy machine to be sure but not what you'd expect for top of the line.
But if they really are committed to the Mac Pro (and if this rumor is essentially true), then they must be planning something pretty extraordinary:
1. They actually have a solid plan on how they are going to make CPUs competitive with Intel Xeons over the next ~2-4 years.
2. They're planing on a bifurcated line, where some Macs have Apple CPUs and some have Intel CPUs... presumably with different architectures. I guess 2b. would be that the Apple CPUs will actually be x64 compatible.
It all seems pretty crazy, but Apple has done this kind of thing before, and done it rather smoothly. I guess time will tell.
Intel has been iterating their design decades longer and was in stiff competition for much of that time period. They will be hard to catch in the desktop/laptop space for anyone starting with a cell phone CPU.
ARM has not had real competition in their market, most chipmakers are licensing ARM tech, so they should be easier to catch up to, which Apple has done (with a healthy dose of borrowed ideas from ARM).
Before they went to Intel, they were at the mercy of Motorola, which couldn't keep up with Intel.
The problem Apple had with IBM was that IBM didn't care enough about power efficiency to make the chips viable in laptops. They also weren't that interested in fast iterations of incremental improvements.
When the G4 first game out, it was far, far ahead of x86. Apple offered it at 350, 400 and 450 MHz but shipped maybe a few hundred or a few thousand at 450 MHz and a few tens of thousands at 400 MHz. Those computers blew the Pentium out of the water. Intel eventually caught up and passed them purely on manufacturing ability.
Then the G5 came out, which was a beast of a processor. But it never came out for mobile, and IBM only upgraded the speed once or twice before Apple went for Intel.
https://en.wikipedia.org/wiki/PowerPC
PowerPC (with the backronym Performance Optimization With Enhanced RISC – Performance Computing, sometimes abbreviated as PPC) is a reduced instruction set computing (RISC) instruction set architecture (ISA) created by the 1991 Apple–IBM–Motorola alliance, known as AIM. PowerPC, as an evolving instruction set, has since 2006 been named Power ISA, while the old name lives on as a trademark for some implementations of Power Architecture-based processors.
Now that they have the upper hand, they are free to go back to their old ways without much considerations about opennesses.
With the PC sales declining and most OEMs following back to the old ways of integrated computers, before of PC components revolution, I guess most regular users will use follow along.
If the macOS/iOS developers still can get their share of the cake, most things will hardly change, although they might loose those that only use macOS as a pretty UNIX.
The question is how relevant are those sales currently.
Apple will not suffer in 2020 from having lower performance than intel. It wont matter. Form factor, screen quality, memory speed, memory size, touch pad, battery life etc will matter so much more.
Multi threading is also so much more common on pro app which require performance. They can just match intel by using more cores. ARM is way cheaper than intel so I don't see how they can lose this game. PPC was an entirely different world.
The mac mini is essentially 1700 days old since they downgraded the processors.
I only have macs because I build apps on them. I buy used and as inexpensively as possible. Using an old i5 for development currently.
I wanted to be an Apple fanboy, but having to rebuy critical software for even point releases because of stability killed that off for me long ago.
Best Apple I've ever owned (beyond my //e) was the Dual Processor Quicksilver. Case opened on the side, you had many upgrade options and it even looked nice (irrelevant to me but I'm sure that matters to some).
ARM will simply be the new PPC. You think things like supporting external graphics cards (yay they just got limited AMD support) and having high end rigs isn't what people want, especially in the gaming community?
My strategy with any apple news: ignore it until its released or said from the horses mouth. Remember the iphones that had clickwheels like ipod rumors prior to the iphone? Thats what I consider this.
Just like this rumor might be.
It's not just feasible for Apple to develop new microarchitecture from scratch. Kalamata will license ARM technology. New microarchitecture takes 6-8 years to develop and it's huge investment even for companies like Intel, Amd and ARM.
Currently only Intel and Amd have high end desktops CPU's. ARM is likely enter as third with ARM architecture that Apple is licensing, but it will have relatively low performance.
Apple will likely take a hit in workstation markets for CAD and image processing application market but they are in the position to gain a lot in more common use cases if customers get better power/performance ratio.
ARM? Walled garden of an app ecosystem? Command line?
There has been convergence between iOS and MacOS for a while now.
I'm sure this has been going on for a long time behind the scenes. That is what happened when the PPC -> x86 transition became public. Since Apple has it's own ARM chips/fab, I wonder if ARM is where they are going? It would make sense from a couple different points of view: Lower power use and security. Can there be equivalence between the two architectures, meaning would similar CPUs net you a similar workload?
There is much to like about the iOS app store, but there also is much to dislike. Apple is the gatekeeper here, and if they don't like your app, you are out of luck. That's not the case with MacOS, at least not yet. You can still write what ever kind of app you desire for what ever your client base may pay for and Apple can't really do much to stop you. Merging iOS and MacOS would need to address this.
Finally I use the command line a lot. I don't have access to that on my tablet or phone unless I jailbreak it which has it's own risks with doing so. If Apple decides this is no longer acceptable, that will certainly change my choices for getting work done.
Anyone want to chime in on why Intel can't get more than 5% YoY while Apple has been getting 30-40%?
I will probably surpass Pizza Hut's growth in making pizzas this year.
Last year I made just a few, and only this month already two or three!
Compared to other ARM licencees they do beat the pants off of. This is probably why Apple put in a T1 chip and a touch bar in the Macbook Pro and the T2 chip (dedicated power module) in the iMac Pro. They are prototyping the individual pieces with Intel as the main processor so that they can attempt to swap the chip in 2020.
EDIT: nitpick on t1 and t2 chips.
In an iPad profile sure the heat dissipation is very limited. With even a basic passive heat sink (not just a spreader, but actual fins for surface area), much less active cooling like most laptop and desktops use, and the heat profile dramatically changes.
This change was inevitable -- recent A## chips have been just astonishing for passively cooled chips. The state of the art in binary translation, and the support for cross compiling across architectures, makes this a very doable transition.
https://www.youtube.com/watch?v=ctgAzn5Wx8o
If Apple can come up with something like Infinity Fabric, then they could steer the same course.
ARM was nowhere near there (for it had no need to) before modern smartphones. ARM in 2007 was single-issue in-order single-core topping out at ~600MHz.
I'd guess, but I don't know, that Apple's performance growth is coming from two places:
1. More multi-threading. Moble chips in general have been getting more parallel over time. It's pretty easy to construct synthetic benchmarks that benefit from this; it's less easy for general purpose applications, although they are coming along.
2. The GPU is improving. It seems like there is a lot of headroom here to improve. Apple's GPU is almost certainly substantially better than Intel's. This isn't really a huge problem for Intel, because for people who care, they can always get a discrete GPU. Super powerful GPUs can be very impactful for certain applications, but they just don't have general applicability.
In general, I'm pretty skeptical that Apple's CPUs are improving in the necessary areas to enable them to switch their pro lines. Moving over their Air and Macbook products to in house chips seems pretty straight forward.
I wonder what he'd say in this scenario. Not saying "Steve Jobs would have NEVER allowed this apple is going to shit", simply wondering if the effort required to move to x86 should be essentially discarded (depending on the implementation)
Edit: I agree with the replies, they are a good reminder to me of the sunk cost fallacy
That's a good point and a reminder to me of the sunk cost fallacy.
What are the odds that Apple will just internalize x86 production, as opposed to doing a A11-style ARM derivative?
Zero, since it's wildly improbable that Intel would grant them a license to use the x86 architecture.
Moreover, the x64 was created by AMD, not Intel.
Factually wrong. Ask Microsoft. ;)
With the assistance of a veritable phone book of cross-licensing of patents with both Intel and VIA.
My experience with HN comments leads me to believe otherwise, at least among professionals. :)
Microsoft Office was another drag on the Carbon library. They also chose to keep their applications in the old format even though they were told repeatedly from Apple that this thing was going away. Eventually they got their shit together and the Office suite for OSX is a best of show.
Userspace GNU/Linux is also pretty bad about this, despite the effort put in by Linux.
The biggest issues I ran into was always with the low quality edu based applications. So many of the issues we had with those apps were because they were created in Windows and ported half way to OS X, an old PPC version that did something special that the Intel version couldn't do, or the worst one using a special baked in version of Adobe Flash..
/shivers
Asking for friend ;)
The app wasn't a universal binary at the time. Which would be fine if the PPC version worked with the PPC machines, and Intel worked with the Intel machines. haha.
*Edit The windows version did usually work without issues. The OS X version eventually worked once they redid the whole application.
Edit: maybe I should explain a little. We were a educational software developer and doing multimedia titles. We had a home grown multimedia engine which served us well (at the time there weren't alternatives) but Flash came along and at the time they would license the engine as a C or C++ library, which we could embed. This would get us a capable engine with superb integration with the content creation tools.
If your application let students finish what they were doing without randomly crashing and losing everything, then it is leaps and bounds better than the MAP system.
The school had to extend the map testing by 2 weeks just because of how often it crashed and students had to retake it. My coworkers at other school districts in other states ran into the same exact issues. Then on Windows, it had to access a SMB share somewhere to dump data to a flat db... that would get corrupted sometimes when a students application froze up... haha. it was job security though.
Unless you rely on a piece of software that does not receive any updates anymore. Then you're basically screwed. I am rather annoyed that Apple is going to break backward compatibility yet again for no good reason. Intel Mac's perform a perfectly adequate job and Intel couldn't really screw Apple because they are a rather good customer.
Why is it unlikely that Apple would make a x86 chip? Because of IP/licensing, or for technical reasons?
[1]: https://www.idc.com/getdoc.jsp?containerId=prUS43495918
On PPC you could either dual-boot or run OS9 (and 8?) apps seamlessly on an OSX desktop, which was pretty impressive.
The seamless emulation of OSX-PPC apps on an Intel processor was extremely impressive though. I remember the majority of stuff working surprisingly well with little slowdown (though this might now be rose-tinted).
Mac OS 9 inside of “Classic” (the VM that ran OS 9 inside of OS X) wasn’t especially seamless, but what was seamless was “Carbon”, a transitional API that allowed developers to build apps that ran natively on both Mac OS 9 and Mac OS X. It didn’t take nearly as long to port code from OS 9 to Carbon as it would have taken to port to Cocoa, so many early OS X apps were Carbon ports.
Or it could be nothing. This is a pretty thin article.
They definitely do have OSX running on ARM64, they had OSX running on x86 for years before the switch (in fact they had OSX running on x86 before it even was OSX, NeXT ran on x86, SPARC, PA-RISC and 68k, PPC is the one Apple had to add), they've already gone through two architectural migrations (68k -> PPC and PPC -> x86) and by all accounts the iOS core is very much shared with OSX, it wouldn't make sense not to port OSX along the way.
Although NeXTStep ran on x86, the MacOS build on x86 was John Scheinberg's personal skunkworks project until it became Marklar in 2001 (and then kept under the hood for another four years). Mind, Darwin was always written to be portable, but it wasn't a deliberate strategy to take it to Intel. This time around though, I too reckon that they have already a MacBook running on an A10X in the labs.
I'm reminded of the patent-sharing agreement between the two. Or, given MS' diversification, they may be willing to directly license the tech. Making the x64 -> aarch64 translation as robust as possible has benefits for both companies, and they're not nearly the bitter enemies they used to be.
No, they have tech for executing i686 binaries on aarch64, not x86_64. Big difference.
Meanwhile, High Sierra is the last macOS release to support 32-bit binaries.
"Without compromise". We'll see what this means later, but most likely it'll mean that macOS won't ship with a 32-bit runtime and you'll be able to download as you do with Java.
I was just listening to a Windows Weekly podcast about that, and its limited to 32-bit x86 binaries only, no 64-bit support. They also said its "unusable" for 32-bit apps (in particular Chrome), because you can watch the system drawing the windows of x86 apps on the screen.
Watching the video, they seem to be exaggerating a bit with "unusable", but Chrome does look sluggish, and the startup of "DrRacket" and its window redraw does look very slow too.
https://www.youtube.com/watch?v=LfYcCSRMkVI&t=60m55s
Edit: After watching the video, that didn't seem too bad. Perhaps it would work well enough on top of a beefier ARM processor? Of course the lack of x86_64 support is another issue that may not have a reasonable solution.
I know the iPad Pros certainly outperform many cheaper Intel chips while using lower power.
But I doubt they would want to split the line into half ARM half Intel, or move the Mac Pro to ARM.
What pro task, really requires high single thread performance? I imagine Apple could match intel by simply using more cores on their ARM CPUs.
- an iMac that didn't really meet my needs
- a ridiculously unaffordable Mac Pro tower
I jumped over to Linux running on commodity PC hardware.
Only issue I have on Mac is compiling large programs.
I dunno, I feel like the writing has been on the wall for Apple to switch to their own ARM chips, for 3 or 4 years now. At first it was "yeah maybe someday", but by this point, I'm just surprised they're waiting until 2020. I was hoping the first ARM Macbooks would be this summer. (Really, last summer, if I'm being honest).
In 2020 I doubt anyone will see any problems with ARM performance on a desktop or laptop.
Edit: Found the source: http://atp.fm/205-chris-lattner-interview-transcript/#bitcod...
To make their own chips, they'd need to either license from an existing holder (which wouldn't let them tinker unless it was a partnership or they acquired the license) or they'd need to make something so incredibly great the other three would trip over themselves to use it, and bind themselves in the process.
(Price tag would be in the ballpark of $15-20 billion, 3 months of income for Apple)
https://www.kitguru.net/components/cpu/anton-shilov/amd-clar...
In theory, but then VIA is a subsidiary of Formosa Plastics Group, so they'd need to either negotiate the sale with an entity with which they've locked horns in the past or buy an entire petrochemical group???
They'd probably have an easier time buying AMD.
They can't buy AMD (nobody can) for patents as licences on parts of x64 AMD doesn't own will be voided if AMD is ever acquired.
Intel will also lose access to AMD patents.
the article (thin as it is) claims a multi-step transition. Apple almost certainly has a version of Mac OS that can run on their iPad hardware - the transition path that makes the most sense to me is a 12" MacBook that runs essentially the same internal hardware as an iPad pro, and a MacOS that can run iOS apps. There would be a great consumer market for a MacBook that runs iOS apps, and it would serve as a hardware test bed for developers to get their MacOS applications ported over to ARM before transitioning the MacBook Pro lineup away from x86.
https://www.macrumors.com/2015/11/16/tim-cook-no-converged-m...
>We feel strongly that customers are not really looking for a converged Mac and iPad, because what that would wind up doing, or what we’re worried would happen, is that neither experience would be as good as the customer wants. So we want to make the best tablet in the world and the best Mac in the world. And putting those two together would not achieve either. You’d begin to compromise in different ways.
But as a former Surface Pro owner who now has an iPad Pro, I don’t see that happening. The iPad is immeasurably better as a tablet when you have tablet-oriented software available. And when you don’t, obviously the Surface’s compromise of “have a crappy desktop experience too” is usable if you need to have that option. But it’s not good compared to stuff designed for a tablet.
Similarly, the chunks of Windows 10 that are clearly designed for touchscreens (like the new Settings app) are not great on a desktop compared to the older and still more powerful control panel. More consistent, sure, as any ground-up redo would be, but the information density of things like the Add or Remove Programs list is awful compared to what it was before.
I don’t think Apple is going to make those compromises. They might do a more converged developer backened for Mac and iOS to make it easier to target both platforms, but they won’t shove the frontends together.
This, I think, is the most accurate picture of future iOS / Mac convergence. Universal binaries that present either a desktop, tablet, or phone UI based on where they're running.
Microsoft's mistake was trying to converge the desktop and tablet UIs.
Unifying the Mac frontend into that ecosystem just seems like the obvious conclusion.
I don't know that they'd strictly be the same executable, but at least as far as the user is concerned they would be the same piece of software. From a developer perspective, multiple UIs built with slightly different flavors of AppKit depending on the UI paradigm, including the Mac which is currently targeted by AppKit.
iOS doesn’t handle that kind of UI well.
There’s also the cost issue. All but the most exotic iOS apps cost less than $100. Many professional apps cost hundreds or thousands of dollars.
It’s not just a fundamentally different market. The products are fundamentally different in critical ways.
I can imagine a hybrid MacPad product - maybe a dual-panel clamshell - but if it’s done badly it would be the worst of both worlds.
I auspect it could a succesful replacement for the iOS product line, with dual MacPadOS and iOS support.
But I can’t see it working for professionals without a lot of breakage.
If it didn't need a totally separate UI framework, ports like this would take less effort and more apps would do it. Maybe you can't sell it for 6x the cost any more, but a comparatively small amount of work gives you a leg up on the competition.
Twitter is another example. They killed the native Mac client earlier this year and said "For the full Twitter experience on Mac, visit Twitter on web."
It's also worth noting that when he said that, Chromebooks didn't run android apps.
https://www.macrumors.com/2018/01/31/apple-still-plans-combi...
Putting an ARM processor in a Mac does absolutely nothing to change the viability of running iOS apps on a Mac.
iOS developers always compile, test, and debug their apps on x86. The challenge of running iOS apps on x86 was solved 10 years ago.
What's stopping Apple from shipping Macbooks with a custom SoC that can run existing Apps in emulation until developers can recompile? I would argue that most Air and Macbook owners aren't developers and probably don't have many apps that didn't ship with their system.
The processor doesn't matter.
But compare the Intel Core m3 to the Apple A11, and a completely different story will emerge. The A11 is already comparable to relatively recent Macbooks in terms of performance.
The current A11 chips for iPhones are within 10% of Intel's top mobile chips on Geekbench, and within about 30% on their top desktop CPUs.
It's entirely possible for chip architectures to see 2x-3x speeds when moving from mobile power budgets to desktop power budgets.
An Intel Pentium 4410Y Kaby Lake running at 4.5-6 Watts gets about 1800 single-core on Geekbench, while an Intel Core i7-7700K Kaby Lake running at 115 Watts gets 5600 single-core on Geekbench.
No, they aren't. iPhone X's multithreaded geekbench score is 10k. The 15" macbook pro is 15k. That's a lot more than 10%. It's only close if you look at the lower end Intel chips, the dual core ones (which is what Apple ships in the 13" macbook pro).
What do you think is the most important for 250million desktop users? Because the vast majority of them are sitting idle waiting for interaction tasks, like on your system now.
My dual Xeon E5-2690 v4 regularly loads all its cores and benefits greatly from them, but keep making assumptions by all means.
But if all you want is a chromebook competitor then sure, A11-class works fine. I'm going to guess that the people using Mac Pros tend to care a bit more about just running Chrome/Safari, though. Maybe Apple is just going to completely give up on their historically strong content creation market.
Keep in mind that while you don’t see much 68k outside embedded these days, you still see POWER in supercomputer rankings, and it also appeared in game consoles.
If Apple ends up doing it, the proposition would almost certainly be different and it seems very unlikely it would involve things like running your x86_64 macOS apps on your brand new Mac except three times slower. Thinking about this in terms of previous changes (or in terms of PPC history details) just seems obviously wrongheaded to me.
The Macbook Core i3 is barely enough to run Safari or iTunes and Apple could probably replace the CPU without many of those users ever noticing.
They will not compete at the high end against the Core i7s with 6 cores running at 3.8GHz (12 with HT) though.
The market segment isn't that large though so it seems tough to get it done within the laptop budget. Still, it could benefit the other devices and streamline the hardware development, so maybe they think it's worthwhile.
I don't think we can make that assumption here. I would be very surprised if the ARM chips they put in desktops are identical to the ones they put in phones.
For one, the power budget is going to be a lot larger (even for a notebook), and power is roughly equivalent to speed.
https://browser.geekbench.com/mac-benchmarks
> iMac (27-inch Retina Mid 2017) | Intel Core i7-7700K @ 4.2 GHz (4 cores) | 5683
https://browser.geekbench.com/ios-benchmarks
> iPhone 8 | Apple A11 Bionic @ 2.4 GHz | 4217
4217 for Apple A11 @ 2.4Ghz vs 5683 for Intel Core i7-7700K @ 4.2GHz
Of course, microbenchmarks don't mean much. But the margins are thin enough for users to notice already. Add in more power, more cores, more Ghz, better optimized instruction set, more vertically integrated system, and who knows.
Geekbench is not at all a reliable benchmark that tells you anything about real preformance.
Its a total farce to suggest that a CPU with a power budget that is 10x to 20x larger, on a modern process, with modern archtecture is somehow just as fast or slower.
I have no doubt some customers were caused pain by the transitions, and some left the Apple world entirely, but characterizing them as being "fucked over" seems a bit over the top.
1) Old programs don't work, because it is a different CPU architecture. 2) Old programs work, but in a VM, so it can't take full advantage of the hardware. 3) Old programs must be recompiled to work on new architecture.
The last one is the preferred option, but is only possible for open source software. If options 1 or 3 are taken for proprietary software, the customer needs to buy a new version of the software.
Look - Apple or any other vendor isn't beholden to one CPU architecture. Such expectations breed monopolies - like Intel in PC CPUs.
None of your arguments prove that Apple is fucking over customers or developers. If anything, this opens up the market for newer, more nimble companies that'll fill the gaps left by slow moving, irrelevant apps/software.
Cheers
I agree that vendors are not beholden to a CPU architecture, but let's not pretend that switching is immediately beneficial to the user. What you call "opening up the market", I call adding unnecessary obsolescence to programs that chose not to add planned obsolescence in the first place.
If anything, I would take this as further evidence that software should be sold as source code, because the utility of mere build artifacts can be taken away.
Then there's your contrived reason to obtain source code - another bogus, non-sensical reason that'll never fly with devs.
You always have the choice of staying with an older model, or better, using Linux on your custom hardware. Don't push your socialism/communism on one of the most capitalistic companies on Earth (Apple)
The PPC transition and Intel Transition both had emulators, fat binary support, and for the Intel transition, early access to developer hardware [1]. I’m not sure how much more you can ask of Apple. The current iOS simulator compiles to native Intel code and then builds for deployment use the appropriate CPU target. The tooling is mature and the execution know.
Apple can certainly do better in a lot of areas, i.e. Swift examples that are either missing or are too old to compile. This is something they’re competent at.
[0] https://arstechnica.com/staff/2008/04/rhapsody-and-blues/
[1] http://vintagemacmuseum.com/the-apple-developer-transition-s...
Compiling for different architectures was a checkbox in ProjectBuilder (after you took care of endian issues, once). Much easier than in Xcode today.
My favorite was that they apparently shipped an additional architecture by accident: the developer tools came with one of the aforementioned architectures long after it had been officially dropped.
"Spreadsheet macros" were like hot personal computing shit in 1983. Really not good if you cannot create them in 2008. , (Few complaints about the current Mac MS Office, FWIW) I'm just saying that breaking old stuff often takes year to fix.
Emulating that requires a massive performance hit, because you essentially have to check every single memory access to make sure its not doing something invalid on ARM.
Google didn’t answer that for me, but I found out that there now is a ”cp15 sctlr[1] (alignment bit)”. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.... says this about it:
”3.5.1. Alignment faults
If alignment fault checking is enabled (the A bit in CP15 c1 is set), the MMU generates an alignment fault on any data word access if the address is not word-aligned, or on any halfword access if the address is not halfword-aligned, irrespective of whether the MMU is enabled or not. An alignment fault is not generated on any instruction fetch or any byte access.”
A lot of x86 code is aligned for speed already so it's a pretty safe bet to assume alignment and fix it up if wrong.
Will it be that simple? Apple's own Logic Pro ships with a lot of legacy products from Emagic days. I know they've re-skinned a few with the last couple releases, but I'm guessing a lot of the DSP code is still the same.
I concluded ARM was fast enough for 90% of users. Once you don't have the restriction of battery life and small enclosure it is not hard to imagine that Apple could beef up ARM a lot for their desktops and laptops.
Why run multiple CPU architectures when one does the job and is much cheaper?
I've been thinking hard about what kind of workload ARM can't handle and I can't think of anything. Ok... there is one 1st person shooter games. But iOS is a more successful gaming platform than Mac.
Not necessary. They only need to ship one model of Mac Mini or any small desktop lineup with Ryzen to improve their negotiating position while still being compatible with the existing x86_64 ecosystem.
So no, this is not merely a negotiation jibe. There are definite long-term prospects.
We're already moving to a mobile-first design and approach world. Having those mobile/tablet apps expand automatically to desktop is the next logical conclusion. As an app developer, there is nothing better than write-once-run-everywhere, and the cascading effects of that on the whole Apple ecosystem and future consumer audience is hard to understate. Keeping aside power, efficiency, device prices, opportunity costs and much more.
> significant work by third parties outside Apple who haven't even heard of the possibility of this happening until today.
Definitely not today. Its been speculated for many years now ever since the A4 chips, and its still not official news. Usual "people who don't want to be identified". If or when this becomes official news, most partners would be like about time, because everyone is in one way or another working on convergence and multi-device. Adobe and Microsoft are examples of pivoting many of their desktop businesses successfully to cloud and apps already.
Thankfully Apple comprises vastly smarter people than me, but I've always thought this is a bad idea.
The two interaction models are so dramatically different that I don't see how merging them makes sense. A finger is not a mouse.
There are no good or bad ideas :) Its all about time, place, knowledge of tradeoffs, execution, business, marketing, taking into account all stakeholders (user is one of them) and everything holistic :)
What you say is true, a finger is not a mouse. But we're now a decade past the release of iPhone, and by this time, the industry in general (and Apple in particular) have deep knowledge about all the tradeoffs involved here. 5 years before and this can be considered a reckless bet that requires a Steve Jobs to pull out. Now, its just natural evolution. Responsive design has been around for even longer, and changing interactions based on screen and form factors is a pretty mature problem domain now.
To be very specific:
- whether its a finger or mouse can be a runtime decision, not necessarily a compile-time or clean-slate/distribution decision for different platforms
- those decisions are already standardized enough based on existing knowledge that you can let the platform/framework (or 3p libraries) handle it out-of-the-box for you and just register multiple possibilities. instead of debating finger vs mouse - think finger and mouse
i.e. different interactions requiring entirely different apps - is not necessarily true for all of them. for a 2D application, some amount of standardization is actually good, otherwise it doesn't really help all the interaction patterns and may instead stagnate them.
Is my anecdotal too far off?
If you look at the PPC->Intel timeline[1], Apple announced it 6 months in advance, although it went fairly quickly after that.
1: https://en.wikipedia.org/wiki/Apple%27s_transition_to_Intel_...
Doesn't all have to happen at once, and Apple has been though this before in the PPC-Intel switch, which went rather well.
It'd be perfectly valid to write an application for the MAS in x64 assembly, if you want, as long as it's sandboxed and doesn't touch any private APIs.
This announcement is hardly a surprise. The writing has been on the wall for at least the last 5 years since LLVM replaced GCC in XCode. It became even more obvious when Apple started compiling to "Bitcode" so that they could deliver optimized binaries to devices. What that replacement meant is that it would ease Apple's transition away from any particular architecture - developers shouldn't have to do much if the app is installed from the App Store.
These weren't clear signs of an upcoming ARM switch:
• Apple has been purging software that's under the GPL for quite a while now, and GCC was probably high on the list since Apple (NeXT) had been bitten by its license before[1].
• The Intel switch in 2006 was extremely smooth even using GCC.
• Bitcode is not enabled on macOS, and even if it were, it's not abstract enough to recompile an x86 app for ARM[2].
[1] https://news.ycombinator.com/item?id=9158017 [2] https://news.ycombinator.com/item?id=9728162
When I say that, I'm thinking of the old TED Talk by Amory Lovins called "Winning the Oil Endgame". I feel like there's some parallel one could draw between peak oil and process improvements. Intel has slowed down now that it's more difficult to extract increased performance with each iteration. I'm guessing someone at Apple is thinking about where they'd like to be positioned when the well runs dry.
> "Apple is working on a new software platform, internally dubbed Marzipan, for release as early as this year that would allow users to run iPhone and iPad apps on Macs"
Two things here:
1) I'm OK with breaking the Intel near-monopoly on x86. I'm not OK with moving to a walled garden where Apple forces you to publish apps through their App Store with a paid dev account, etc. just for the privilege of users on their platform. ARM doesn't necessarily mean this, but it is a different CPU arch. When Apple transitioned to Intel/x86 from PowerPC, Intel processors were performant enough compared to PowerPC processors to provide a pleasant emulated PowerPC environment for applications build for PowerPC. I don't think that a switch to ARM would provide this benefit, and afaik Intel's mobile offerings aren't that far off from ARM efficiency. So what's the benefit? Just vertical integration, I guess? Escaping Intel's backdoors and high prices?
2) iOS apps on OS X. Why? Does anybody want this? The way I see it, web apps are perfectly adequate for the desktop environment when it comes to stuff like checking my bank account or browsing Hacker News. I don't want to deal with a desktop app to do any of the stuff I can currently do via a browser. Is there actually a use case?
3) Given the hellscape of bugs currently present in iOS/macOS, does anybody have faith that Apple is going to be able to navigate a rewrite of macOS on this scale? It sounds like the sort of thing that requires a lot of talent and a lot of focus. Apple has the capital for this, but not the environment, imo.
Seems to me like this could be the nail in the coffin for Macbooks that's been pending since the merger of the macOS/iOS teams and the introduction of the controversial TouchBar/USB-C Pro.
Also, the Microsoft Surface Book Pro has a detachable screen that is a stand alone tablet. What if Apple is designing for an iPad to be the main screen with a base that houses external GPU, battery, keyboard, etc. iPad production ramps up, iPad users can "upgrade" to a full laptop, laptop users are automatically in the iOS eco-system.
I'd join you in that minority.
Inn their current yearly OS release cycle? Nope, not at all.
You're already scratching the surface: vertical integration, backdoors and high prices, power and battery life optimization, lesser effort for an app developer to publish to all platforms, develop-once-run-everywhere, ...
Looks like you're looking for one "The Reason" - but there doesn't need to be one. If a layperson like you or me is able to provide 5-10 reasons, then its likely there could be 100-1000 reasons internally, and all of them add up.
> 2) iOS apps on OS X. Why? Does anybody want this?
Of course yes. As an app developer and as a consumer - convergence and bringing my apps and data across all platforms is no longer an "optional" thing anymore, its mandatory even for a ToDo list app, or email, or IM and everything else. Web apps suck at power efficiency - see the situation with Slack/Electron/Chrome/others on desktop, especially when it comes to stuff like hardware bound work (video/audio, digital image and movie processing, hidpi wor and much more).
If you don't need all this, and all you need is just a chromebook with a browser, its fine, it has and will keep working. It also ties in to why you're confused "why this is required" in so many ways. You may not be the target audience here.
> 3) Given the hellscape of bugs currently present in iOS/macOS, does anybody have faith that Apple is going to be able to navigate a rewrite of macOS on this scale?
This one answers itself. If a fragmented platform doesn't work and has lots of bugs - then it makes all the more sense to invest all resources in one platform/arch to have better focus and lesser bugs to tackle. Everyone doing rewrites know that there will be short-term pains, but that has to be balanced with the larger picture - otherwise we'll just keep hating new releases but there will be no solutions other than "let's do only bug fixes for next 1-2 years" aka platform stagnation, and users still won't be happy :)
On 2)... I hate web apps. Probably much more than your average layperson. Electron is miserable in my experience -- laggy, high memory/CPU user, non-native feel, but I think a web app in a browser is OK. There are really two different use cases I see here. a) Take TurboTax, for instance. I don't want to download a TurboTax app for my computer. I'd only use it once or twice a year. But it works well in a browser. It's complex enough that a web app is justified. b) Spotify. It needs to interact with local files, and I usually have it up in the background. A web app doesn't work well for this. Unfortunately Electron doesn't work well for this either.
I think if this is executed well it could be amazing -- what if layouts scale beautifully onto a laptop screen, so I can use an iOS app instead of an Electron app for Spotify/Slack/etc? If this happened, the benefits could trickle down into iOS, making it a more useful platform. On the other hand, layouts might not scale well for larger screens, and iOS apps on macOS could end up neutered and even less useless than a current webapp. Hopefully the former case happens, but lately Apple makes me feel like the latter is more likely.
3) I'm not really convinced that this will reduce bugs. In my experience, combining two pieces of software into one just makes the resulting monolith harder to reason about because it doubles complexity at high levels and increases complexity exponentially at low levels. But maybe that says something about my development skills :)
Yes, and perhaps better power/performance ratio. Possible iOS binary compatibility as well.
It should be an easier transition than from PPC -> Intel, since at that time, most big apps used CodeWarrior and had to transition to XCode along with the architecture move.
As for 2), I think that's a nice convenience - if you're a developer you wouldn't have to to worry about emulation.
> does anybody have faith that Apple is going to be able to navigate a rewrite of macOS on this scale
Is it really that crazy they would rewrite parts of their OS to target a new architecture? A large undertaking sure, but not that ridiculous... This is Apple, not some random startup lol.
Right now many new desktop apps are just badly ported web apps wrapped in electron. They are slow and eat a lot of memory as all of their UI is a being rendered in a glorified standalone chrome tab.
This is less about iOS apps on OSX and more about making it easier for the iOS developer ecosystem to build desktop apps. Right now it’s web teams that are building desktop apps because for most companies it’s too expensive to hire a dedicated desktop team. Even big apps like slack/WhatsApp use electron.
Making it easier for iOS developers to build desktop applications with the APIs they currently use should hopefully lead to higher quality apps.
Hybrid mobile frameworks like Cordova tend to get a bad rap these days especially with the arrival of more performant alternatives like React Native.
Electron apps are not built by iOS developers, but by developers like myself who would rather hit 3 birds with one stone ;-)
And no, nothing would change, except the MacBook will get to be even more shitty. We'll remember fondly the MacBook Pro of year 2015 as the last model that didn't suck.
Android apps on Chrome OS tablets are a thing now.
With macOS on ARM, the iPad Pro and MacBook lines merge, as the hardware internals converge.
I still expect that they'll offer devices in traditional form factors -- laptop-like devices and desktop devices, if the market demands this. But for most users, they don't care what's inside if it let's them accomplish what they're trying to accomplish.
What are iOS developers supposed to develop on?
Presumably laptops and desktops with Apple chips inside.
Where do you see that?
That said, CPUs have gotten so cost effective that it makes possible something which has come in and out of favor for a while, which is a network of devices that do one thing co-operating as a larger system.
So lets say you buy your "iDisk" which is a storage brick that you can put on a short range wireless network. A couple of iPad monitors, a wireless Apple keyboard, and a wireless Apple mouse. You set up this box of stuff and arrange it around on your desk and it is essentially a "single" computer system perceptually which, running a development "app" could work fine for development.
The "brick" turned out to be the all-aluminum MacBook, being carved from a single piece of metal.
Maybe someday they'll make a cross-platform Xcode.
It appears that Apple, at least when it comes to the iPad, is increasingly unwilling to deliver new software that isn't explicitly tied to a new piece of hardware (and thus a hardware sale). We got writing APIs in order to sell $99 Apple Pencils, but never an actual vision for what it would really mean to do professional work on the iPad. And at some point, it stops seeming like there's some master plan waiting to be unveiled just around the corner. The iPad has been around for 8 years and the fundamentals of using one have largely remained the same, the same as the original subpar experience we excused since it was obviously a 1.0 product. The iPad has basically gotten thinner, faster, and gotten a pencil (which don't get me wrong, is great). iPad sales reflect this: iOS DEVICES may be doing amazing, but iPad sales have plateaued or declined repeatedly. Apple seems eternally confused by this, as if they think the product is done. They begrudgingly offer a "new" iPad with older parts and slightly cheaper price as if people just don't get what they're missing.
But what's missing is a message, a message other than "this is obviously the next iteration of the computer, why aren't you buying them even though we hardly update the Mac either?". The message and vision would inspire Apple to lead by example in the software they produce for it.
Yeah, it felt a little stuck for a while, but iPads are ridiculously more useful and viable as work platforms than they were in the iOS 8/9 days.
Give us a MacOS-like desktop mode. We could connect a mouse and keyboard using bluetooth. We could airplay to a display. Even better, replace lightning with thunderbolt so we can connect our phones to an external GPU.
Just because Apple says they are done with Intel and are making their own chips, does not preclude the possibility that they are simply working with a different x86 vendor on a custom/semi-custom design.
I see zero way Apple gets off the x86 architecture in the next few years, simply due to the tremendous software ecosystem that has grown up around the platform since the switch from PowerPC. They would have to offer a dual path for years to get their larger software partners prepared.
You may be underestimating the possible paths Apple has to a) transition software developers quickly with better tooling, and b) provide sufficiently performant JIT / compatibility layer by sprinkling a bit of x86 compatibility into future A-series chips, and you’re certainly underestimating the value in c) reducing complexity on the software-side.
Apple is already making their own GPU and CPU and throwing all their weight behind that, why would they hop onto the (brilliant but rather unreliable and on mobile totally unproven) AMD train?
What’s being suggested is not that Apple use AMD designs. It’s that Apple partner with AMD in order to gain licensing cover for their own largely or completely in-house engineered chips.
Even having never built one myself, it remained a last resort of some kind in the back of my mind.
I wouldn't assume that Bitcode is a huge help with this. Per Chris Lattner in the linked transcript, "It's useful for very specific, low-level kinds of enhancements, but it isn't a panacea that makes everything magically portable."
This allows Apple to switch to intel chip on iPhone, or switch to an ARM chip on MacOS.
[1] https://thenextweb.com/apple/2015/06/17/apples-biggest-devel...
I think you're assuming way too much. Says Chris Lattner regarding Bitcode, "It's useful for very specific, low-level kinds of enhancements, but it isn't a panacea that makes everything magically portable." [1]
[1]: http://atp.fm/205-chris-lattner-interview-transcript/#bitcod...
I have it built on my raspberry pi B+, Linux 32bit chroot, and there is a prebuilt Windows image available that you unzip and run.
Not easily. It's optional on iOS [1], and doesn't support completely new (non-ARM) CPU architectures. On macOS, the feature doesn't exist at all.
[1]: https://help.apple.com/xcode/mac/current/#/devbbdc5ce4f
In theory an LLVM-based bitcode-like system could allow Apple to change CPUs and automatically recompile App Store binaries without developer intervention, but their current bitcode system does not support that.
I think it's safe to say that the vast majority of applications (Microsoft Office, games, browsers, text editors, IDEs, etc.) installed on Macs are sourced from places other than the app store.