iOS 11.2 Beta Fixes Calculator Bug Causing Incorrect Calculations when Numbers Are Rapidly Entered

[sdf]

Bugs are excusable; Apple's response is unworthy

Reality check: This bug has been in the light for about a week. It was never going to make it to 11.1 in a week; assuming there's no 11.1.1 planned, 11.2 is the soonest it could be fixed. And we have no idea when that's coming out. It could be mere days (but is probably by the end of November or very early December).

 

[C DM]

Reality check: This bug has been in the light for about a week. It was never going to make it to 11.1 in a week; assuming there's no 11.1.1 planned, 11.2 is the soonest it could be fixed. And we have no idea when that's coming out. It could be mere days (but is probably by the end of November or very early December).

To be fair Apple has known about it for much longer, it's just that they haven't gotten to it until recently for one reason or another.

 

[bjet767]

A calculator fix should simply be an update from the app store, period.

This wasn't an "App" issue, it is a fundamental change in how iOS transitions views in 11. What we need to understand is the "UIButton" is an object that "inherits" from an "UIControl," and in turn "inherits" from the "UIView."

For some silly reason Apple iOS developers decided that we users did not have fancy enough animated transitions between our "UIViews" so they programmed some new moves which work on really fast new models, but stink on the older ones.

But they forgot there's a short delay while the animation takes place, so it (the UIButton) ignored a fast touch while it did its animation dance.

 

[chucker23n1]

For some silly reason Apple iOS developers decided that we users did not have fancy enough animated transitions between our "UIViews" so they programmed some new moves which work on really fast new models, but stink on the older ones.

But they forgot there's a short delay while the animation takes place, so it (the UIButton) ignored a fast touch while it did its animation dance.

Even on my iPhone 8, the transition wasn’t fast enough for Calculator to handle properly. Supposedly, it was rewritten in Swift, so I don’t think your explanation that it was merely compiled against an SDK with a behavioral change is sufficient.

 

[samwight]

Making a statement about reality doesn't mean defending, just because it's not attacking at the same time.

Not necessarily, but in context, your reply was a defense of Apple.

 

[bjet767]

I don’t think your explanation that it was merely compiled against an SDK with a behavioral change is sufficient.

That’s not what I wrote.

This is a far bigger change than a simple recompile and you really don’t fully understand how much the UIView actually does. The view is the heart of everything a user sees and touches, while simply calculating numbers is something all CPUs do well, but how the OS gets those numbers is where the problem lays.

Video your iOS device in slo-mo as you use it sometime and see how the various layers change as you do things. It’s an animation nightmare.

 

[C DM]

Not necessarily, but in context, your reply was a defense of Apple.

As in that is what was read into it, rather than what was actually said.

 

[Bacillus]

To be fair Apple has known about it for much longer, it's just that they haven't gotten to it until recently for one reason or another.

And those guys are supposed to sell me a self-driving car? Give me a break...

 

[chucker23n1]

That’s not what I wrote.

This is a far bigger change than a simple recompile and you really don’t fully understand how much the UIView actually does. The view is the heart of everything a user sees and touches, while simply calculating numbers is something all CPUs do well, but how the OS gets those numbers is where the problem lays.

Video your iOS device in slo-mo as you use it sometime and see how the various layers change as you do things. It’s an animation nightmare.

Right, so your point is that you learnt something about a UI framework and want to brag about it.

Are you asserting that Calculator was old code compiled against a newer SDK, and that the developer didn’t read the release notes? Or that, without a recompile, the behavior changed anyway?

 

[sdf]

To be fair Apple has known about it for much longer, it's just that they haven't gotten to it until recently for one reason or another.

That 's totally possible, but certainly not proven.

 

[C DM]

That 's totally possible, but certainly not proven.

Well we know that the issue has been reported to them and has been in open state with many duplicates for some time. We also know that the fix for the issue didn't show up until iOS 11.2 beta 1.
[doublepost=1509550698][/doublepost]

And those guys are supposed to sell me a self-driving car? Give me a break...

Are you saying that those who are working on self-driving cars haven't been or aren't involved with the same companies that put out other products that also have had issues? Even extremely important military systems have issues here and there (as I even recall a developer on such systems commenting on that not long ago in one of the threads where this kind of discussion also came up).

 

