If it’s purely to improve build times, then I suggest you don’t. I went from a MacBook Pro i5 2013 to an iMac Pro 3Ghz 10 Core and average build speeds went from 5 minutes to a disappointing 4.5 - I’d expect you’d get a much better bang for you buck with a standard iMac…
I don’t have an iMac Pro, but I do have the maxed out version of the regular iMac.
Watching Activity Monitor, multiple cores are only used during the final stage of the build process when multiple instances of HoudiniAssistant are spun up. I’m sure that if you’re using aggressive optimisation then you’ll see more of an advantage with multiple cores, but I see very little advantage with default optimisation.
Making a debug build of our desktop project takes long enough that I used that time to search Feedback for feature requests to improve this, didn’t find any, and created my own: <https://xojo.com/issue/52782>
FWIW, I’d prefer that Xojo concentrate their efforts on improvements that our customers will see (Android and continued improvements to Windows redraw are at the top of my list) but improved debug build speeds would be a good quality of life improvements for those of us who are actually using Xojo 
Actually, aggressive optimisation adds an additional 30 seconds or so for me…
Sorry Chris, I should have been clearer aggressive optimisation will be slower than the default option, but because that’s the part of the process that uses multiple processor cores then you might expect to see more benefit from your monster machine when you compare it to one that’s less good at multicore stuff.
e.g. our two iMacs might take roughly the same time to do the rest of the compilation process, but your iMac Pro might take half the time to do the final stage because it’s better at multicore processing. However, with default optimisation that final stage only takes ~20% of the time for my large desktop project so it’s not a big time saver.
Thanks for the clarification Tom and the response. Whilst it would be great to see Windows refresh working and Android capabilities, personally, I’d love to to see the compiler running on multi-core. I spend a minimum of 200 minutes a day just looking at a progress bar!
WOW… what kind of apps are you people writing that takes 5 minutes to compile?
I have written a few rather complicated ones in my day… and never has the compile time been over a minute, and that was with the new 64bit in aggressive mode.
Ya I know Dave, maybe too big 
With my 4-5 apps including the dmg I easily get 5 minutes, too, on a relatively fast machine. Thanks the gods for the IDE scripting that spits out everything at once.
I wouldn’t mind building taking that time - it’s just 1 app for me, so it’s running the debugger is the problem. The only work-around that works some of the time is starting a new class in a smaller test project to start the debugging before transferring to the beast! The other workaround is Netflix 
Problem is if I do that I’m not concentrating not really on “what did I want to test last” and also not really on the show running. I’d like to have some (more) parallel structures in my brain 
But compile time has become more and more of a problem - especially when trying to do it in 64Bit. As far as I know the upcoming version of macOS will only accept 64Bit SW, right? Is anyone REALLY sure that I can debug in 32Bit and compile in 64Bit and have the same results - and no other awkward bugs?
I’m not sure when Apple plan to eliminate 32bit, but ever since the OS message warned the users, I’ve gone 64bit for builds and debugging and, yes, it added and 20% or so to the running time of the debugger.
macOS 10.14 Mojave displays a warning when starting 32-bit apps, but they do run.
More information:
Did you notice any changes in behaviour? I depend quite heavily on all sorts of CSV exports of numbers with 4 - how do you say in English “decimal places”? And I remember once a horrible bug that I experienced with a problem between the (US-English) notation of 1,250.4768 vs. the German 1.250,4768 that was XOJO induced and … wrecked a complete month of fiscal relevant documents. I’m sort of afraid of something like that happening when making the step to 64.
Thank you for the link, Paul!
Thanks Paul - I switched straight away, otherwise, it gave the appearance my software was out of date.
I can see how that would put the frighteners on you Jan - I remember changing when 64bit was still beta and loads of stuff going wrong; crashes, incorrect reporting, even gui problems, but this time (v2018), there no problems at all on the same project.
The Xojo IDE is 64-bit now and many people have been updating their apps to 64-bit so I’d say most bugs have been caught and fixed as this point. All you can do now is build your apps as 64-bit and test them. You can install macOS 10.14 Mojave in a VM as well to test with that.
Some tips if you haven’t yet started your 64-bit work: 64-bit Guidelines
But did you have to adapt / change things in order to do that? Or was it just the click in the compiler?
Just the click in the compiler! I was very pleasantly surprised as I thought I would have to change integer to int64 or int32 everywhere, mess around with binary files and have headaches with any of my pseudo cryptos :-/
It depends on your app, of course. Start by just switching the Build Architecture from 32-bit to 64-bit and give it a go. For some apps, that’s all that’s needed.