4 ms·

"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 Y

"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 5y ago
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 5y ago
  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.
spike021 5y ago
> 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.
- ollysb 5y ago
  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.
  - spike021 5y ago
    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.
  - cudgy 5y ago
    What’s wrong with nibs or storyboards? Why does it have to be the latest shiny abominable object to emerge from the incubator?
saurik 5y ago
> 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?
billforsternz 5y ago
30 incremental builds an hour doesn't sound like a good process to me. Personally I find if I am building too often I'm not thinking about what I am doing enough and I'm just throwing things at a wall hoping they'll stick/work. A good software process involves a lot of thinking, a medium amount of typing, a small amount of compiling. I understand that sometimes the ideal and the reality are different of course.
- h0l0cube 5y ago
  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 10 seconds before Android Studio would register my keypresses, I knew it was time to upgrade to M1.
  - billforsternz 5y ago
    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 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.
    - h0l0cube 5y ago
      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.
jon889 5y ago
I've actually found SwiftUI previews work fairly well, have to admit they get better with every Xcode version, and I don't understand why sometimes they need to recompile. Using them I generate snapshot tests automatically, and an app for our designer to see the various UI components on device through TestFlight. Currently only for our UI components library, but I'm hoping to expand the automatic snapshot testing to the app at some point.
wbond 5y ago
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 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.
- omegalulw 5y ago
  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.

zionic 5y ago

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 5y ago
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.

spike021 5y ago

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

ollysb 5y ago
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.
- spike021 5y ago
  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.
- cudgy 5y ago
  What’s wrong with nibs or storyboards? Why does it have to be the latest shiny abominable object to emerge from the incubator?

saurik 5y ago

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

billforsternz 5y ago

30 incremental builds an hour doesn't sound like a good process to me. Personally I find if I am building too often I'm not thinking about what I am doing enough and I'm just throwing things at a wall hoping they'll stick/work. A good software process involves a lot of thinking, a medium amount of typing, a small amount of compiling. I understand that sometimes the ideal and the reality are different of course.

h0l0cube 5y ago
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 10 seconds before Android Studio would register my keypresses, I knew it was time to upgrade to M1.
- billforsternz 5y ago
  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 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.
  - h0l0cube 5y ago
    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.

jon889 5y ago

I've actually found SwiftUI previews work fairly well, have to admit they get better with every Xcode version, and I don't understand why sometimes they need to recompile. Using them I generate snapshot tests automatically, and an app for our designer to see the various UI components on device through TestFlight. Currently only for our UI components library, but I'm hoping to expand the automatic snapshot testing to the app at some point.

wbond 5y ago

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

omegalulw 5y ago
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.