[bjet767]

Right, so your point is that you learnt something about a UI framework and want to brag about it.

The point is Apple has clearly messed up, not the just the App, but in my opinion (and I stress my opinion) their approach to iOS. Do we need for the view animations to be so special or is simple, smooth and fast a better user experience? Additionally, what does it say about Apple's QC and the associated pressures for something "new" and "innovative" when such stuff is released to the general public?

Was it old code, a recompile, reliance on older UIView calls, or some other thing which causes this issue? You decide, and in case you haven't noticed the problem isn't limited to the Calc App. The delay with touches and animations occurs almost anywhere those actions are needed. It's just bad math is a whole lot more noticeable than typing a character in error while sending a message.

As far as the question about why this flaw slipped through the cracks of QC, consider for yourself, with the complexity of iOS, if you would have noticed the error?

What I really think is you need to quit trying to read something into other's posts in an attempt to stir up some sort of controversy.

 

[chucker23n1]

Was it old code, a recompile, reliance on older UIView calls, or some other thing which causes this issue? You decide, and in case you haven't noticed the problem isn't limited to the Calc App.

Except that it is. You still haven't answered whether you believe that UIKit retroactively changed the behavior of applications compiled against an older SDK or not.

What I really think is you need to quit trying to read something into other's posts in an attempt to stir up some sort of controversy.

You're the one stirring the pot by making a claim then refusing to back it up. Not my problem.

 

[bjet767]

Except that it is. You still haven't answered whether you believe that UIKit retroactively changed the behavior of applications compiled against an older SDK or not.

Basically you don’t know and have no clue who wrote the native apps or what they were coded in. Was it C, C++, Objective C or Swift? You don’t know and my observations stand as valid.

Now what do I believe about iOS 11 and it’s effect on apps? Exactly what I’ve posted, they have been effected no matter if the native apps were recompiled or not with the latest version of the API; THEIR BEHAVIOR HAS BEEN EFFECTED BY iOS 11 PERIOD.

Now I have some questions for you, do you develop iOS apps, do you have any in the App Store and we’re they effected, recompiled or not, by iOS 11? My answer to all those questions is yes and I’ve been developing apps since iOS 4, all in objective C BTW.

For your information, I have always been stating my opinions and observations which you seem to find offensive. Please back off!

 

[samwight]

As in that is what was read into it, rather than what was actually said.

As in what was understood by what was actually said. The same words mean different things in different contexts, and in the context in question, I understood what was actually said to be a defense of Apple. And if it wasn't, I still have no idea what message you were attempting to communicate.
[doublepost=1509614511][/doublepost]

Reality check: This bug has been in the light for about a week. It was never going to make it to 11.1 in a week; assuming there's no 11.1.1 planned, 11.2 is the soonest it could be fixed. And we have no idea when that's coming out. It could be mere days (but is probably by the end of November or very early December).

My objection was not the timing, but that they found it necessary (or expedient) to ditch the animation instead of fixing it, and that a new OS was needed considering all they did was remove the animation.
[doublepost=1509614949][/doublepost]

This wasn't an "App" issue, it is a fundamental change in how iOS transitions views in 11. What we need to understand is the "UIButton" is an object that "inherits" from an "UIControl," and in turn "inherits" from the "UIView."

For some silly reason Apple iOS developers decided that we users did not have fancy enough animated transitions between our "UIViews" so they programmed some new moves which work on really fast new models, but stink on the older ones.

But they forgot there's a short delay while the animation takes place, so it (the UIButton) ignored a fast touch while it did its animation dance.

But they just got rid of the animation.

For all your UI-jargon, the keyboard uses rapid input with animations and does not have this problem. Neither do other calculators. Obviously rapid input with animations works in the current version of the OS. In fact, one of the iPhone's claim to fame from 2007 on was the intelligent multi-touch input that made the keyboard work so great at any rate of input and in spite of errors etc. Now you're arguing a fundamental issue prevents rapid input with animations that can only be corrected with a new version of the OS, and I'm not buying.

 

[bjet767]

Now you're arguing a fundamental issue prevents rapid input with animations that can only be corrected with a new version of the OS, and I'm not buying.

