Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
No, just like the Electron apps that use Private API’s, once they set up their automated server to reject apps that use it, it’s done.
I don't quite know what your obsession with Electron apps specifically is - Apple's App Stores have always rejected apps of all types that use private APIs, and when they're not detected initially, they're removed after, as its against the terms stipulated for the (both) App Stores.

The change suggested is to have a new requirement for submissions: that has zero affect on existing listings in the stores.
 
No. It won't recognize which low power cores in Catalina.
What makes you think that? I don't see why they'd not support it.
[automerge]1585463839[/automerge]
Isn't it possible that this rumor is only half true? Couldn't Apple be working on their own x86 CPU?
Well there's an earlier comment saying this is a mistranslation and really it's about AMD CPUs. I could research more, but I don't care enough.
 
Last edited:
  • Like
Reactions: Unregistered 4U
What makes you think that? I don't see why they'd not support it.
[automerge]1585463839[/automerge]

It's quite possible that Apple will be a lot worse in innovation if Tim Cook does not really understand the future direction of its product. In fact, Apple needs to release an ARM version of macOS for developer and test kit long time ago so it can compile third party app to the architecture instead of waiting for an official launch.
 
No, just like the Electron apps that use Private API’s, once they set up their automated server to reject apps that use it, it’s done.

Except that we have years of older Electron apps in the store. For your suggestion to work, they’d have to prune all that.
[automerge]1585470744[/automerge]
No. It won't recognize which low power cores in Catalina.

It doesn’t need to.
[automerge]1585471145[/automerge]
What makes you think that? I don't see why they'd not support it.

They would. Apps had to do absolutely nothing to support Fusion on iOS, and they would have to do nothing to do so on macOS.

You use a lot of perf, and the OS scheduler will move you to the high-efficiency cores. Just like on Intel, where you use a lot of perf, and it’ll boost the cores. Or you use a lot of perf but don’t parallelize well (or at all), and it’ll shut down cores and boost the remaining ones even further.

That all happens in fractions of a second. There may be APIs to signal intent and optimize even further, but they’re only a cherry on top. They’re not essential.

Heck, 99.99% of apps don’t know or care how many cores you have, or how fast they are. That’s not the app’s issue to deal with.
 
Last edited:
You are still sticking with this faulty logic? Apple literally just doubled the base storage of the Air while *reducing* the price. They did the same for the Mini while maintaining the same price. According to your logic, this was impossible, despite Apple (and every other manufacturer) doing it over and over and over.
It not faulty logic at all. Your faulty logic simply fails to take into account the fact that the price of NAND has been dropping greatly over the past months. This allowed Apple to both increase the base storage on many products as well as reduce the cost of storage quite markedly.

For instance, here is the pricing of the i3/8GB/2TB Mac mini since its introduction:

$2,399 Oct 2018
$2,199 Mar 2019
$1,799 July 2019
$1,599 Mar 2020

Those price cuts are completely decoupled from Apple’s product line pricing strategy.

It’s not really that complicated. Apple can either:
  1. Price the base model on the low side and accept a smaller profit margin on the lower-end SKUs, while making it up on higher priced SKUs; or
  2. Price the base model higher and make better margins on the lower-end SKUs, while charging less for upgrades.
Either way, near identical ASPs and overall margin can be achieved. With the latter strategy, you’ll see a compression of prices from lowest to highest into a tighter range. You'll also price out customers who can’t afford the higher priced base model, resulting in fewer units sold.
 
Developers can already port their iPad apps to macOS. Being arm or x86 is irrelevant to make that port.

having an arm cpu inside doesn’t magically make macOS windowing, multitasking, and the system libraries and frameworks compatible with an app written for iPad.

How many ****ing times does this need to be repeated?

As many times as it takes for the likes of you to consider that it is a possibility.
 
But it's already a possibility for them to do this. Having an ARM CPU in the Mac solves zero percent of the work to port an iPad app to macOS using Catalyst. Literally zero.

Well, I wouldn't say zero, but pretty close. There are gonna be a few apps out there that use ARM-specific optimized code. There might be apps that only work properly on Apple's GPUs rather than Intel's.

But… close to zero.
 
  • Like
Reactions: CarlJ
Well, I wouldn't say zero, but pretty close. There are gonna be a few apps out there that use ARM-specific optimized code. There might be apps that only work properly on Apple's GPUs rather than Intel's.

But… close to zero.
I’d be very surprised if anything currently shipping on iOS is able to use anything cpu or gpu specific given the restrictions on iOS App Store submissions - they specifically want everyone to be using their high level apis.
 
I’d be very surprised if anything currently shipping on iOS is able to use anything cpu or gpu specific given the restrictions on iOS App Store submissions - they specifically want everyone to be using their high level apis.

They want you to, and you typically should, but they don't restrict it. They only restrict private APIs.
 
Given the heat issues in iPads, if Apple goes ARM with their computers: I hope they do consider cooling for all Macs that ship with ARM processors.

That is as much of a worry to me as software compatibility.
 
Which made it so much easier to escape the walled garden.......

I have jumped ship myself to a 16 core Ryzen based system myself, it is nice. My Mac Pro is just used for Zbrush now. When the current unpleasantness is over, I'll get a new copy and retire my last mac.

Why do you use Zbrush on your mac instead of the ryzen system? Just curious as a windows Zbrush user
 
All this it's just clickbait, there's no ARM Mac, or at least won't be an transition to ARM exclusive future.

Few things non programmer and non system architect knows about ARM vs AMD64 (aka x86-64):

