What's new

IOS 5 BETA 6 dropping on the 17th

iJeff

New Member
Joined
Jun 6, 2011
Messages
1,612
Reaction score
12
Location
Maryland
Just after the newly released BETA 5 Apple announces that they will drop BETA 6 on the 17th. Just an FYI.....
 
jbs06civicsi said:
Just after the newly released BETA 5 Apple announces that they will drop BETA 6 on the 17th. Just an FYI.....

Where did you see this?

Sent from my iPhone using iPF.net
 
Sometimes I wonder why don't they just do everything that they need to improve on before they let it out. I mean they have their own judgement.
 
Sometimes I wonder why don't they just do everything that they need to improve on before they let it out. I mean they have their own judgement.

The answer to that question is rather long. But I'll give you the short version.

iOS is a mulit-million line Operating System that has to be compiled for the following hardware: iPhone 3GS GSM, iPhone 4 GSM, iPhone 4 CDMA, iPad 2 WiFi, iPad 2 GSM/WiFi, iPad 2 CDMA/WiFi, iPod Touch 4th Gen, iPhone 5 GSM, iPhone 5 CDMA, iPad 3.

That means they need to be able to test every application currently on the Market against every WiFi configuration, every screen resolution, every cell phone carrier, every memory configuration, every CPU clock speed, etc, etc and etc....

Just that list alone results in trillions of combinations that need to be tested. The staffing required to test would be in the tens of thousands. That would be very cost prohibitive. Their solution is simple, they release it to us developers and we can help find the issues. Since we do have a vested interest in the success of iOS 5.

Since every iOS developer is under an NDA there should be no news what-so-ever concerning the status of iOS 5. But the reality is, some people don't care what they signed or the consequences of their actions. Personally, I abide by the NDA, which is why I have not posted a single sentence since I have switched to it.
 
Skull One said:
The answer to that question is rather long. But I'll give you the short version.

iOS is a mulit-million line Operating System that has to be compiled for the following hardware: iPhone 3GS GSM, iPhone 4 GSM, iPhone 4 CDMA, iPad 2 WiFi, iPad 2 GSM/WiFi, iPad 2 CDMA/WiFi, iPod Touch 4th Gen, iPhone 5 GSM, iPhone 5 CDMA, iPad 3.

That means they need to be able to test every application currently on the Market against every WiFi configuration, every screen resolution, every cell phone carrier, every memory configuration, every CPU clock speed, etc, etc and etc....

Just that list alone results in trillions of combinations that need to be tested. The staffing required to test would be in the tens of thousands. That would be very cost prohibitive. Their solution is simple, they release it to us developers and we can help find the issues. Since we do have a vested interest in the success of iOS 5.

Since every iOS developer is under an NDA there should be no news what-so-ever concerning the status of iOS 5. But the reality is, some people don't care what they signed or the consequences of their actions. Personally, I abide by the NDA, which is why I have not posted a single sentence since I have switched to it.

Wow!! I can say I learned a lot from your post!

Sent from my iPad using iPF.net
 
17th? August? September?

Edit: Nevermind...found it. 17th of august. .)

Google is my friend.
 
Last edited:
I feel sometimes that many users have no idea what goes in behind the scenes to release software to the public. Your post covers all the issues furthermore getting it right is the highest priority and that has been The case since 1977

So just be patient let the beta testers do their job

Sent from my iPhone using iPF.net
 
Jani said:
17th? August? September?

Edit: Nevermind...found it. 17th of august. .)

Google is my friend.

Ok, speak to me like I'm 5, what does the 17th mean to a regular "Joe" like myself?

Sent from my iPad using iPF.net

If your not planning on installing beta 6 for the next firmware (ios5) it wouldn't mean anything. You can only beta test if your a iPhone developer.
 
Last edited by a moderator:
As an after thought, I would like to provide one other insight into the process.

Many developers categorize software issues into several buckets. The top 3 are usually:
1) Hardware/Software crash.
2) Software produces unexpected results.
3) Users perception of how to use the software produces unexpected results.

The reason Apple only wants Developers to test Beta versions of iOS is because we have the ability to list which bucket a bug belongs in and a gauge of the severity. It also helps that we have the ability to type up the steps needed to reproduce the issue. Or at least provide the scenario that produced the issue. Those insights are very critical to tracking down the nastiest bugs.

Now the funny thing is, I listed the bugs in the order of easiest to hardest in terms of troubleshooting. That's right, software crashes are simple to troubleshoot compared to user perception issues that create unexpected results.

When I code a new module for an application I have a simple five step process for testing when it comes to input and output.
1) No data.
2) Partial data.
3) Expected data.
4) Corrupted data.
5) Unexpected data.

The first 3 are easy to generate and test. The 4th is a tad harder but usually has to do with over/under flowing of data. But the 5th one is the nightmare. A user types in something that seems 100% legit to them but your program didn't account for it.

Let me give you a real world example to help explain.

