Live data from Hacker News

Apple’s iPhone Software Shakeup After Buggy iOS 13 Debut

bloomberg.com

1–10 of 251 posts

Re: Apple’s iPhone Software Shakeup After Buggy iOS 13 Debut

#2
> The new approach calls for Apple's development teams to ensure that test versions, known as “daily builds,” of future software updates disable unfinished or buggy features by default. Testers will then have the option to selectively enable those features, via a new internal process and settings menu dubbed Flags

Re: Apple’s iPhone Software Shakeup After Buggy iOS 13 Debut

#3
post #2

> The new approach calls for Apple's development teams to ensure that test versions, known as “daily builds,” of future software updates disable unfinished or buggy features by default. Testers will then have the option to selectively enable those features, via a new internal process and settings menu dubbed Flags

That’s nice and all, but I don’t really understand how that helps.

Ah, from the article:

> some “testers would go days without a livable build, so they wouldn’t really have a handle on what’s working and not working,” the person said. This defeated the main goal of the testing process as Apple engineers struggled to check how the operating system was reacting to many of the new features, leading to some of iOS 13’s problems.

Re: Apple’s iPhone Software Shakeup After Buggy iOS 13 Debut

#6
The same thing happened when we were working on Leopard under Bertrand. Because the developer toolchain switched to Objective C 2.0 with garbage collection enabled, the OS was unusable for development for months at a time.

Development took twice as long as planned, the release was fairly bloated, and required 2 or 3 updates in the first month or two.

When Craig took over he introduced a sprint model so that there were periodic relatively stable releases. If something wasn't ready and there were still sprints left, you could push it back.

But it sounds like there has been milestone creep causing those sprints to either become more heavy or less missable. And I'm guessing the consequences for missing a sprint are more career limiting than they were when the methodology was still new.

It's like Rich Hickey said, we're smarter than runners, we just fire a new starting pistol every 100 yards and call it a new sprint: https://www.youtube.com/watch?v=zPT-DuG0UjU

Re: Apple’s iPhone Software Shakeup After Buggy iOS 13 Debut

#8
post #5

Apple needs another "Snow Leopard" release - spend an entire year not adding anything - just focus on making everything work better, fix bugs, etc.

They just did that with iOS 12/macOS Mojave. I guess they need another one?

iOS 12 and Mojave are fine. Just stay there, fix bugs, and add support for new hardware.

Re: Apple’s iPhone Software Shakeup After Buggy iOS 13 Debut

#9
> The new approach calls for Apple's development teams to ensure that test versions, known as “daily builds,” of future software updates disable unfinished or buggy features by default. Testers will then have the option to selectively enable those features, via a new internal process and settings menu dubbed Flags, allowing them to isolate the impact of each individual addition on the system.

Uh, I'm not very confident on this helping; wouldn't this mean fewer people will be using and evaluating beta components?

> Apple privately considered iOS 13.1 the “actual public release” with a quality level matching iOS 12.

It certainly didn't reach that quality level…

Re: Apple’s iPhone Software Shakeup After Buggy iOS 13 Debut

#10
post #3
post #2

> The new approach calls for Apple's development teams to ensure that test versions, known as “daily builds,” of future software updates disable unfinished or buggy features by default. Testers will then have the option to selectively enable those features, via a new internal process and settings menu dubbed Flags

That’s nice and all, but I don’t really understand how that helps. Ah, from the article: > some “testers would go days without a livable build, so they wouldn’t really have a handle on what’s working and not working,” the person said. This defeated the main goal of the testing process as Apple engineers struggled to check how the operating system was reacting to many of the new features, leading to some of iOS 13’s p…

I think the idea is that you can't put anything with a known regression in the daily builds any more. But that gives a problem of how do you even get feedback on an in-development feature while you're trying to get it to a zero-regression state? The answer appears to be feature flags, I guess.
Post reply on HN