Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
To be fair to some complainers, the Apple development process certainly creates a lot of regressions, so much so that I sometimes wonder if they are deliberately discouraging widespread beta adoption by putting them in.
Any competent development team shouldn't be changing stable code that has been running fine for years. Why should a new update be breaking bluetooth functionality or Apple Pay?
(I did work on commercial software that ran multiuser networked and real time on IBM PCs in 24-hour businesses and sold worldwide. Nothing like a few calls at 2am to encourage a developer to make sure they code defensively.)
 
  • Like
Reactions: VictorTango777
I have got the red number update on the latest PB, can’t get rid of it tried reboot, force reboot ........
Check in settings for a backup message, or iCloud update message or Apple Pay setup message. Maybe even log out and back into iCloud. The settings app badge is used for more than just a notification that there is an update these days and other items as mentioned will cause it to be on.
 
Last edited:
  • Like
Reactions: PickUrPoison
How is iOS 12 (in beta) compared to iOS 11 on your iPhone 5s?
Smoother in general. Battery life is a bit better, but it was never great on this phone to begin with, so any improvement is a plus.
No stuttering or lagginess in any of the stock apps.
 
Hm, I'm on PB6 and don't see any PB8 available on my iPhone X.
[doublepost=1534452468][/doublepost]
How is IOS12 Running oin the iPhone x??
It's running great for me ... no issues. I purposefully started with PB5 though to try and avoid the bigger bugs in the initial beta releases. Battery life is good, and everything is smooth like butter.

mmm, butter.
 
Hm, I'm on PB6 and don't see any PB8 available on my iPhone X.
[doublepost=1534452468][/doublepost]
It's running great for me ... no issues. I purposefully started with PB5 though to try and avoid the bigger bugs in the initial beta releases. Battery life is good, and everything is smooth like butter.

mmm, butter.
PB6 is the latest, equivalent to DB8.
 
The Developer Beta 8 is running very smoothly on my iPhone 8 Plus, my X and my iPP 10.5.

I do not want to get flamed, but I think...and it is only my perception...that Apple might be on the track to become like just before Steve Jobs returned. They might have too much in the pipeline. When Steve came back, he scaled everything back and concentrated on a few products. Just my opinion.
 
  • Like
Reactions: atomic.flip
Always wondered weather people would actually find 32 friends for group Face-time at once.

Works well on stage, but that's not reality.

It’s almost as though the feature won’t work if you need to FaceTime with fewer than 32 people...
 
To be fair to some complainers, the Apple development process certainly creates a lot of regressions, so much so that I sometimes wonder if they are deliberately discouraging widespread beta adoption by putting them in.
Any competent development team shouldn't be changing stable code that has been running fine for years. Why should a new update be breaking bluetooth functionality or Apple Pay?
(I did work on commercial software that ran multiuser networked and real time on IBM PCs in 24-hour businesses and sold worldwide. Nothing like a few calls at 2am to encourage a developer to make sure they code defensively.)
That’s exactly the point of ios 12. ripping up the innards of the operating system to achieve better results for the end users. The keynote at wwdc touches on this.
 
You seem to have a serious misunderstanding of both writing code and developers in general if you think that the *only* reason software would contain so many bugs is due to incompetent developers. A small development team at Apple can only find so many bugs based on the test devices they use. Once the software is released to a massive ‘developer’ base with *different* devices that’s when more bugs show. And then even more show up when the software gets released to the public.

This is completely and utterly wrong. First what's this about a "small development team"? This is the world's first trillion dollar company with their flagship product. This isn't some indie dev team that's overstretched and needing resources. Do you think Microsoft has a "small development team" working on Windows?

Secondly, the "development team" doesn't find bugs. The development team... develops. The QA team tests the software and logs bugs. Apple have it extremely lucky that they only need to test a TINY number of devices (compared to say Microsoft with Windows, which needs to be tested with a near infinite number of configurations).

Apple's QA team will be testing iOS on all these devices. They don't need to rely on external teams to tell them how iOS 12 runs on the iPhone SE.

Thirdly, the "developer beta" is NOT so developers can help Apple find bugs. Dear lord, seriously? The developer beta is so that developers can help spot problems with THEIR software ahead of the public getting iOS 12.

The reason for this is that Apple (and app developers) don't want everyone to download iOS 12 and suddenly find that all their favourite apps have problems running. Apple (and app developers) want a smooth transition for their customers.

Apple does NOT seed "developer betas" so that app developers (who pay Apple a yearly sum just to be app developers) can spend their free time helping Apple, a trillion dollar company, debug their software.

Finally, the "public beta" is there to kill the black market that had arisen from hobbyists wanting the latest iOS software. The side effect that some people might be able to assist with debugging has now been capitalised by Apple, but they cannot rely on it for serious testing: These people are amateurs, and Apple cannot trust that their flagship product to the general public who a) may not even download the beta, b) may not report bugs as they find them, c) may submit poor quality bugs that aren't usable by the dev team.
[doublepost=1534500550][/doublepost]
To be fair to some complainers, the Apple development process certainly creates a lot of regressions, so much so that I sometimes wonder if they are deliberately discouraging widespread beta adoption by putting them in.

Any competent development team shouldn't be changing stable code that has been running fine for years. Why should a new update be breaking bluetooth functionality or Apple Pay?

