Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Apple’s new M1 chips are essential for rapid iOS development

doordash.engineering

Post reply on HN
Print view View original

111–120 of 135 posts

Re: Why Apple’s new M1 chips are essential for rapid iOS development

#111

Post by aaronbrethorst »

billforsternz wrote: post #108
aaronbrethorst wrote: post #99

Earlier quoted context omitted.

30 incremental builds an hour while doing iOS UI development can be entirely the norm: Tweak a font size; rebuild. Tweak the font again; rebuild. Change the text color from 'label' to something slightly gray; rebuild. et cetera.

I know people do this sort of thing, but I still don't approve of it as a good way to live :-) Sounds too much like editing a document by manually styling every last element instead of creating a theme with a consistent set of styles.

It isn’t. Welcome to iOS development :-|

Re: Why Apple’s new M1 chips are essential for rapid iOS development

#112

Post by billforsternz »

aaronbrethorst wrote: post #111
billforsternz wrote: post #108

Earlier quoted context omitted.

I know people do this sort of thing, but I still don't approve of it as a good way to live :-) Sounds too much like editing a document by manually styling every last element instead of creating a theme with a consistent set of styles.

It isn’t. Welcome to iOS development :-|

Edit: Whoops, I misunderstood your meaning please ignore and accept my apologies! You mean it isn't a good way to live!

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.

Re: Why Apple’s new M1 chips are essential for rapid iOS development

#113

Post by olliej »

andy_ppp wrote: post #95
jarjoura wrote: post #86

Earlier quoted context omitted.

There is no OpenGL driver on M1. So your app is running through a translation layer to the native Metal driver underneath. All OpenGL rendering on M1, no matter the framework (iOS, Catalyst, macOS) has pretty terrible performance because of that.

Is this true for WebGL as well or does Safari/Chrome/Firefox do something special?

All browsers use the ANGLE library to translate to the underlying platform 3d engine (Direct3d, Metal, OpenGL, Vulkan?)

That aside, afaik M1 Macs only have OpenGL as a translation layer (to metal) for programs running under Rosetta

Re: Why Apple’s new M1 chips are essential for rapid iOS development

#114

Post by h0l0cube »

billforsternz wrote: post #94
h0l0cube wrote: post #72

Earlier quoted context omitted.

Have you worked with SwiftUI or Jetpack Compose? The new tooling for mobile development requires basically building the app to simulate the layout engine. And when you're building interfaces, ideally you want < 1 second updates so you can tweak things that don't lend themselves perfectly to foresight and analytical thinking - you just need feedback. Jetpack Compose in particular is atrociously slow. When was taking 1…

No I haven't done that specifically, although I've done some stuff with other GUI builders and I think I know exactly what you mean. Basically this is why I added my ideal vs reality YMMV qualifier :) 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…

The main issue with these new UI frameworks is that they are composable and dynamic. It's great because you can make your own application specific or organisation wide UI libraries that are, in essence, a collection of free functions. But it also means that the dependencies of all those functions need to be compiled. This same workflow is fine in the JavaScript world because it's an interpreted language and the compilation step can be skipped.

Re: Why Apple’s new M1 chips are essential for rapid iOS development

#115

Post by aaronbrethorst »

billforsternz wrote: post #112
aaronbrethorst wrote: post #111

Earlier quoted context omitted.

It isn’t. Welcome to iOS development :-|

Edit: Whoops, I misunderstood your meaning please ignore and accept my apologies! You mean it isn't a good way to live! 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…

Yep, all good :)

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 :)

Re: Why Apple’s new M1 chips are essential for rapid iOS development

#116

Post by spike021 »

ollysb wrote: post #83
spike021 wrote: post #34

Earlier quoted context omitted.

> 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…

I used SwiftUI for a side project and after 6 months binned the whole thing and switched to flutter. I was finding that a huge portion of my time was spent trying to get the project to compile (it generally just needed many recompiles so presumably there's race conditions in xcode or the compiler) and the previews induced several minutes worth of spinner every time I went near them.

That's pretty crazy. Fortunately once I stopped relying on Previews things quieted down. I have trouble debugging some runtime issues, but that's my fault for not being very confident with Xcode's debugger and such rather than a compiler or Swift issue.

Re: Why Apple’s new M1 chips are essential for rapid iOS development

#117

Post by xenadu02 »

TheNewAndy wrote: post #4

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…

Simulator has never supported hardware acceleration for OpenGL ES. It is no different on an Intel Mac. Only Metal in Simulator runs on the GPU. This includes WebGPU if you're using Safari.

Re: Why Apple’s new M1 chips are essential for rapid iOS development

#118

Post by xenadu02 »

TheNewAndy wrote: post #33
my123 wrote: post #15

Earlier quoted context omitted.

Sounds like it went through the software rendering path...

You are correct. It is frustrating because clearly it can be hardware accelerated, just Apple hasn't really bothered themselves to do this

Simulator support for GPU rendering is far from trivial so it isn't about "bothering". Metal jobs are packaged up along with shaders and proxied out to the host macOS Metal framework. Textures are backed by IOSurfaces which do some fancy Mach memory mapping tricks to share memory between your app in a simulator, the macOS side of Metal, and sometimes GPU memory (on Intel Macs with discrete GPUs). For the most part this is transparent to you and works even when Simulator vNext is running on macOS vPrevious.

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.

Re: Why Apple’s new M1 chips are essential for rapid iOS development

#119

Post by TheNewAndy »

xenadu02 wrote: post #118
TheNewAndy wrote: post #33

Earlier quoted context omitted.

You are correct. It is frustrating because clearly it can be hardware accelerated, just Apple hasn't really bothered themselves to do this

Simulator support for GPU rendering is far from trivial so it isn't about "bothering". Metal jobs are packaged up along with shaders and proxied out to the host macOS Metal framework. Textures are backed by IOSurfaces which do some fancy Mach memory mapping tricks to share memory between your app in a simulator, the macOS side of Metal, and sometimes GPU memory (on Intel Macs with discrete GPUs). For the most part th…

With the amount of cash apple has, it very much is about bothering. They have the resources to make their development tools not terrible, but instead they seem to be investing in... cash for a rainy day.

Re: Why Apple’s new M1 chips are essential for rapid iOS development

#120

Post by omegalulw »

wbond wrote: post #101
luigi23 wrote: post #8

"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 t…

How big is the app you are working on? How long does an incremental build take including linking and signing? 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 se…

It really depends in coding style. For example, I always like to write the smallest possible change to address a feature and bug fix that's testable, then I start writing unit tests, then back to code, then back to unit tests and so on. So it's not uncommon to do a lot of incremental builds (but yeah 30/hour is on the high side). Sometimes this is not feasible, e.g. working on a complex component which has a simple public API but does a lot of heavy lifting internally - in that case it takes a while to get to a testable change.
Post reply on HN