SwiftUI Preview on HDD

Has anyone successfully used SwiftUI previews on a machine with a mechanical disk drive?

Both the first and second betas of Xcode have been unable to generate previews on this installation.

Results are any of a variety of errors, extraordinarily long compile times, inability to launch the simulator, a kernel panic or being logged out.


An unmodified project created using the Xcode single-view template simply doesn't work.

The experience is akin to using an ill-behaved Desk Accessory in System 7 :-(


It's unclear whether the problem is with Xcode itself or the Catalina installation.

Wondering if anyone has been through this and resolved the problem?

Replies

A mechanical hard drive is going to be a slower experience than a system with an SSD. For the best performance I recommend using an SSD. Even an external USB3 or Thunderbolt SSD will be an order-of-magnitude faster than a mechanical hard drive.


The preview canvas is driven by Simulator under the covers and we've done some work in this release to improve perf here by adopting a dyld shared cache, but there is a strong upper limit on how fast we can make spinning rust that has to physically move a read head back and forth.

That's.... an interesting reply.


Is the slowness and stalling we experience due to APFS problems that Apple won't "spend any time testing or thinking about"?

If Apple could fix it, every scenario of Mac use would greatly benefit, SSD or mechanical based, regardless of the application.


Can you see there's a problem with promoting this new SwiftUI development model that is only practical on >$5,000 hardware?

Running Apple's internal development exclusivly on hot hardware hides a multitude of sins.

Only a minority of us will have fully loaded iMac or Mac Pros available for development work.


Also, external SSDs have been very troublesome for us so far with Catalina's split read-only drive layout.

The CPU, memory load and disk I/O aren't showing abnormally high usage, but disk traffic just mysteriously blocks very often,

and when you have to split MacOS, Xcode, and a user account because it wont all fit on one drive, development is impossibly painful.


Again, is this an APFS issue that will never be looked at or fixed?


I'm being glib here but our SwiftUI testing so far is nowhere near like what was shown during the WWDC demos.


We need a roadmap and clarity from Apple. Please tell us what is oficially (or unofficially) recommended.

Will we require Xeon-based Xcode machines only, no i7s or less? A minimum of 12 cores? 128GB of RAM?


Are hard drive-based Macs obsolete and essentially abandoned?

Saying that you "don't spend time testing or thinking about" sounds like that's the case.

Let me clarify my last comment as I may have overstated. While the team primarily uses SSDs, we do test across all devices. Our quality engineering team does of course want to track down this particular issue you’re having. Can you please file a bug report so we can keep in contact with you as we investigate?


(You can use Feedback Assistant to file the report and reply with the FBxxxxxx number)

I just bought a new iMac (model 2017) with a HDD, with the intension of being ready for SwiftUI.


Today was the first day, I experimented with Catalina and the new Xcode. And it did not go well.


I began this work, by following the Landmarks tutorial (...), step by step, but did not come far.


When trying to do Preview, compile, or start to run the simulator, my computer just stalled and became very slow.


After several attempts to fix the otherwise, I gave up, and found this blog, which I hope explains the problem.

Will certainly file additional bug reports once the installer team returns from their remedial state machines course and produces a functioning installer. :-( Catalina DP 3 is, as was DP 2 before it, uninstallable for a significant number of users, this one included. Seems unlikely this will change until at least 14 days have elapsed.


For the moment, it's worth noting SwiftUI Preview under DP 1 is the first userland scenario in a very long time I've seen capable of consistenly triggering kernel panics.