Apple's fix for shaking iPhone 14 Pro cameras arriving next week

Apple wants to make a big deal of how many and how fast users have upgraded to iOS 16 vs iOS 15, so much so they let iOS 16 out of the gate with a few baddies they either didn’t know about or couldn’t fix in time.

lkrupp said:

Apple wants to make a big deal of how many and how fast users have upgraded to iOS 16 vs iOS 15, so much so they let iOS 16 out of the gate with a few baddies they either didn’t know about or couldn’t fix in time.

Apple would not intentionally ship software with a known bug that has no workaround and requires an immediate or nearly immediate fix. 

All software development organizations have invested very heavily in testing over the past several years. They know that they need to increase test coverage and avoid releasing bugs into the field, not just for maintaining their reputation for quality, but because it's so damn expensive to fix bugs that are in the field. One of the techniques they've used to improve testing is to test early and test often - mostly using automated test tools that are less expensive and less manpower intensive.

Unfortunately, there are some features/functions that are not easy to test using automated test tools and techniques, notably those features/functions that require a human tester to manually interact, usually in an in-lab test facility, with the system under test and system-level tests. This camera OIS bug falls into both categories. In addition to a test engineering developing the test cases, a tester has to install at least one of the third party apps on the test system and use it in a scenario that involves the OIS feature. Part of the test scenario would involve making sure the feature activates when it should and does not activate when it shouldn't.

Could Apple find an automated way to run tests that seem to require manual, hands-on human interaction? Sure. They could for example use a test fixture with a shaker table and an automated test script that runs through the various app combinations with OIS. Developing complex test fixtures is usually not cheap and has to be weighed against the cost of doing it manually and frequency of use. Sometimes it makes sense to invest in test fixtures. Sometimes it doesn't. 

Automated testing can make the overall test coverage numbers look really good and is especially good for regression testing, i.e., making sure that things that were working normally before changes were made are still working normally after the changes were made. But anything that requires manual testing, in-lab testing, involves new features, involves system level interactions, or is only exposed to the public and majority of third party developers during a new product announcement only days before the release are still high risk and should receive higher levels of scrutiny, regardless of the overall test coverage. Ideally, the resources freed by investing in automated testing should be redeployed to address high risk areas of concern, but this is not always feasible.

In summary, this particular bug getting out into the field is not really a big surprise from a risk or probability standpoint. At least Apple can fix it quickly.

The bugs I find more annoying are the ones that rely on the kindness of a particular app or software developer to acknowledge  and fix when it’s their code alone that’s incompatible. 

lkrupp said:

Apple wants to make a big deal of how many and how fast users have upgraded to iOS 16 vs iOS 15, so much so they let iOS 16 out of the gate with a few baddies they either didn’t know about or couldn’t fix in time.

I don't see how one thing has anything to do with the other. Whether they released it a week ago, today, or two weeks from now, they can make a big deal about how fast users upgrade if users do indeed upgrade fast. It's not like people are gonna be like, "I don't wanna upgrade to this shit because it didn't get released sooner!"