Dec 12, 2012
I’m working on making DTCoreText iOS 6 compatible and when implementing line heights I found this problem. Naturally I filed a radar.
This is one of many shortcomings of UIKit’s support for attributed strings. A workaround for this was described as having to omit font attributes from the attributed string. So you can either have multiple fonts and unchanging line height or only the font you set on the font property of UITextView.
Other people are having the same problem, as outlined by this question on StackOverflow.
Filed as rdar://12863734
Dec 03, 2012
That’s certainly a mouth full. We stumbled on this weirdness when working on PDF Importing for our iCatalog Editor. I am filing this as a Mac bug at the same time as communicating with DTS to see if they can offer a workaround for this problem.
The problem appears if a PDF is using a CMYK color blending space on a page for transparency blending. That causes this effect. Left side is how the PDF comes out on Mac, right side how it looks correctly on iOS (Simulator/Device). Also if you view the PDF in Preview or Pixelmator it looks weird, only in Adobe’s tools do they look correct.
If the behavior were the same on Mac and iOS then I would have thought to be Adobe using some weird special extension, but since the output is correct on iOS we think that this must actually be a bug. Maybe the Mac version of Quartz PDF rendering tries to do something smart since it is aware of color calibration but doing so messes up the colors.
Sep 30, 2012
Hot on the heels of my research into the responder chain comes this bug report. Nikita Korchagin deserves the main credit for mentioning this first to me.
Turns out that Apple broke the responder chain as it used to work on Mac and non-storyboard apps. I’m filing this as a bug report to find out if this indeed a bug or an “undocumented feature”. rdar://12402078
Update Oct 5th: Apple closed this as suplicate of rdar://12395544
Sep 24, 2012
This is one of those rare jewels of a bug that will cost you days to figure out if you encounter it in the context of a large app. It makes you doubt our own sanity until you come to the painful conclusion that the problem indeed resides in Apple’s code, not yours.
In this special case we had a couple of rare circumstances that worked together to form a scenario where CGRectMakeWithDictionaryRepresentation partially fails to reconstitute a CGRect from a dictionary. This function is literally ancient, it exists since iOS 2 and Mac OS 10.5. This makes it even more implausible that nobody has stumbled across this before us.
In the project where we first saw the problem these where the steps that led to this bug’s discovery:
- Create a CGRect that is not an integer
- Write a dictionary from iOS simulator which contains a dictionary encoding this CGRect
- Open this dictionary in Xcode’s property list editor
- Upon saving some of the least significant digits change in the “real” items
- This new dictionary can no longer be parsed on iOS
What’s even funnier is that some such modified values can still be read, but then the function fails internally and the remaining values don’t get parsed, i.e. stay zero.
From what I have seen researching this bug looks like certain floating point numbers cannot be represented on iOS. The normal parsing functions are able to round to the closest value that can be represented in 32-bit floats, whereas CGRectMakeWithDictionaryRepresentation fails to do so. The first value that cannot be exactly represented is truncated, all following values turn out to be Zero.
This was filed as rdar://12358120 and on OpenRadar.
Sep 05, 2012
It is understandable to have this ominous “Natural Scrolling” setting for trackpads. And that there is a separate such setting for mice. But I don’t understand why Apple would like these two settings, because somebody working on a laptop might want to use the normal way to scroll with his mouse’s scroll while while using the “natural” setting for his trackpad.
Filed as Radar #12236447 and cross-posted on OpenRadar.
Updated March 6th, 2013: “Works as Intended”
Aug 24, 2012
I got an AppleTV for our office and brought over my old Sharp TV which is able to display 720p well enough to be used as a presentation display via AirPlay. When I tried to use AirPlay to display the desktop of a MacMini server I discovered this bug.
The workaround at the moment is to use the AirParrot software which has no problems displaying the desktop. I filed it as rdar://12167290 and mirrored it on OpenRadar.
Update Nov 7th: Apple closed the bug report as a duplicate of rdar://11782381.
Jun 28, 2012
Here’s another thing that I had discussed with an Apple engineer at WWDC. UIWebView at present does let you easily modify the user-agent header field that it sends to the server. We found this functionality sorely lacking when we needed to change the user-agent in iCatalog. There are some scenarios where the server-side browser-detection fails and you want to override the user agent for example with one to pretend the web view is desktop Safari.
This feature request was filed as rdar://11767306 and on OpenRadar.
Jun 25, 2012
Fresh from our series “Another Day Another Radar” here’s one that stumped my associate Rene.
Since I’m getting a knack in filing these I did the “quick file” for him, as rdar://11738458 and on OpenRadar. As always I am doing this publicly because other people out there might have experienced the same issue which can be quite nerve-wrecking. Also this problem was observed on an OS X version that is public and widely used.
Jun 21, 2012
There’s a gotcha/bug if you’re using -[UIColor CGColor] to get a CGColorRef for use with CoreGraphics. I think several people have already documented this on their blogs, but I was having the same issue in my DTCalendarView when running it on device. The same code worked before enabling ARC, but with ARC enabled it there is a difference whether its running on device or simulator.
On Simulator all is fine. On device however you get a EXC_BAD_ACCESS because the ARC release the UIColor way before the end of the current scope. There are several possible workarounds but it is still unintuitive that previously working code ceases working with ARC.
We were told to also file bug reports for unexpected behaviors or something that is counter intuitive, so here you go… Radar #11717864 and OpenRadar. Here’s the sample project.
Update: Yes, I know that you could call this “works as designed”. But the point here is that it is non-obvious and causes previously working code to break. Even the gurus at the Big Nerd Ranch stumbled over this one and filed is filed. In the least I would expect an LLVM compiler warning for this to be added.