Live data from Hacker News

Apple’s iPhone Software Shakeup After Buggy iOS 13 Debut

bloomberg.com

21–30 of 251 posts

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

#21
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 did that with iOS 12. iOS 12 was great. Actually made a bunch of old devices more usable.

But then for iOS 13 they tried to catch up with 2 years worth of features in 1 year...

They just need to either slow down the pace, or figure out how to scale their developer count better.

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

#22
When I first worked at Apple 30 years ago it was widely acknowledged that R&D had a two-tier system for software development. The rockstar engineers got to work on new stuff and the less productive/creative engineers cleaned up their mess. Bringing new features to maturity was a low-prestige activity and was not rewarded as well. The top engineers joined the hot new projects, shipped the first version, and then moved on to the next big thing. That pattern changed somewhat after Steve Jobs returned, but it still seems to be the case that testing and maintenance are not a very high priority.

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

#23

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

I hate that Rich Hickey quote. Sprints are just the classic computer science "divide and conquer" strategy applied to development.

The why not use a word that doesn’t imply “go at an unsustainable pace”? There are plenty of good ones to choose from.

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

#24
post #3

Earlier quoted context omitted.

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…

So one of the issues is that Apple lives on their own tools, so when critical system components are broken nobody can get work done. But ideally they'd actually fix the bugs and try to keep the daily builds livable rather than trying to sweep the issues under the rug…

The problem seems to be there are so many bugs it becomes impossible to tell what caused what. Also, mixing unfinished features with known bugs in there might be a waste of time.

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

#25
post #16
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.

People remember fondly of Snow Leopard 10.6.8, but the introduction of Snow Leopard 10.6.0 was very rough, certainly not bug free. Snow Leopard did change a lot of things under the hood (64-bit mostly, maybe Grand Central Dispatch). At the time I was depending on macports to install a lot of dev dependencies: mono was broken, and a bunch of other libraries were also not compiling anymore. It is to this day the only m…

Bertrand Serlet used to go through ps output looking for threads so he could berate managers about not using GCD. So we had to uproot a bunch of stuff just to change the threading model used.

It was a strange way to manage tens of thousands of people.

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

#26
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

So they're just now discovering feature flags? I would have assumed that any team working on a large code base has been using those for years. The concept has been around since forever.

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

#27

Apple parrots their OS update metrics as a leading indicator of customer engagement / satisfaction with the platform & how sympathetic they are to the difficulty for developers of putting out software for new hardware every year. I'm interested to know the rationale for them putting out weekly releases vs. fortnightly or monthly. It seems like they could burn a lot of goodwill with casual users.

> I'm interested to know the rationale for them putting out weekly releases vs. fortnightly or monthly.

Apple doesn't push out weekly releases to the public. Are you suggesting that they should?

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

#28
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 should totally do that to macOS and i(Phone)OS, but personally I can’t wait to see what else they have in mind for iPadOS. Big fan of iPad Pro, could still use a lot more power user features though.

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

#29
post #26
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

So they're just now discovering feature flags? I would have assumed that any team working on a large code base has been using those for years. The concept has been around since forever.

It depends on what you consider "feature flags" to be. Apple already uses macros quite heavily to selectively include code and new features in certain builds. Presumably the new flags allow for enabling features at runtime or to certain groups, which is something that they don't seem to have done much in the past.

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

#30
I'm one of the most staunch Apple supporters but even I must admit that since WWDC 2019, I have spent more time fighting Apple's bugs than actually using any of the new features...or the old features that used to work flawlessly (like iTunes/Music.)

Not just on the user side, but the developer end as well.

Perfectly valid code which used to work up till Xcode 11.1 throws errors inside the Swift runtime or toolchain on Xcode 11.2 (and 11.2.1). Even the Swift engineers on the official forums don't seem to know what you can or can't do with the new language features.

And after seeing bugs I reported eons ago still not fixed, it feels futile to even bother reporting them anymore.

It's still not quite bad enough to make me want to flee back to Windows or switch to Android, but it does make me depressed, like there's nothing left in the world that "just works", except maybe my Nintendo Switch.

Post reply on HN