I last took the opportunity to bitch about UIAlertView when a threading error by my predecessor at work caused the screen to flicker. Along with all the problems mentioned in my last rant, it is also often abused by developers stuffing it with custom content, when the documentation clearly states it should be left alone.

Whether it was intentional or accidental collateral damage, iOS 7 breaks most existing UIAlertView customization methods. At WWDC, they announced a new -contentView property to allow these classes to do what they were doing before in a more supported manner. I was less than pleased. I wanted them to disappear, and Apple was promising to make them easier to use.

Lo and behold 3 months later and not only is -contentView not a property of UIAlertView on iOS 7 yet, but it looks like it will not be added at all. This makes me very happy. Not only does it mean other developers have to spent a few more minutes thinking about how this abused content should better fit into their UI, it gives me the political capital necessary to go back and undo some of the sins previously committed in this code base in the name of compatibility. Thank you, anonymous Apple decision maker!

Of course some people will never learn. There are already people in the developer forum that have found new ways to hook into the UIAlertView view hierarchy. I hope they get rejected in the review process and Apple continues to tweak the private class structure. Next step, burn it with fire!

My only concern is that @behrens suggests that people file a radar if they want to see the contentView property added in the future. What if I want it to stay gone? Do I file my own keep it out radar? Will enough people vote the same way with me?