Why Apple’s new M1 chips are essential for rapid iOS development
doordash.engineering
doordash.engineering
...wait, what? I know YMMW, but for me and most of my colleagues it's 1-2 clean build per day and 30 incremental... per hour, sometimes.
"...In parallel with our modularization effort, we’re also adopting new technologies like SwiftUI and Xcode Previews. These technologies allow us to almost entirely remove the tweak-compile-and-run loop when developing user interfaces."
This sounds more like SwiftUI ad/SEO blogpost than real developer's insights. SwiftUI Previews is notorious for crashing, timeouts and random errors. I have a lot of problems with these on small projects, not to mention bigger ones at work. It's also a nonsense to proclaim 'it remove tweak-and-compile' loop. Any change to model layer requires you to rebuild project, otherwise Previews will return old state. Not to mention that Xcode likes to rebuild project even for UI-only change.
Just going to plus one this point in particular. I just started working on an app for the first time in January, chose SwiftUI, and probably wasted at least a few days' worth of work time dealing with non-problems that become problems only because of using SwiftUI Previews.
Once I disabled Canvas and removed the Preview struct, my dev time got quite a bit more efficient.
Yeah, this doesn't make any sense for me either... I only do clean builds of any of my software when I am working on the build system itself or am cutting releases (so I'd measure them on a small handful per week), and I'm constantly doing incremental builds so quickly it is essentially a pipeline: I don't even wait for the build to finish before I'm making more changes. Why are they doing so many clean rebuilds?
In an ideal world GUI tools would let you easily specify what parameters were required from the user, what standard very flexible and adaptable widgets were to be used to get those parameters, and how the parameters are constrained. All with a coherent special purpose language or some other fit for purpose technique, with an absolute minimum of pixel tweaking etc involved.
Sadly it's not an ideal world.
What do you mean it isn't? Of course it is, at a conceptual level. By your own admission you're endlessly tweaking each presentation detail. Wouldn't it be better to operate in an environment where minor presentational details look after themselves?
Don't get me wrong, if that's the way you have to do it, that's the way you have to do it. I've done similar things in GUI environments myself. But I didn't enjoy doing it that way and yearned for something better - even if I didn't have the time, opportunity, skill or talent to construct that better way myself.
Wouldn't it be better to operate in an environment where minor presentational details look after themselves?
From your lips to Tim's ears, buddy :)
30 incremental builds an hour sounds pretty high to me, unless you’ve got a smaller app. On Intel machines, I’ve been seeing minimal incremental build times of over a minute. The M1 obviously make some pretty significant improvements in this situation.
However, while I’m relatively new to the iOS world, it seems linker performance is a fairly hot topic. I know more than a few people are eyeing support for Mach-O linking in mold, based on the massive speedups shown for Linux.
I developed a game on a shoestring budget, and hoped that an M1 would be able to be used for capturing video of the game at the resolutions that Apple wants, but it was way too slow to be able to do this, so I had to just leave video out of my store page.
The same app run on your M1 mac with its iOS compatibility works completely fine (as it should, it is a 2d game with about 10 sprites that just get drawn with scaling and no rotation).
Does OpenGL ES not get this treatment...?
The vast majority of developers are using higher-level system frameworks, an engine that has a Metal renderer already, use WebGPU, or use Metal on Apple platforms.
There's definitely something wrong even with the iOS compatibility layer.
That aside, afaik M1 Macs only have OpenGL as a translation layer (to metal) for programs running under Rosetta
From my perspective, compilation I do (mostly Go) is near instant versus 20 seconds.
Where the horizontal axis is labeled as "10", "20", "30" , ... without any unit and the vertical axis isn't even labeled beyond "Cost" (no units, no numbers). If you want to make a graph, fine, but remember your math teachers and at least get the axis right before even thinking of the data. And before drawing any conclusion.
1: https://github.com/bazel-ios/rules_ios
2: https://www.reddit.com/r/RedditEng/comments/syz5dw/ios_and_b...
Slack is an abomination.
Slack is all the bad organizational behavioral issues of email, except harder to filter with rules & with more sender-side options for creating noise for the recipient.
It's lovely to send a slack and get quick response.
It's a huge productivity killer to get dozens/100s of half-thoughts ad-hoc sent over IMs to individuals and blasted to groups.
Is there a massive production outage? (I care about)
Did someone just share a funny GIF? Is Bob helping Jim debug a firewall issue for a client? (none of which I care about)
I got that stupid red dot, hard to tell without checking.
Air travel is such a colossal waste of environment and time so to top it off with additional cost to the company for "developer experience" is so unnecessary. If a company wants me, a developer, to fly in in business class I'd immediately think that they prefer to concentrate on showing off instead of concentrating on things that really matter. Unless it's a fucking Ryanair (don't know what's US equivalent of shitty el cheapo airline), I'd be fine flying in economy. I'd rather the company spend the money on my salary or work environment instead of one time showoff so that I could sip champagne and put my feet up while flying for 4 hours.
You're sure? For everyone across all fields? The simple fact is in many professional contexts, air travel is mandatory (including for many developers). I fly several times a year for work because the nature of my development job demands it.
> I'd rather the company spend the money on my salary or work environment
This is the point I was making. Since I have to travel, a relatively cheap business class upgrade (not first class) is the company spending money on my work environment.
A bad network connection is severely disruptive to almost all dev workflows so it's not a unique reason against remote development. The other factors you raise are not really relevant. The "overhead" of syncing code should be invisible with modern dev tools, and binaries should be built remotely anyway. I.e. the laptop should basically used as a thin client + web browser.
>What if you want to work from outside the office?
This is an argument in favor of remote development. When everything is on the cloud, it doesn't matter whether you are in the office, at home, or travelling.
If you are outside the office, chances are your internet connection is not as good. The scenario given here where everything is in the cloud sounds like a nightmare for me.
The new MBPs are incredible machines and worth the money in engineer productivity. for an iOS engineer, I'm not sure of a better set up from Apple's current line up.
Actually I wanted to compile an Android app on it, which uses some C code. On an MPB with an M1, Android Studio does not handle that natively and without hassle in Android Studio release, or beta - they seem to have some support in Android Studio Canary now, with a little futzing.
I'm not in a rush, and will probably wait until I can just compile the Android app from Android Studio release without any jury-rigging needed. So I'm not stuck really, I have the time to wait for it to all get into the NDK post-canary release and the Android Studio post-canary release and I will proceed from there.
Also, I have never used Fidelity's Active Trader Pro app, and wanted to check it out as my desktop is a System76 box running Ubuntu and ATP is not available for that. So I tried to install on the MBP with M1 and - no go. Not sure what is needed for this to go on.
I think I have Rosetta installed, but hasn't helped much.
I'm not really stuck on these things, they're just observations. It is as fast as everyone says. The local app store only 16G RAM MBP's in stock so I got one instead of waiting for a 32G RAM one. Android Studio still compiles apps pretty quick though.
It would be nice if all of these apps and operations worked smoothly and out of the box now, but it's not a huge deal. The purchase works for me for other things and neither of these things have high urgency presently.
sounds like what rust people do, they can't acknowledge the stupidly and insanely slow build times, they tell you "it works fine on my threadripper, don't be poor lmao"
Why five clean builds a day? That seems like a lot. Any iOS devs care to chime in?
However, it's kind of amusing to think how shocked we are by this development when such things were taken for granted in the 90s.
This applies to incremental and clean builds running locally with default Xcode settings
When you archive and build for the store then your compilation will include all architectures
maybe simply unaware of the alternative ecosystem costs
The iCE40 boards are sub $20 (iCESugar nano) and have an open source toolchains. And things like the ECP5(G) boards are large enough to host full RISC-V/etc environments for less than $50.
So, yah, FPGA's can get outrageously expensive, but there are a lot of low end devices with a lot of capabilities (those ECP5's have highspeed serdes, which can act as PCIe cards for example).
The “largely free” is in contrast with platforms having >$25,000/yr entry costs just for a license.
My personal situation: I wanted to add an iOS client for the game I've been developing in Flutter. I did not have a mac or an iphone already. Fortunately, I've been able to borrow them for builds and occasional testing. But, that's obviously not optimal, and there's zero good reason that Apple couldn't provide their build tools for other platforms. Instead, they leverage their monopoly on the app store to force hardware sales to developers.
How do you figure? Then Apple would have to maintain their build tools for other platforms. Waste of resources for something that ultimately isn't going to make Apple money. It's no different than Microsoft intentionally gimping Excel on Mac.
I've never seen anyone complain that they have to own a Windows computer to develop Windows apps. Or a Playstation to develop Playstation games. I'm not sure why Apple is such an exception in your eyes.
It makes sense on Apple's part, but I still dislike it.
> I've never seen anyone complain that they have to own a Windows computer to develop Windows apps.
Windows can be installed on any computer, whereas macOS requires purchasing Mac hardware. Additionally you can cross-compile Windows apps on Linux (and possibly Mac) using MinGW toolchains (or with great difficulty, MSVC on Wine).
Running Windows natively requires an Intel PC. an Intel Mac via Boot Camp (but I'd advise buying a two-button mouse with a scroll wheel if you do that), or a subset of ARM PCs for which Microsoft provides ARM builds. That's definitely not "any computer" or even "practically any computer."
It is absolutely insignificant compared to the cost of developing software.
It’s a tool needed to do a job. Go talk to a carpenter, a builder or a mechanic and ask them how much they spent on tools. Then compare their hourly rates to that of a software engineer.
They are equivalent if not more, where I am.
I can develop software comfortably on a $100 laptop and whatever choice of FOSS operating system. You can get a workable but less comfortable setup with an inexpensive device like the raspberry pi or a used system.
That is part of what makes CS special compared to other fields, the tools and information are available to everyone who has a working computer and internet access instead of being extremely expensive and locked behind gatekeepers like colleges.
Also keep in mind that the free tools and operating systems are not "junky" or whatever you might assume if you aren't familiar with them. GCC and LLVM are examples of extremely high quality FOSS toolchains, Debian and FreeBSD for operating systems.
>PlayStation developers need to cough up £ 12,000 for the full system (which Sony is adamant it doesn’t make money on), although all subsequent software tools and hardware upgrades are free.
https://www.retroreversing.com/official-playStation-devkit
Not to mention other obscene costs that were common, like charging developers to issue a patch for software sold online.
>Double Fine's Tim Schaefer pegged the cost of submitting an Xbox 360 patch at $40,000
https://arstechnica.com/gaming/2012/07/microsoft-comes-under...
This problem extends to the consumer side as well. Developers use expensive MacBooks and fiber internet connections and the end user has a laggy experience running the hundreds of megabytes of JavaScript on an average site. The user has no choice but to upgrade their computer, and then companies see the new spare CPU cycles and fill them up as well. The end result is that while hardware keeps getting ridiculously faster and more efficient, user experience doesn't noticeably improve.
It is just Writh's Law (https://en.wikipedia.org/wiki/Wirth%27s_law) in action.
[0]: https://www.vtpi.org/tdm/tdm64.htm
Briefly, as impediments to congestion are introduced (bike lanes, tolls), individual cars either join or leave the traffic system until the delay for cars reaches a rough equilibrium based on what people will tolerate.
Seems the same is true for computing capacity.
You're not necessarily wrong, but that ship has sailed for iOS development long ago and isn't necessarily the fault of teams like Doordash who have probably (like others) already squeezed as much build-time performance out of their given app size and feature set.
Mobile apps are inherently monoliths, and there is unfortunately no real way around some code changes triggering full rebuilds of millions of LoC.
Ofc, probably a lot harder to go back and redo a huge legacy codebase where you still have new deadlines to meet, but for folks just starting out, these should be guiding principles in a Swift codebase if you care about compilation time.
What I find really offensive, which my Mac likes to remind me of regularly on the energy usage side of things, is the siloed vats of excrement that JavaScript, Browsers and Electron have enabled. These are absolutely horrible to use compared to native applications and each one has its own ozone hole above it. If I don't open a browser or Electron app my battery lasts 2x as long.
I do the occasional bit of Swift with XCode just for fun and to concentrate on that case really does disservice to the real elephant in the room above because at least Swift is not burning the universe to the ground and recompiling bits of it every time you click something. When you're done it's native.
Edit: personal wastage shitlit: Lens, Discord, Teams, Slack, VScode. VScode gets a pass as it doesn't annoy me as much as the others.
That’s just battery usage, not even touching on general performance, how buggy the app is in general.
It was horrible on the previous Intel i5 MBP though.
I refused to install it on my M1Pro MBP!
When someone is sharing video / screen share its even worse.
I absoutely cannot fathom how it passes any form of QA.
I feel with JavaScript and especially everything being Electron (I shudder to think how many copies of Chromium I am running at the moment) we've backtracked back to those days - but worse.
For the projects I work on, compile time has been declining with each hardware gen despite app complexity increasing significantly. I’m sure there are other devs who this is true for too. We’re not all 5 abstractions deep and nonchalant about heavy resource usage and bad engineering.
These are the mains reasons I sold my 2015 MBP to get the M1 Air. I was not doing anything computationally heavy, so I don't notice any performance improvement. But the Air never get hot. And the battery usage is so light that I don't worry over its charge status.
The speedup isn't limited to iOS app builds. For instance, at Reddit:
>We recently found that the new 2021 M1 MacBooks cut our Android build times in half.
https://twitter.com/softwarejameson/status/14559711620606976...