Setting UIAppearanceProxy on UINavigatonBar screws up MFMailCompose/MFMessageComposeViewController's nav bar
||Date Originated:||17-Feb-2017 09:23 AM|
If you set an appearance proxy on [UINavigationBar appearance] without using `appearanceWhenContainedInInstancesOfClasses` and passing in a custom navigation controller class, it screws up the navigation bar on MFMailComposeViewController and MFMessageComposeViewController, as well as other system-provided classes which subclass UINavigationController. This setting persists even if you manually reset the appearance proxy on these other classes.
Steps to Reproduce:
PREREQ: Must be installed on device since the simulator no longer has the two classes which definitely reproduce the bug, so it crashes when attempting to present them.
1. Open attached project.
2. Install on device using “AppearanceProxyBugProof - Direct” scheme.
3. Note the delightfully fugly navigation bar, with custom colors and fonts.
4. Tap the “email” button.
5. Note that despite setting font back to something normal and colors back to normal on the nav bar using `appearanceWhenContainedInInstancesOfClasses` and explicitly passing in the `MFMailComposeViewController`, the background color and title text attributes are still fugly. Looks like the nav bar buttons recovered.
6. Close out of the email composer, deleting the draft.
7. Tap the “SMS” button.
8. Note that the fugly background color has been reset, but the title text attributes are still showing the fugly font/font color. Again, nav bar buttons seem to have recovered.
Resetting the appearance proxy on specific classes allows you to use their default appearances.
See “steps to reproduce”
This has been happening since the iOS 7 transition. From my original radar on this, 15526703, filed in November 2013: “In iOS 6, setting the tintColor on the navigation bar proxy in the same way using the appearance proxy updates the bar's background color. My guess would be this is something that was overlooked in the migration from tintColor to barTintColor”.
Original radar was closed as a dupe, and I can’t actually access the original at radar.apple.com anymore to see if the issue it was tied to ever got closed. I’ve seen this problem floating around in the wild ever since so I figured I’d see if it’s still happening. Yep!
I have included the workaround I’ve been using for the last three and a half years - if you build and run the AppearanceProxyBugProof - Custom Nav” scheme, you’ll see that when I create an otherwise useless UINavigationController subclass and set the proxy to be only on instances of this subclass, the issue goes away.
Reports posted here will not necessarily be seen by Apple.
All problems should be submitted at bugreport.apple.com before they are posted here.
Please only post information for Radars that you have filed yourself, and please do
not include Apple confidential information in your posts. Thank you!