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

How Apple Plans to Root Out Bugs, Revamp iPhone Software

bloomberg.com

Post reply on HN
Print view View original

201–210 of 234 posts

Re: How Apple Plans to Root Out Bugs, Revamp iPhone Software

#201

Post by exBarrelSpoiler »

perseusprime11 wrote: post #176
askafriend wrote: post #7

This comment from a former employee on the iOS team provides some more context around the software quality issues. I think this is the more interesting point around which we should have this discussion. https://www.reddit.com/r/apple/comments/7x0eif/how_apple_pla...

Interesting comment. I thought Project Managers are a thing in the past. Looks like it is alive and kicking and taken on a new life at Apple.

The role of EPMs has been known to the public for some time:

https://www.quora.com/What-is-the-role-of-an-engineering-pro...

Re: How Apple Plans to Root Out Bugs, Revamp iPhone Software

#202

Post by rdschouw »

marklubi wrote: post #115
rdschouw wrote: post #89

Earlier quoted context omitted.

Yea, I hear you. For me, Apple Music randomly pauses my music when it is on bluetooth or ipod dock every 60-90s. Googling it revealed that I am not alone and this issue has been going on since the introduction of Apple Music app. Every release I try again, but no fix so far.

Speculating here, but I suspect that it's an app in the "background" that is causing the issue. As much as I like Sonos, it exhibits bad behavior with its background task that requests priority audio. If I have the app even running (even in the background, but haven't force quit it), it will interrupt the stereo in my car if I'm trying to listen to terrestrial radio and keep forcing CarPlay to open until I force quit…

That could be, but no other music app (Spotify, TuneIn, Tidal or Flacbox) have this issue for me.

Re: How Apple Plans to Root Out Bugs, Revamp iPhone Software

#203

Post by vlovich123 »

exBarrelSpoiler wrote: post #198
vlovich123 wrote: post #190

Earlier quoted context omitted.

It's really hard to put any single root cause on it. Firstly, mobile OSes are massive beasts with lots of different teams working on it. Co-ordinating this becomes very difficult. Additionally, you typically get about 1 build a day which means there's a long lead time to find a bug that's managed to propagate out and then a long lead time for it to get fixed (at least 1 day). I think this decrease in quality has been…

QA being divided between Craig and Kim didn't help, either. Nor the organizational wars.

Hmm... I think Kim came in towards the time I was leaving. Last name? When I was there our immediate QA was embedded within SW & reported up through the SW chain. Craig took over all OS SW development early 2015 IIRC. Have things changed? FWIW software quality of iOS has always been a concern in the media and I don't see that iOS 11 is particularly better or worse than other releases. iOS 8 had horrible performance issues for example to the point where iPhone 4S lifetime had to be artificially extended to iOS 9 instead of being EOL'ed in iOS 8 as originally planned. Every release has had its own share of embarrassing/severe bugs. Except for maybe iOS 1.0 which had no 3P features, a very small feature-set, & no competition to be evaluated against, each iPhone release has always been received as having stability issues, at least initially.

> However, they criticized it for having stability issues and overall sluggishness https://en.wikipedia.org/wiki/IPhone_OS_2

> iPhone 3G users reported performance and battery issues after upgrading to iOS 4 https://en.wikipedia.org/wiki/IOS_4

> The iOS 5 update was the subject of criticism for iPhone 4S users, as the upgrade caused problems with battery life, failures of SIM cards, and echoes during phone calls. https://en.wikipedia.org/wiki/IOS_5

> A study by Apteligent (formerly Crittercism) found that the rate at which apps crashed in their tests was 3.56% on iOS 8, higher than the 2% found on iOS 7.1.[81] > Forbes published several articles focusing on problems in iOS 8 regarding Wi-Fi and battery,[82] Bluetooth,[83] and calendar.[84] https://en.wikipedia.org/wiki/IOS_8

A lot of iOS9 issues received media attention: https://en.wikipedia.org/wiki/IOS_9#Problems

https://en.wikipedia.org/wiki/IOS_10#Problems

Except for iOS6 & 7 which appear to have had a milder reaction, if anything I think iOS 11 may be a more stable release compared to iOS 8, 9, & 10 in that while there are more frustrating UI bugs you can hit (auto-correct, iMessage message ordering) but the overall performance & stability hasn't suffered as badly. Also iOS has knock-on impressions from OSX stability which has had similar UI embarrassments + a couple of security-related missteps.

My point is I don't think there's any single particular cause that's identifiable as the reason behind poor SW quality. If it were the hundreds if not thousands of really smart people Apple employs would have solved the problem. At this point it's all higher-level issues & more often than not tradeoffs (e.g. reducing the features you ship every year & going away from a waterfall development model)

Re: How Apple Plans to Root Out Bugs, Revamp iPhone Software

#204

Post by randyrand »

dkonofalski wrote: post #45
randyrand wrote: post #19

If they just added the ability to jump to a given date in text messages, I'd be happy. That's a long overdue simple feature.

That seems a lot less useful than a functional search for messages. I hate the fact that I can only search for 1 instance of my search within a conversation. There's no way to go to a previous or next instance from the instance that the search feature already found. That sucks.

I agree, but perhaps a functional search is asking for too much. I'd be happy with either. If you don't have a good key word to use, then jumping to a date range is the next best thing.

Re: How Apple Plans to Root Out Bugs, Revamp iPhone Software

#205

Post by foobarbazetc »

alexkavon wrote: post #147
foobarbazetc wrote: post #114

Earlier quoted context omitted.

