Using QuickRadar decreased my barrier of pain for filing Radars to a level that I find myself also filing way more benign ones like …
Filed as rdar://13450321 and on Open Radar. Please dupe it if you agree.
On more than one occasion I’ve been stumped by some new functionality from a newer iOS version crashing when used on an older iOS device. You know, the kind of problem that you’re supposed to catch yourself with a NSStringFromClass or respondsToSelector.
The recently released Deploymate app scans your Xcode projects for such problems and flags them. This proves that such an analysis is possible and can be implemented. The developer of Deploymate confided that he hesitated to release for a long while since he feared that Apple might put exactly this functionality into Xcode. But they never did, so he created the app.
This Radar is my documented suggestion to Apple to finally add such functionality into Xcode. Worst case they should acquire the technology employed by Deploymate and add that. But I am quite certain that LLVM’s analysis capabilities should be able to put to this use as well.
Filed as rdar://13436964 and on OpenRadar.
This is a feature request for something that could have used just yesterday. Filed as rdar://13271368 and on Open Radar.
Update: I was made aware by an Apple engineer that Xcode is indeed already autosaving versions of your files as you make changes. Versions is an OS X feature. But there is no Revert menu option in Xcode to access these saves. As a workaround you can open the source file in TextEdit and do the reverting there! A hidden feature that is so well hidden, it’s even in a different app!
I noticed the bug when I re-added an Edit menu to a Mac app that I had earlier removed. Turns out that all your NSTextFields lose their ability to cut/copy/paste and undo if you don’t have corresponding menu items.
So after I copied the menu over for another app I found that I couldn’t find the redo: action to connect to the Redo menu item. Filed as Radar rdar://13113666 and cross-posted on Open Radar.
I noticed this bug in NSTextField already back last year but I procrastinated until I saw it the second time in the second Mac app I am building. I did have a workaround for the bug, so it was not that pressing.
But I guess we should consider it our duty as Mac developers to make sure that Apple knows about bugs for this platform. So finally here’s my Radar for it. rdar://13006140
That was an easy Radar for me to file. It’s not a bug, but it is bugging me nevertheless.
I am disturbed by the disparity between the NSShadowAttributeName attribute (which can only hold a single NSShadow) and CSS where you can have multiple shadows. Because NSHTMLWriter simply copies these to the CSS style of a span it should be quite easy to to also let NSHTMLWriter take an array.
It’s not a very important feature to have, but hey … it would give me some peace of mind.
Filed as Radar#12908144.
While researching the root cause for the UITextView line-height bug I also found another difference between attributed strings rendered via CoreText and UITextView. The latter ignores font kerning.
UITextView uses Webkit for displaying attributed strings. Unfortunately Kerning is disabled on Webkit views unless you specify a certain CSS style.
If you look at the AV characters you can see how the version with Kerning enabled has the AV seem at a more natural distance while the lower line has an uncomfortably wide distance between them.
In the Radar (which I filed under #12889869) I argue that when setting text on UITextView via setAttributedString we developers expect for Kerning to be on by default since this is the way that is closest to how CoreText renders it.
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
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.