I have a multi-million line code base that is used in the HVA/C industry. I have users in several countries. I decided to create a new Date Widget that would allow the user to type in the date or hit enter in input box to bring up a simple widget. It worked perfectly in "standard windows configuration" but failed under a condition I never thought to test, my case 5. A user always has to set his Calendar date input format when installing Windows. My program reads this setting directly from Windows at input screen instantiation. At the time that makes perfect logical sense. Except when a French Canadian user decides that he needs output a quote from my program in US Dollars just once. So he goes into windows setting to adjust the display from 1.000,00 to 1,000.00. Normally that would be no big deal but he also thought he had to adjust the date format as well. He adjusted Windows while the data input screen, with that widget, was open and waiting for input. He then typed in the date of 09/24/2010. The program suddenly crashed. Since my program, when it relaunches, auto recovers the users information, suddenly everything was fine and the program behaved as expected. UNTIL... He did the same thing in reverse. He started a job, got to that screen and remembered "I have to switch back to my normal currency and date". He does so, types in 24/09/2010 and BAM another crash. He then calls me for tech support because the program has now crashed twice in the same place and it shouldn't be. Most of the programmers reading this have already figured out what happened because I gave away the clue early on to the actual failure. Because I set the preference in the Widget at the time the screen was created, the computer saw the wrong date format and barfed. Basically I tested to see if the data was nn/nn/nnnn. Since that test passed, I then tested to see if the nn were within range. But I had taken a short cut and only tested for 1 to 31 on both of the first two numbers. Big mistake. Because when I fed the date to the widget it barfed because I had set the format BEFORE Windows had been changed. Feeding the day of 24 to a month parameter caused a crash of "Illegal Date" and because I wasn't expecting an error there I treated it as an unrecoverable error. Took me the better part of 4 hours looking over the two error logs and interviewing the user for 45 minutes to piece it together. The fix was dirt simple. Move part of the setup code to the validation of the data. That way the users could switch date formatting at will.


Just imagine how many issues like this they have to deal with considering how many languages and regions the iPhone is going to be deployed to in the next year alone.
 
Excellent post skull one. Thanks for bringing this information to everyones attention.

iPhone 4 16Gb 4.2.8 (jbme 3.0)
 
Skull One said:
As an after thought, I would like to provide one other insight into the process.

Many developers categorize software issues into several buckets. The top 3 are usually:
1) Hardware/Software crash.
2) Software produces unexpected results.
3) Users perception of how to use the software produces unexpected results.

The reason Apple only wants Developers to test Beta versions of iOS is because we have the ability to list which bucket a bug belongs in and a gauge of the severity. It also helps that we have the ability to type up the steps needed to reproduce the issue. Or at least provide the scenario that produced the issue. Those insights are very critical to tracking down the nastiest bugs.

Now the funny thing is, I listed the bugs in the order of easiest to hardest in terms of troubleshooting. That's right, software crashes are simple to troubleshoot compared to user perception issues that create unexpected results.

When I code a new module for an application I have a simple five step process for testing when it comes to input and output.
1) No data.
2) Partial data.
3) Expected data.
4) Corrupted data.
5) Unexpected data.

The first 3 are easy to generate and test. The 4th is a tad harder but usually has to do with over/under flowing of data. But the 5th one is the nightmare. A user types in something that seems 100% legit to them but your program didn't account for it.

Let me give you a real world example to help explain.

I have a multi-million line code base that is used in the HVA/C industry. I have users in several countries. I decided to create a new Date Widget that would allow the user to type in the date or hit enter in input box to bring up a simple widget. It worked perfectly in "standard windows configuration" but failed under a condition I never thought to test, my case 5. A user always has to set his Calendar date input format when installing Windows. My program reads this setting directly from Windows at input screen instantiation. At the time that makes perfect logical sense. Except when a French Canadian user decides that he needs output a quote from my program in US Dollars just once. So he goes into windows setting to adjust the display from 1.000,00 to 1,000.00. Normally that would be no big deal but he also thought he had to adjust the date format as well. He adjusted Windows while the data input screen, with that widget, was open and waiting for input. He then typed in the date of 09/24/2010. The program suddenly crashed. Since my program, when it relaunches, auto recovers the users information, suddenly everything was fine and the program behaved as expected. UNTIL... He did the same thing in reverse. He started a job, got to that screen and remembered "I have to switch back to my normal currency and date". He does so, types in 24/09/2010 and BAM another crash. He then calls me for tech support because the program has now crashed twice in the same place and it shouldn't be. Most of the programmers reading this have already figured out what happened because I gave away the clue early on to the actual failure. Because I set the preference in the Widget at the time the screen was created, the computer saw the wrong date format and barfed. Basically I tested to see if the data was nn/nn/nnnn. Since that test passed, I then tested to see if the nn were within range. But I had taken a short cut and only tested for 1 to 31 on both of the first two numbers. Big mistake. Because when I fed the date to the widget it barfed because I had set the format BEFORE Windows had been changed. Feeding the day of 24 to a month parameter caused a crash of "Illegal Date" and because I wasn't expecting an error there I treated it as an unrecoverable error. Took me the better part of 4 hours looking over the two error logs and interviewing the user for 45 minutes to piece it together. The fix was dirt simple. Move part of the setup code to the validation of the data. That way the users could switch date formatting at will.

Just imagine how many issues like this they have to deal with considering how many languages and regions the iPhone is going to be deployed to in the next year alone.

Nice.
 
When is iOS 5 coming out

Apple doesn't make it a habit of announcing a time frame and missing it. Though it does happen on occasion. Since Apple said Fall of 2011, that means the last day they can release it and still be technically correct is Dec 21st. So 19 weeks from today. My guess it will be closer to 11 weeks or sooner from now.
 
Top