Still waiting for this ~2 year old bug to get fixed in Edge: https://developer.microsoft.com/en-us/microsoft-edge/platfor...

FYI, the latest updates state this is fixed and in the insider builds.

It’s “fixed” in that the PM decided to gaslight everyone on that thread by claiming pointer events are what people are asking for.

It’s not. People want working scroll/wheel/touch events. They think the entire web dev world is going to rewrite stuff to support like Funny how Chrome supports the exact functionality they keep claiming is impossible to support.

Note also that there’s no way to detect Edge with working events vs Edge with a precision trackpad where events aren’t dispatched to the DOM.

God this bug makes me angry.

Re: How Apple Plans to Root Out Bugs, Revamp iPhone Software

#206

Post by savoytruffle »

gurkendoktor wrote: post #160
masklinn wrote: post #150

Earlier quoted context omitted.

> Based on your experience there what would you say is the cause of the recent slip in software quality in both iOS and macOS? It's not clear because there have been absolute shit-show releases going back to the early days of OSX. Even the fondest-remembered releases were only so after a ton of polish, and that was with releases slipping significantly (you might see 3 years pass between major updates, and the new ver…

What has definitely changed is the pace with which people are expected to upgrade. When OS X Snow Leopard came out, you had to visit a store to buy the DVD. Nobody would look down on you for running a "legacy OS" if you only upgraded when .3 was out. The ways in which this has changed affect both tech-savvy and casual users: 1. Older versions of iOS (which didn't exist back then) don't receive security fixes, so the…

When Snow Leopard 10.6 came out in August 2009, it only supported Intel Macs, which were at earliest from January 2006, about three and a half years earlier. Typical Mac OS X releases up to El Capitan (september 2015) supported 10 years of Macintosh computers. Sierra/High Sierra still do, essentially.

Re: How Apple Plans to Root Out Bugs, Revamp iPhone Software

#207

Post by avar »

oillio wrote: post #191
avar wrote: post #175

Earlier quoted context omitted.

Git itself is developed this way, so saying it could be fixed by "real revision control" is silly. Maybe you worked with someone who misused this model, but there's good reason Git and Linux use it.

I think the OP covered this argument with is comment about Linus' "benevolent dictatorship." That is an extreme outlier. If your organization is run by someone like Linus, it can work, maybe.

Git hasn't been run by Linus for over 10 years, and uses this workflow. Is it flawed in some ways? Sure, but it works and has its advantages.

Furthermore the way patches are submitted, discussed and reviewed has little to do with the process by which they're eventually accepted or rejected by a BFDL maintainer, unlike what the GP is claimnig.

If the kernel used say Github pull requests you'd just have Linus rejecting some of those instead of refusing to accept patch serieses submitted by E-Mail.

The GP is just railing against some bad experience with the "True Gatekeepers", as if a company that was dysfunctional enough to use E-mailed patches as some unreasonable filtering mechanism wasn't able to do so via other methods.

The advantages of the E-Mail workflow is that it's fully distributed (aside from the ML hosting), bug/patch discussion can naturally flow into one another, everyone can use their favorite client that they can script etc., and you don't need an active network connection to participate (do all your patch review on the plane), all as opposed to using some opaque web UI.

Re: How Apple Plans to Root Out Bugs, Revamp iPhone Software

#208

Post by pm215 »

rwmj wrote: post #154
ndesaulniers wrote: post #81

Earlier quoted context omitted.

plain emailed diffs? this isn't LKML

What's not to like? Lightweight, multiple interoperable tools (MUAs and editors), no barrier to entry, easy to review and comment. Compared to shitshows like Gerrit and the awful clunky workflow of Github, I'll take an emailed patch every time. Does it scale to huge patchsets? ... well not so much. However Gerrit is not the answer to that (in fact, no tool I've found provides a good answer).

The major problem with the email-patches workflow is that it is a pretty poor experience for the new and occasional contributor, who will generally find that their email client makes a complete pig's ear of their patch. What I'd really like to see is a web UI that seamlessly interacted with the trad email workflow, so people who prefer a web UI and especially people who are just making a single drive-by contribution could work that way without having to start by setting up git-send-email. You could also make the web interface keep track of which patches are still unreviewed so things drop through the cracks less often...

Re: How Apple Plans to Root Out Bugs, Revamp iPhone Software

#210

Post by bri3d »

avar wrote: post #207
oillio wrote: post #191

Earlier quoted context omitted.

I think the OP covered this argument with is comment about Linus' "benevolent dictatorship." That is an extreme outlier. If your organization is run by someone like Linus, it can work, maybe.

Git hasn't been run by Linus for over 10 years, and uses this workflow. Is it flawed in some ways? Sure, but it works and has its advantages. Furthermore the way patches are submitted, discussed and reviewed has little to do with the process by which they're eventually accepted or rejected by a BFDL maintainer, unlike what the GP is claimnig. If the kernel used say Github pull requests you'd just have Linus rejecting…

The advantage of the Pull Request system is that it lends transparency. Especially in a corporate environment, a team can easily ignore and reject a lot of code sent to a mailing list. When each patch is tracked using tooling built for that purpose, this gets a lot harder.

Yes, the BFDL maintainers can continue to operate in whatever system they're given, but the more transparent the system is, the more likely they are to be discovered and the issue corrected.

I do agree that the E-mail workflow offers (a few) advantages, but the lack of inherent transparency in the tooling tends to be quite troublesome. It also doesn't inherently offer easy integration with automated testing systems or easy audit and compliance logging.

Post reply on HN