How fast does your MacBook need to be to comfortably code iOS apps with Xcode? Is a MacBook Pro from 2-3 years ago good enough to learn Swift programming? Let's find out!
Here's what we'll get into:
The CPU — central processing unit — is the engine that makes your Mac go. Currently provided by Intel, they range from the ultra-low-power Core i3 to the ultra-powerful quad-core Core i9 in high-end MacBook Pro and iMac to the Xeon workstation chips in the Mac Pro. Generally speaking, faster cores let you do single things faster. Apple's iMac Pro is the most powerful Mac the company has ever sold, and the best bit of hardware it's offered professionals in a long time. While plenty of tech products have the 'Pro' tag added.
- The minimum/recommended system requirements for Xcode 11
- Why you need – or don't need – a fancy $3.000 MacBook Pro
- Which second-hand Macs can run Xcode OK, and how you can find out
I've answered a lot of 'Is my MacBook good enough for iOS development and/or Xcode?'-type questions on Quora. A few of the most popular models include:
- The 3rd- and 4th-gen MacBook Pro, with 2.4+ GHz Intel Core i5, i7, i9 CPUs
- The 2nd-gen MacBook Air, with the 1.4+ GHz Intel Core i5 CPUs
- The 4th-generation iMac, with the 2.7+ GHz Intel Core i5 and i7 CPUs
These models aren't the latest, that's for sure. Are they good enough to code iOS apps? And what about learning how to code? We'll find out in this tutorial.
My Almost-Unbreakable 2013 MacBook Air
Since 2009 I've coded more than 50 apps for iOS, Android and the mobile web. Most of those apps, including all apps I've created between 2013 and 2018, were built on a 13″ MacBook Air with 8 GB of RAM and a 1.3 GHz Intel i5 CPU.
My first MacBook was the gorgeous, then-new MacBook White unibody (2009), which I traded in for a faster but heavier MacBook Pro (2011), which I traded in for that nimble workhorse, the mighty MacBook Air (2013). In 2018 I upgraded to a tricked out 13″ MacBook Pro, with much better specs.
Frankly, that MacBook Air from 2013 felt more sturdy and capable than my current MacBook Pro. After 5 years of daily intenstive use, the MacBook Air's battery is only through 50% of its max. cycle count. It's still going strong after 7 hours on battery power.
In 2014, my trusty MacBook Air broke down on a beach in Thailand, 3 hours before a client deadline, with the next Apple Store 500 kilometer away. It turned out OK, of course. Guess what? My current MacBook Pro from 2018, its keyboard doesn't even work OK, I've had sound recording glitches, and occasionally the T2 causes a kernel panic. Like many of us, I wish we had 2013-2015 MacBook Air's and Pro's with today's specs. Oh, well…
Learn how to build iOS apps
Get started with iOS 14 and Swift 5
Sign up for my iOS development course, and learn how to build great iOS 14 apps with Swift 5 and Xcode 12.
That 100 Mhz i486 PC I Learned to Code With
When I was about 11 years old I taught myself to code in BASIC, on a 100 Mhz i486 PC that was given to me by friends. It had a luxurious 16 MB of RAM, initially only ran MS-DOS, and later ran Windows 3.1 and '95.
A next upgrade came as a 400 Mhz AMD desktop, given again by friends, on which I ran a local EasyPHP webserver that I used to learn web development with PHP, MySQL and HTML/CSS. I coded a mod for Wolfenstein 3D on that machine, too.
We had no broadband internet at home back then, so I would download and print out coding tutorials at school. At the one library computer that had internet access, and I completed the tutorials at home. The source codes of turn-based web games, JavaScript tidbits and HTML page snippets were carried around on a 3.5″ floppy disk.
Later, when I started coding professionally around age 17, I finally bought my first laptop. My own! I still remember how happy I was. I got my first gig as a freelance coder: creating a PHP script that would aggregate RSS feeds, for which I earned about a hundred bucks. Those were the days!
Xcode, iOS, Swift and The MacBook Pro
The world is different today. Xcode simply doesn't run on an i486 PC, and you can't save your app's source code on a 1.44 MB floppy disk anymore. Your Mac probably doesn't have a CD drive, and you store your Swift code in a cloud-based Git repository somewhere.
Make no mistake: owning a MacBook is a luxury. Not because learning to code was harder 15 years ago, and not because computers were slower back then. It's because kids these days learn Python programming on a $25 Raspberry Pi.
I recently had a conversation with a young aspiring coder, who complained he had no access to 'decent' coding tutorials and mentoring, despite owning a MacBook Pro and having access to the internet. Among other things, I wrote the following:
You're competing with a world of people that are smarter than you, and have better resources. You're also competing against coders that have had it worse than you. They didn't win despite adversity, but because of it. Do you give up? NO! You work harder. It's the only thing you can do: work harder than the next person. When their conviction is wavering, you dig in your heels, you keep going, you persevere, and you'll win.
Winning in this sense isn't like winning a race, of course. You're not competing with anyone else; you're only really up against yourself. If you want to learn how to code, don't dawdle over choosing a $3.000 or a $2.900 laptop. If anything, it'll keep you from developing the grit you need to learn coding.
Great ideas can change the world, but only if they're accompanied by deliberate action. Likewise, simply complaining about adversity isn't going to create opportunities for growth – unless you take action. I leapfrogged my way from one hand-me-down computer to the next. I'm not saying you should too, but I do want to underscore how it helped me develop character.
If you want to learn how to code, welcome adversity. Be excellent because of it, or despite it, and never give up. Start coding today! Don't wait until you've got all your ducks in a row.
Which MacBook is Fast Enough for Xcode 11?
The recommended system specs to run Xcode 11 are:
- A Mac with macOS Catalina (10.15.2) for Xcode 11.5 or macOS Mojave (10.14.4) for Xcode 11.0 (see alternatives for PC here)
- At least an Intel i5- or i7-equivalent CPU, so about 2.0 GHz should be enough
- At least 8 GB of RAM, but 16 GB lets you run more apps at the same time
- At least 256 GB disk storage, although 512 GB is more comfortable
- You'll need about 8 GB of disk space, but Xcode's intermediate files can take up to 10-30 GB of extra disk space
Looking for a second-hand Mac? The following models should be fast enough for Xcode, but YMMV!
- 4th-generation MacBook Pro (2016)
- 3rd-generation Mac Mini (2014)
- 2nd-generation MacBook Air (2017)
- 5th-generation iMac (2015)
When you're looking for a Mac or MacBook to purchase, make sure it runs the latest version of macOS. Xcode versions you can run are tied to macOS versions your hardware runs, and iOS versions you can build for are tied to Xcode versions. See how that works? This is especially true for SwiftUI, which is iOS 13.0 and up only. Make sure you can run the latest!
Pro tip: You can often find the latest macOS version a device model supports on their Wikipedia page (see above links, scroll down to Supported macOS releases). You can then cross-reference that with Xcode's minimum OS requirements (see here, scroll to min macOS to run), and see which iOS versions you'll be able to run.
Further Reading
Awesome! We've discussed what you need to run Xcode on your Mac. You might not need as much as you think you do. Likewise, it's smart to invest in a future-proof development machine.
Whatever you do, don't ever think you need an expensive computer to learn how to code. Maybe the one thing you really want to invest in is frustration tolerance. You can make do, without the luxury of a MacBook Pro. A hand-me-down i486 is enough. Or… is it?
Want to learn more? Check out these resources:
Learn how to build iOS apps
Get started with iOS 14 and Swift 5
Sign up for my iOS development course, and learn how to build great iOS 14 apps with Swift 5 and Xcode 12.
9 Tweaks to Speed up Xcode Builds
As projects grow, build times can become problematic. However, there are several tweaks you can make to Xcode that can decrease the amount of time it takes for builds to complete without any extra work.
UPDATE: This article has been expanded to add two factors to think about when speeding up VMs. In addition, this article references Xcode 9. With reports that Xcode 11 builds are up to 50% slower, Xcode build speed has become an even hotter topic.
Increase the thread count:
By default, Xcode typically uses the same number of threads as the number of cores in the machine's CPU. However, you can dramatically reduce build times – in some instances by a full 30% - by increasing the thread count beyond the default. This takes advantage of some processors' ability to multi-thread or simulate additional cores. Keep in mind that you may need to experiment to determine if there are diminishing returns for parallelized builds with your code base, and then adjust the thread count accordingly.
Enable the New Build System:
Apple's 'New Build System' is written completely in Swift and was designed for overall performance and dependency management improvements. Be aware that while the New Build System is available in Xcode 9+, it must be enabled in Xcode under Project/Workplace Settings since 'Standard Build' will be the default option. Alternatively, the New Build System can be enabled via command line (details linked below).
Imac Pro Xcode Benchmarks Tool
You can find more details and instructions for enabling the New Build System here:
Xcode New Build System for Speedy Swift Builds
Tweak the iOS simulator:
The Apple iOS test simulator lets you test across different software and hardware combinations (but only from a Mac). By using Physical Size or Pixel Accurate window sizes, you can reduce both the size of your tests and the time it takes for them to complete. These configuration changes use less resources and help prevent tests from slowing down simulating pixels that no one will ever see.
You can find configuration instructions here: Adjusting the Xcode iPhone simulator scale and size
Use parallelized builds:
Parallelized builds can reduce total Xcode build times by building components of the app that do not depend on each other at the same time. For projects with many smaller dependencies that can easily be run in parallel, this can offer significant time savings. Gains will obviously depend on how your code is written, but it is worth testing since parallelized builds aren't enabled by default. You can enable parallel builds by editing the Xcode Scheme and checking ‘Parallel Builds' in the build action of the scheme.
You can find more detail on leveraging parallelized builds here: When should I check 'Parallelize Build' for an Xcode scheme?
Google explorer update. Turn on build time summary:
Build time summary enables reporting on the build times of each piece of the Xcode build. In other words, build time summary can help you identify the parts of the build that are impacting build times and further optimize the build order for overall gains. While not a fix in and of itself, the insights that build time summary provides can be useful in prioritizing efforts when trying to optimize your build times.
Bigger build machines:
This one isn't technically an Xcode tweak, but bigger build machines do have an outsized impact when attempting to speed up builds. More computing power simply translates into faster completion of processes and builds. Our testing shows that moving from a dual-core Mac mini to a 12-core Mac Pro can give a 3x speedup without any additional effort. When you're ready to upgrade or scale your Mac infrastructure, feel free to contact us at MacStadium.
UPDATE - Increase your clock speed:
With the recent Xcode 11 release, more and more builds are showing signs of single-threaded-like behavior. That is, some elements are not being run in parallel like before. In this event, hardware with more cores is not necessarily better. MacStadium is currently finding customers can complete builds faster by picking a 6-core 2013 Mac Pro, which has a 3.5 GHz clock speed over the 12-core 2013 Mac Pro at 2.7 GHz. Individual builds vary, but this a factor to check.
UPDATE - Enable caching:
Xcode now supports caching automatically as long as users do not run the Product > Clean feature before builds. This is a great improvement for local developers who are the primary audience for Apple's continued development. For teams, the caching features of Bazel make it a very attractive choice. Minecraft pe free install ios. The implementation of Bazel is not always easy, but implementing Bazel for iOS and macOS builds was the specific focus of the 2019 BazelCon. All the talks are now on YouTube.
If you're running dozens or hundreds of builds a day as part of a CI pipeline, you can improve performance by leveraging a virtualized Mac fleet. Orka, the first and only solution built for orchestrating genuine Apple hardware allows you to orchestrate many build machines using Kubernetes technology.
You can try an Orka sandbox and see for yourself how easy it is to manage a Jenkins pipeline, spin-up VMs and achieve near bare metal speeds on a hypervisor built specifically for macOS and iOS app development. Have questions? Talk to a sales engineer about how Orka can transform your Xcode build process.
Additional Resources:
Of course, these are only a few of the suggestions you can use to speed your Xcode build times. The following resources can provide additional information and suggestions on improving your Xcode build times.
Imac Pro Xcode Benchmarks Software
Imac Pro Xcode Benchmarks App