Sam I understand you’re not buying it, but what I have found is there are fundamental problems with the transition animations that are noticeable on older iPhones, particularly 6 and older. I have access to the 6+ and newer versions for testing and the problem seems to be minimal if not as noticeable. The current iPad Pro I’m typing on right now also seems okay.

I have documented in slo-mo the issues and sent bug reports with the videos to Apple. It does not require a new version of iOS just a fix. What Apple has done is add a rapid zoom and contraction to transition from one to another, this is what’s new and causes that “ lagging” impression so many are reporting on other threads. It also allows the user to type early on the keyboard prior to the old view disappearing and display typing errors as the text view is given priority.

Apple will “fix” things if they perceive enough users are unhappy with the interface. If not, buy new device is the solution for the unhappy.

 

[samwight]

Sam I understand you’re not buying it, but what I have found is there are fundamental problems with the transition animations that are noticeable on older iPhones, particularly 6 and older. I have access to the 6+ and newer versions for testing and the problem seems to be minimal if not as noticeable. The current iPad Pro I’m typing on right now also seems okay.

I have documented in slo-mo the issues and sent bug reports with the videos to Apple. It does not require a new version of iOS just a fix. What Apple has done is add a rapid zoom and contraction to transition from one to another, this is what’s new and causes that “ lagging” impression so many are reporting on other threads. It also allows the user to type early on the keyboard prior to the old view disappearing and display typing errors as the text view is given priority.

Apple will “fix” things if they perceive enough users are unhappy with the interface. If not, buy new device is the solution for the unhappy.

Yea, I don't have an old phone, but the calculator bug is obvious on the 7+, while I've not seen evidence of a problem anywhere else. If Thomson can make pcalc work on the current OS, Apple ought to be able to make a much simpler calculator work on the same OS.

 

[sdf]

Well we know that the issue has been reported to them and has been in open state with many duplicates for some time.

We know "some time," where I assume you mean more than a few weeks? I haven't seen any evidence of this. What have you got?

Even if they had a report or two of this prior to it hitting the public, Apple deals with (literally) thousands of bugs. When looking for "unforgivable" behaviour, I think you need something more than a minor bug being put off a few releases. I don't think we've got anything near that.
[doublepost=1509646565][/doublepost]

My objection was not the timing, but that they found it necessary (or expedient) to ditch the animation instead of fixing it, and that a new OS was needed considering all they did was remove the animation.

I don't understand this. Apple doesn't have a way of updating Calculator without updating the OS?

 

[bjet767]

I don't understand this. Apple doesn't have a way of updating Calculator without updating the OS?

Yes they could, but apps aren’t always updated immediately when the OS is updated and native apps seem to always come with the OS update.

So was it updated with the OS or not? We only know it broke with 11 and had to be updated later.

The question is can Apple update a native app outside of a new iOS update? They could, but I’ll bet they would still send it via an iOS update and fix misc other bugs at the same time.

 

[C DM]

We know "some time," where I assume you mean more than a few weeks? I haven't seen any evidence of this. What have you got?

Even if they had a report or two of this prior to it hitting the public, Apple deals with (literally) thousands of bugs. When looking for "unforgivable" behaviour, I think you need something more than a minor bug being put off a few releases. I don't think we've got anything near that.
[doublepost=1509646565][/doublepost]

I don't understand this. Apple doesn't have a way of updating Calculator without updating the OS?

People have brought up the issue back in the iOS 11.0 beta days and have talked about it being reported to Apple. That said, I haven't said anything about it being "unforgivable" or anything close to it--in fact most of my posts in relation to it have been quite a ways off from that.

And given the current setup it seems like a stock iOS app like the Calculator can't be updated outside of an iOS release. By even with all of that it assumes that the fix for all of this is just in the Calculator and not elsewhere in iOS.

 

[maxjohnson2]

So just updated to 11.1 final this morning. Still not fixed. I think they'll just let it go until iOS 12 come out, new feature: working calculator.

 

[C DM]

So just updated to 11.1 final this morning. Still not fixed. I think they'll just let it go until iOS 12 come out, new feature: working calculator.

It's already fixed in iOS 11.2 beta 1--which is what this whole article and discussion is about.