Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
As much as this is a bit embarrassing I'd say theres no malice behind it but rather optimisation.

You see, it takes a bit of time to fire up the audio processors on iOS. So if you'd only do this as the call is accepted you'd have a second of silence before all systems were go.
What they have done is allocate an instance of the audio handler when the call comes in. So when the call is accepted audio is ready to go immediately.

The problem is that you need to mute the audio handler and then un-mute when the call is accepted. What happened here is that _something_ triggered the un-mute to happen immediately. leaving the audio go through even though the call isn't answered yet.

Calls to have Tim % Co. fired for this are just ridiculous, grow up kids, grow up. This is a pretty small bug, a bit embarrassing alright but it's not a 'gate'.
 
How is adding yourself to a call you’re already on part of any “basic” testing? What other “basic” scenarios would you test?

Here are a few...

Adding yourself on a secondary device / iPad to iPhone, etc.
Adding yourself using a matching identity
Making sure audio-only can't turn into video without consent
Making sure that the "cover" screen can't be deactivated with accessibility
Checking that a secondary call can't be added through accessibility shortcuts when otherwise prohibited
Call yourself directly using direct / phone number / number variance(local, then the +1 or +64, etc), and then adding someone else

That's in a few minutes, and doesn't even cover anything malicious with Siri, etc. I'm sure if I was inside the walls, there'd be 100x more to sort out.

And yes, these are simple checks that should be done *every* release.
[doublepost=1548798678][/doublepost]
As much as this is a bit embarrassing I'd say theres no malice behind it but rather optimisation.

You see, it takes a bit of time to fire up the audio processors on iOS. So if you'd only do this as the call is accepted you'd have a second of silence before all systems were go.
What they have done is allocate an instance of the audio handler when the call comes in. So when the call is accepted audio is ready to go immediately.

The problem is that you need to mute the audio handler and then un-mute when the call is accepted. What happened here is that _something_ triggered the un-mute to happen immediately. leaving the audio go through even though the call isn't answered yet.

Calls to have Tim % Co. fired for this are just ridiculous, grow up kids, grow up. This is a pretty small bug, a bit embarrassing alright but it's not a 'gate'.

No, but they do need to review their testing processes, and why they didn't catch this. The retrospective will be lit.
 
Apple should give the "bounty" money (and more) to that kid who found this and tried to inform them.
[doublepost=1548883722][/doublepost]
Because Tim Cook personally coded the functionality that gave rise to this bug?

The head that wears the crown …
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.