IPC myth : not easy to compare, as with ARM you need more instructions to do the same as an AMD64 instructions, many more, while current IPC seems close (at half clock speed) to leading AMD64, things are very different when you run code (real world applications) where you realize you need almost twice cycles in arm than AMD64.

Optimized vector processing, while ARM introduced vector specific instructions in ARM, the truth is are far behind to be as productive as AVX, even maybe even slower as some ARM vector processing sometimes is done by microcode instead dedicated ASICS.

AMD64 future, there are nothing new and undeserved about x86 stagnation and some emerging x86 killers, to date x86 survived: itanium (with AMD64), PoweraPC, N-emulator/virtual x86, and won't be different now that fight among Intel and AMD reignited is not the same to try catch someone sleeping than running to stay alive, this is what's enabled ARM to get close x86-64 but doesn't undermine x86 development, as is not an dead end yet.

Intel and AMD foresee deep architecture changes which I feel ARM won't catch, mostly due development atomization (not the same having 2 big r&d team's than a dozen customizer teams or teams just doing close development (as Apple).

The Cisc/WISC/risc debate this is long, on the paper every strategy has its strength and weakens, but I bet on WISC as the future for Von Neuman architecture, while cisc is almost dead (most x86 CPU actually are risc with Cisc decoders), risc is stagnant beyond vectoring/smt/branch prediction, there's nothing More to improve performance, and is where AMD64 and ARM are doomed to become the same thing, while AMD64 decodes Cisc into risc (a instruction decoder it's an asic moreless the same for every CPU family) then intrude it into the execution pipeline where smt strategies are executed (an smt pipeline just put to work the asic on another thread when a thread is sleeping or holding for I/o) smt may rise tdp about 60%-200% while increase throughput by 1.2x to 2x, vector processing it's 99% the same among x86-64 and ARM, but x86-64 use to have a more extensive set of vector instructions (indeed needing more gates), then comes where more gates are needed in either platform: prediction pipelines, most CPU includes a miriad of ASICS to run certain frecuent code and deliver a result in fewer clock cycles, this is what differentiate a high performance CPU (or s faster core) from a high efficiency CPU (or efficiency cores), you can't have both, as for faster CPUs you need a deeper (or broad) prediction pipeline requiring more gates than for efficiency cores where it's used to avoid this and smt execution.

Why I believe in WISC, as you see either x86 or ARM to be faster needs more gates (almost the same, x86 add the instruction decoder), which indeed make the CPU more power hungry, at the end execution pipeline are just an arbitrary implementation of WISC, but a modern well planned WISC CPU may have the best of both worlds: efficiency and speed, but it's deeply corelate to the code compiler, both have to be planned by the same team, instead to compile a high level code as C or Rust into assembly or relatively simple llvm objects,. The compiler translate it into a "miriad" of specific purpose instructions which don't need to decofe neither prediction branch, certainly the CPU will require a lot of gates for that miriad of instructions but at the end less cycles and more efficient smt, and much better I/o synchronization. The best is WISC CPU can emulate arm/x86 for non WISC inherited binaries, what I've read is the approach both intel and AMD are studying for x86-64 successor.
 
Why do you use Zbrush on your mac instead of the ryzen system? Just curious as a windows Zbrush user

Cost.

There is a 1 time charge to move platforms ($100 last time I looked), but I want the new version. Pixelogic doesn't do upgrade pricing. But the updates go on for years after you have purchased a copy.
 
They would. Apps had to do absolutely nothing to support Fusion on iOS, and they would have to do nothing to do so on macOS.

You use a lot of perf, and the OS scheduler will move you to the high-efficiency cores. Just like on Intel, where you use a lot of perf, and it’ll boost the cores. Or you use a lot of perf but don’t parallelize well (or at all), and it’ll shut down cores and boost the remaining ones even further.

That all happens in fractions of a second. There may be APIs to signal intent and optimize even further, but they’re only a cherry on top. They’re not essential.

Heck, 99.99% of apps don’t know or care how many cores you have, or how fast they are. That’s not the app’s issue to deal with.
Exactly, the other guy I replied to isn't seeing the abstraction here.
[automerge]1585516062[/automerge]
It's quite possible that Apple will be a lot worse in innovation if Tim Cook does not really understand the future direction of its product. In fact, Apple needs to release an ARM version of macOS for developer and test kit long time ago so it can compile third party app to the architecture instead of waiting for an official launch.
Even Tim Cook somehow doesn't know they're switching to ARM, the OS engineers have to know, and they'll make sure the thread scheduler sensibly decides when to use the high-power cores. That's not the dev's job. As it stands, there are lots of decisions like this that the OS or some private libraries make for the programs. Like, it's very rare that you manually select a core to run a thread on. It's also rare that you care how many cores the machine has, what kind of disk it has, or even what the CPU architecture is.
 
Last edited:
Cost.

There is a 1 time charge to move platforms ($100 last time I looked), but I want the new version. Pixelogic doesn't do upgrade pricing. But the updates go on for years after you have purchased a copy.
I thought they scrapped that and gave everyone a multiplatform license?

Copied from the website

"Single seat license of ZBrush 2020.1.1 for both Windows & macOS in digital download format.
Each copy receives a unique serial number which is assigned to a single artist. ZBrush may be concurrently activated on any two computers (Windows or Mac) provided that both copies are never run at the same time. ZBrush may also be easily moved between computers whenever necessary."

I would try and see if you can do it.
 
  • Like
Reactions: CarlJ
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.