(I did work on commercial software that ran multiuser networked and real time on IBM PCs in 24-hour businesses and sold worldwide. Nothing like a few calls at 2am to encourage a developer to make sure they code defensively.)

It's possible that parts of these features have been rewritten from the ground up (I hope they have), but it's certainly surprising and worrying that, after a year of development for a release whose primary goal is to fix bugs, these major features are apparently so fragile.
 
Update: Apple has released a new version of iOS for its public beta testers. iOS 12 Public Beta 6 is identical to the eighth developer beta.

Where's the source for this? I can't find anyone else suggesting they've released developer beta 8 as public beta 6?

Edit: Double checked and it’s true. Installed on my SE and it’s running GREAT!
 
Last edited:
This is completely and utterly wrong. First what's this about a "small development team"? This is the world's first trillion dollar company with their flagship product. This isn't some indie dev team that's overstretched and needing resources. Do you think Microsoft has a "small development team" working on Windows?

Secondly, the "development team" doesn't find bugs. The development team... develops. The QA team tests the software and logs bugs. Apple have it extremely lucky that they only need to test a TINY number of devices (compared to say Microsoft with Windows, which needs to be tested with a near infinite number of configurations).

Apple's QA team will be testing iOS on all these devices. They don't need to rely on external teams to tell them how iOS 12 runs on the iPhone SE.

Thirdly, the "developer beta" is NOT so developers can help Apple find bugs. Dear lord, seriously? The developer beta is so that developers can help spot problems with THEIR software ahead of the public getting iOS 12.

The reason for this is that Apple (and app developers) don't want everyone to download iOS 12 and suddenly find that all their favourite apps have problems running. Apple (and app developers) want a smooth transition for their customers.

Apple does NOT seed "developer betas" so that app developers (who pay Apple a yearly sum just to be app developers) can spend their free time helping Apple, a trillion dollar company, debug their software.

Finally, the "public beta" is there to kill the black market that had arisen from hobbyists wanting the latest iOS software. The side effect that some people might be able to assist with debugging has now been capitalised by Apple, but they cannot rely on it for serious testing: These people are amateurs, and Apple cannot trust that their flagship product to the general public who a) may not even download the beta, b) may not report bugs as they find them, c) may submit poor quality bugs that aren't usable by the dev team.
[doublepost=1534500550][/doublepost]

It's possible that parts of these features have been rewritten from the ground up (I hope they have), but it's certainly surprising and worrying that, after a year of development for a release whose primary goal is to fix bugs, these major features are apparently so fragile.
Apple probably relies more on automated regression than humans testing. And I submit while there are probably a number of posters that are software/system engineers no one except Apple insiders know much of apple’s development process or software work force.
 
Well, that is a poor excuse since a lot of their software problems end up being ridiculously obvious issues hours after a public release and not strange fringe cases found weeks or months later. Also Apple has a beta program set up months in advance that gets into the "public" users hands and yet does not identify many glaring release issues.

Apple also controls their own hardware and has a limited range of product variations to target their software on so when Android or Windows can release on a much wider set of hardware and has greater initial quality and performance then many recent Apple OS releases, it just speaks volumes to the actual level of quality of Apple's development processes.

Lastly a trillion dollar valued company should not have a "small" development team incapable of delivering better initial release quality, not for something a prominent as the software required for the hardware that made them a trillion dollar company. I don't think this comes down to incompetent developers, but I think obviously there is a culture of poor executive leadership and overall denial at Apple where they think they are still producing the kind of quality they were known for back when Steve Jobs used to chew the heads off his development team when the color of an icon didn't come out right.

Excusing Apple for the plethora of iOS and Mac OS release bugs is nonsense. The company wants more money for their products and so my expectations of initial quality is, and should be, far higher then the average software company. If Apple wants to sell $300 phones full of bugs then my expectations will match the value of the phone. But sell me a $1300 phone and it is quickly broken or crippled by the next iOS patch or major release is inexcusable.

How many test plans have you written?

How many automated test suites have you written?

Do you have any knowledge of combinatorics?

Writing good tests is HARD, and it is impossible, for a large code base, to guarantee that all bugs have been eliminated, or even that all serious bugs have been eliminated. You can improve your process by requiring reviewers for every change, by using code coverage tools and requiring monotonically increasing test coverage for merges to mainline, by using static analysis tools (though this is fraught with false-positives), by using test generators, by using "fuzzing" tools, etc., but given the combinatorial challenges in a large code base and the time required to write and run tests, if you demand 100% statement and condition/decision coverage, you will never release.

Even then, you cannot cover all combinations of user environments (especially now, with plugins that allow for changing the behaviors of built-in applications with third-party code; e.g., Mr. Number and NoMoRobo for phone calls, picture editing plugins, ad blockers, etc.), and then there is the impossibility of recreating every possible sequence of user interactions in order to catch all corner cases.

Finally, there is the notion, to which I was first introduced at a talk by a guest researcher at Lawrence Livermore back in the early '90s, that at some point, you reach a minimum field-fault density. At that point, every attempt to fix additional bugs ends up introducing new ones, and the only way to get better from that point is to redesign and rewrite (at least portions of) the code base. He called this the "Reimann-Belady Curve," but I've not been able to find it in a search, so I may be misremembering it.

Throwing money at the problem DOES NOT fix it. See, e.g., Fred Brooks, The Mythical Man-Month.
 
  • Like
Reactions: PickUrPoison
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.