[HN Gopher] Why Apple's new M1 chips are essential for rapid iOS...
___________________________________________________________________
Why Apple's new M1 chips are essential for rapid iOS development
Author : apalom
Score : 69 points
Date : 2022-03-01 18:50 UTC (4 hours ago)
(HTM) web link (doordash.engineering)
(TXT) w3m dump (doordash.engineering)
| maradona_yolo wrote:
| FUCK OFF DOORDASH YOU FUCKING PREDATORY MONSTERS!!!!
|
| https://www.theverge.com/2019/7/22/20703434/delivery-app-tip...
| TheNewAndy wrote:
| One thing that is surprisingly slow on the M1 is running an
| OpenGL ES application in the simulator.
|
| 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).
| TillE wrote:
| I've tried a number of games from the app store (relatively
| simple 2D games which don't melt your phone) on an M1 Pro MBP,
| and found they all constantly maxed out multiple CPU cores for
| no apparent reason.
|
| There's definitely something wrong even with the iOS
| compatibility layer.
| my123 wrote:
| Sounds like it went through the software rendering path...
| TheNewAndy wrote:
| You are correct. It is frustrating because clearly it can be
| hardware accelerated, just Apple hasn't really bothered
| themselves to do this
| [deleted]
| asdff wrote:
| Why do companies even build locally anymore? It's never been
| cheaper to spin up your own cluster that's going to be more than
| enough horsepower. If you give your devs the $899 air instead of
| the $2300 16", I feel like that $1400 surplus per dev would go a
| long way in buying some nodes that are going to still be some
| muscle 5 years from now. You could buy two mac minis per dev and
| set up an m1 cluster if you wanted. If you didn't want that
| overhead, plenty of companies sell compute by the second now
| these days too.
| paxys wrote:
| On one hand, these machines are clearly superior, and it's a no
| brainer for companies to purchase them for development. On the
| other, this is just another one in the long line of examples of
| bad software practices being overcome by throwing more money and
| hardware at the problem. Is there any reason for an iOS app build
| to take 8+ minutes to begin with? And does anyone realistically
| believe that once all developers have these shiny new computers
| build time won't creep up again till everyone starts demanding M2
| and M3?
|
| This problem extends to the consumer side as well. Developers use
| fancy MacBooks and fiber internet connections and the average 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.
| theplumber wrote:
| Look at the bright side: bad/lazy software helps the world
| develop faster computers that can be used efficiently for
| "real" projects (i.e scientific research). If the computers
| would be "fast" enough there would be no incentive to make them
| faster and we would never reach singularity
| nhoughto wrote:
| Yep agree, having spent some time digging into why Xcode builds
| are slow it looks like low investment is a major reason. The
| tooling and optimizations are fairly primitive compared to
| other ecosystems and harder to get right where they do exist.
| It's just not a priority it seems, likely because new features
| win out.. and selling new hardware "solves the problem".
| massysett wrote:
| The user does have a choice: do not use crappy slow services.
| For example I stopped using Instacart because there was a long
| lag each time I typed a single character is the search box.
| Amazon and Peapod did not have this problem.
| sitzkrieg wrote:
| that is such a rookie mistake if they are doing searching
| immediately on inputs! debounce it ffs! i hope that was it
| and not general ui slowness
| bnj wrote:
| This reminds me of the same phenomenon that occurs in traffic
| planning[0]
|
| [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.
| kitsunesoba wrote:
| This may be true of 50-in-one megaprojects such as those from
| the likes of Uber and Google, but these machines are also
| beneficial to developers of more lean, focused, and optimized
| apps too. The few seconds my M1 Pro shaves off of incremental
| builds and the general improvements in IDE responsiveness
| compared to an upper-spec Intel mac pile up and become worth it
| quickly, not even mentioning quality of life improvements like
| far better battery life and being able to use the laptop in my
| lap comfortably.
|
| 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.
| skydhash wrote:
| > far better battery life and being able to use the laptop in
| my lap comfortably
|
| 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.
| kerbs wrote:
| Your argument is more or less a critique of Swift itself, which
| is a far more full-featured and "safe" language than
| Objective-C, at the expense substantially higher compilation
| times given otherwise like-for-like programs.
|
| 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.
| tarentel wrote:
| Definitely will echo this. The app I work on is probably a
| lot of bloat which the op is complaining about but compared
| to the last app I worked on it's quite a bit less and
| compiles at least 5 times more slowly due to using swift
| where as the last project was 100% obj-c. Even if we could
| somehow manage to convince management to let us clean up the
| app we'd still be at the mercy of however long the swift
| compiler takes.
| sixstringtheory wrote:
| Don't use type inference, and modularize the codebase into
| separate static libraries. That should reduce the amount of
| full rebuilds, and should make builds faster. (ETA: also
| try to avoid generics.)
|
| 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.
| GeekyBear wrote:
| > Is there any reason for an iOS app build to take 8+ minutes
| to begin with?
|
| 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...
| hughrr wrote:
| Yeah that's about it.
|
| 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.
| luigi23 wrote:
| "Based on rough usage patterns, we assumed an average iOS
| engineer does around five clean builds and 30 incremental builds
| each day..."
|
| ...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.
| zionic wrote:
| My biggest issue with SwiftUI previews is tweaks to a single UI
| file rebuilding random dependencies. Like, I just changed a
| color why is it rebuilding the graphing library AGAIN?
| luigi23 wrote:
| I'm not an expert on Swift, but I can only guess that code
| injection mechanism that's been used for Previews resolves
| changes incorrectly. Or the state got out of sync, so it's
| safer to rebuild the project rather than crash/timeout. Which
| unfortunately happens quite often, even after rebuild.
| saurik wrote:
| > 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.
|
| 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?
| spike021 wrote:
| > SwiftUI Previews is notorious for crashing, timeouts and
| random errors.
|
| 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.
| s800 wrote:
| Does the toolchain on x86 still build an x86 and ARM
| executable(s)? Perhaps that contributes to the 2x build time?
| flax wrote:
| I had to laugh at the opening: "The tools are largely free",
| except the bare minimum to develop for ios is a mac and the apple
| developer account (if you ever expect to publish your app). And a
| significant subset of functionality only works on physical
| devices and not emulators. If you don't already have the mac and
| iphone, you're looking at $600 for a used macbook air, ~$300 for
| a used 2 generations old iphone, and $100 for the dev account.
| $1000 is not "largely free".
| ctdonath wrote:
| You need a computer to compile at all. If you're doing iOS you
| probably already have an iPhone. Old physical phones (cheap)
| are fine for dev, can simulate latest. $100/yr only needed if
| you're actually charging for the app - which should earn you
| those costs pretty soon. Yes, $1000 baseline for what you
| likely already have most of.
|
| The "largely free" is in contrast with platforms having
| >$25,000/yr entry costs just for a license.
| flax wrote:
| Except that it's actually in direct contrast with Android
| development, where the tools are available, for actually
| free, for Windows, Linux, and Mac. And the developer account
| is a one time $25.
|
| 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.
| spiderice wrote:
| > and there's zero good reason that Apple couldn't provide
| their build tools for other platforms
|
| 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.
| nyanpasu64 wrote:
| > 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 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).
| GeekyBear wrote:
| How quickly we forget what development costs looked like in the
| recent past
|
| >PlayStation developers need to cough up PS 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...
| wmf wrote:
| I don't know if that's a great comparison since only 7,918
| PlayStation games were ever released while computers and
| phones have literally millions.
| Aaargh20318 wrote:
| > $1000 is not "largely free".
|
| 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.
| wmf wrote:
| In the developed world I presume.
| sitzkrieg wrote:
| came to post this, what a joke. are they steeped in privilege
| or what?!
|
| maybe simply unaware of the alternative ecosystem costs
| vmception wrote:
| its not just about javascript and android, take a look at
| FPGA development... several multi thousand dollar licenses
| out the wazoo
| [deleted]
| Rafuino wrote:
| And how about treating your contractor labor as real employees
| next, eh? Why not give them some nice, shiny, new hardware?
| tehjoker wrote:
| I believe it. I did benchmarking on my algorithms and it wasn't
| uncommon to see speedups in that range just executing on newer
| hardware from an old laptop.
|
| 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.
| thebean11 wrote:
| Essential for any development occurring on a Mac IMO. I upgraded
| from a fully specced out 16inch to a base model M1 with the 32GB
| upgrade (a machine roughly half the price I think) and it's night
| and day. I can use Docker now without Slack getting laggy.
| kitsunesoba wrote:
| I can't wait for the next macOS + iOS updates so I can use
| Universal Control to run Slack on my iPad and never have to
| open their bloated web/electron app ever again. I wish Slack
| would just let us run the iOS app on our macs with Catalyst,
| but they seem pretty bent on pushing desktop OS users to the
| web/electron version.
| periheli0n wrote:
| I thought the base model M1 maxed out at 16GB? Must be a M1 pro
| or max.
| nicoburns wrote:
| The 14 and 16 inch models only have pro or max, so yes that
| must be what they meant.
| thebean11 wrote:
| Yeah that was unclear, I meant the base model 16 inch which
| has an M1 pro chip.
| zitterbewegung wrote:
| I guess the new benchmark for development is can it run Slack?
| (While developing)
| thebean11 wrote:
| In my experience, yeah unfortunately. Slack goes to shit if
| the computer is under load, way before other software.
| steveBK123 wrote:
| arguably slack having performance issues might increase most
| developers productivity
| hughrr wrote:
| When they broke Slack the other I actually celebrated for
| the couple of hours and got some work done for a change. No
| joke but it's the single most productivity destroying tool
| I have ever used.
| nicoburns wrote:
| I realise your post is in jest, but I've found that
| responsive slack (due to a similar machine upgrade) has
| actually had a noticeably positive effect on my
| productivity. Checking a slack notification is now a ~2-5
| second task, quick enough that I can switch back to my task
| with losing context. It used to be more like 10-20 seconds
| if my machine was under load which was highly disruptive.
| chubs wrote:
| Where do these companies exist that buy the latest hardware for
| their devs? Please tell me, i've never seen one! ;) Honestly,
| maybe it's an australian thing (where i'm based) but i work for
| an international company now too and it's the same.
| IMTDb wrote:
| > Figure 1: Plotting the cost of "time spent compiling" of the
| old vs. new laptops shows the one-time cost of the hardware
| upgrade quickly pays for itself.
|
| 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.
| nicoburns wrote:
| I upgraded to an M1 Pro from a 2015 i5 Macbook Pro and have seen
| even more dramatic results. ~3 minute clean compile times for our
| iOS app, down from over 20 minutes!
| hughrr wrote:
| That's exactly the jump I made.
|
| From my perspective, compilation I do (mostly Go) is near
| instant versus 20 seconds.
| spiderice wrote:
| > Based on rough usage patterns, we assumed an average iOS
| engineer does around five clean builds and 30 incremental builds
| each day
|
| Why five clean builds a day? That seems like a lot. Any iOS devs
| care to chime in?
___________________________________________________________________
(page generated 2022-03-01 23:00 UTC)