I just appended the following to the original bug.

--

UPDATE:

People have pointed out alternative workarounds in response to this bug, as posted on OpenRadar. One of these even seems to be officially sanctioned by DTS, but as far as I can tell, that doesn't make it less of a workaround for a genuine bug:

• https://gist.github.com/pkamb/5585751
• https://gist.github.com/karstenBriksoft/5308470

I hope this will help with locating the problem!

... this will simply be a leak. It's an unfortunate design decision on Apple's part (even though they have clearly thought about it and also a private property to retain self while being visible, see https://twitter.com/steipete/status/333629160708788225).

use a property like the rest of us :)

Apple responded having checked with engineering saying that this is expected behavior. They explained LocalDB uses very strong hashing functions and the delay is expected and, in fact, purposeful.

This is normal behavior. When CoreData hits a merge conflict it raises an exception, then attempts to handle it using whatever merge policy the developer has set.

Duped as rdar://13855002

This radar is staying on top here since months because of the wrong radar number!

Also Apple apps such as "Find my Friends" or "Find my iPhone" which seem to use MapKit suffer from the same performance problem.

Here's my radar on that topic: http://openradar.appspot.com/12088966

… on my 2011 17" MBP. Especially when plugging out the headphone jack. Mostly I notice there are no sounds when chatting in iChat/Messages. Then I plug out the headphone jack and sometimes all those buffered alert sounds are played. Filed a dupe: rdar://13848798

[Excerpted from a longer but no more informative email.]

Thanks very much for your feedback.

Engineering has determined that there are no plans to address this issue.

If you have questions regarding the resolution of this issue, please update your bug report with that information.

We are now closing this bug report.

Please be sure to regularly check new Apple releases for any updates that might affect this issue.

Please provide information and comments via the Apple Bug Reporter at http://bugreport.apple.com. Bug reports requiring your attention will appear under ‘My Originated Problems’.

Thank you for your assistance in helping us discover and isolate bugs within our products.

Best Regards,

Apple Developer Support

The tool "plutil -lint" is used to check the file, not -line as originally stated

Keith have you got any insight about collection view? I have both a table view and a collection view in my view controller, toggling their appearance with a bar button item, showing the same data.

Trying to call -reloadData on the collection view and table view doesn't affect the collection view. Is there any possibility to followup with the apple engineers about this for a suggested workaround?

Example project available here: http://d.pr/f/XPny

Yes Saniul, I remember reading about these remote view controllers a while ago. It's interesting to see that on iOS devices with 3.5" screens running iOS 6.x, the mail compose controller does initially use the settings you defined in -appearanceWhenContainedIn:, but only the first time. Other tries fail.

This is very interesting, proving it can be done, but there is obviously a bug. So, we can probably expect this fixed in iOS 7.

I would very much appreciate that functionality!!!

This radar helped me solve a tricky crash scenario in my application that was also silently crashing. My app was iterating over 1000+ files and using an NSFileHandle to check the first couple bytes of each file. When I initialized the handle with a URL, the application started working fine.

// Crashes after 1000 or so calls NSFileHandle *fileHandle = [NSFileHandle fileHandleForReadingAtPath:path];

// Does not crash NSFileHandle *fileHandle = [NSFileHandle fileHandleForReadingFromURL:[NSURL fileURLWithPath:path] error:nil];

However, I also found that I was not calling [fileHandle closeFile] before leaving the method. When I started calling [closeFile] my crash went away.

"issue behaves as intended"

Created a duplicate of the bug under rdar://13784595

This happens because Apple started using XPC in iOS 6 and View Controllers such as MFMailComposeViewController are actually run in a seperate process.

You can read more about it here: http://oleb.net/blog/2012/10/remote-view-controllers-in-ios-6/