All the tech nerd/mac nerd sites keep pointing to the UDID ban as the big news of the day. While that is indeed important, and every developer should make sure none of their code or 3rd party dependencies like crash reporters or ad networks use the UDID anymore, I think the most overlooked item of the day is Apple's second post.

As of May 1, iPhone 5 support is required. While this may be great news for those iPhone 5 users who are tired of apps not using those extra 88 points of vertical realestate, it is the final nail in the coffin for those still using iOS < 4.3 and iPhone 3G or iPod touch 1G/2G devices.

While most app developers had already set the minimum version supported of their products to 4, 5, or even 6, it was still techinically possible to support all the way back to 3.2 by using Xcode 4.4. That's because Xcode 4.4 still allowed you to target iOS 3.2 and create armv6 binaries. With Xcode 4.5, apple stripped armv6 support and set the minimum iOS target at 4.3. Apple has also decreed that if you want to support the iPhone 5, you must build with the iOS 6 SDK and at least Xcode 4.5, even though it still technically works with the iOS 5 SDK on Xcode 4.4 (Apple ties SDK versions to Xcode releases).

Yes, I know if you google hard enough there are ways to partially build in Xcode 4.5, take those results and re-build and archive them on Xcode 4.4 and submit THAT franken-binary, but that's way outside supported territory getting into submission rejection land for doing funky things. Bye Bye iOS 3 and iPhone 3G owners. It was nice knowing you, but at least now everyone can transition to ARC without feeling like it was their decision to cut off older customers.

With the release of iOS 6.1, my main product at work started flickering pretty badly. Sometimes the whole screen, and sometimes just small regions unrelated to view boundaries. I initially had no idea what was going on, but woke up at 4am the next morning with one thought keeping me awake. UIKit.

A few hours of hunting later and I found it. An UIAlertView was being created and shown from a background thread early in the app setup process, and once you triggered it the flickering continued sporadically until the app was killed with the task switcher. Once you got past this initial setup phase most users never trigger this particular alert view again, so it only affects new users (those most likely to leave App Store reviews). This bugged version is still available in the App Store at the time of this writing because of a software release process that I will rant about another day.

I knew it was almost certainly an alert view triggering this bug, so why hours? Because we have 150+ alert views in this app, and I had to try triggering nearly each and every one of the until I found the right one.

I hate the UIAlertView. How much do I hate it? Let me count the ways.

1. It’s an ugly hack for lazy programmers to stop the user from interacting with your app on a device that should always be under the users control, 100% of the time. And it can’t even do that. The device has a giant home button that always interrupts program execution and returns the device to the home screen. At any time. Good luck recovering your uninterruptible state upon relaunch when that happens.

2. It’s too easy to create. You don’t have to stop and think about where it belongs in you’re view hierarchy. You can create and show one anywhere with 2 lines of code and user interaction grinds to a halt. This is where my particular bug came in. My predecessor didn’t stop to think where he was calling it from.

3. It’s design is crap. Assuming you have a need for such a concept (you don’t), then at least make sure it doesn’t cause a mountain of spaghetti code when used. This class has a single app delegate who’s main method upon return only gives you a button index. It is your responsibility to keep track of what the buttons prompted the user to do, and if you have multiple alerts which one was shown and what the appropriate action to take upon their dismissal should be. This leads to long switch statements dispatching other functions at best, and a giant didDismiss…. function at worst. Let’s face it, you’re always crunched for time and doing the awful hack way.

4. There is no notification when you screw up. This is more of a UIKit hate in general, but if your going to require all UI state changes happen on the main thread, then by God have some way of enforcing it other than bugging out at runtime. Do some static analysis and throw a compiler warning. Abort() at runtime. Something other than random glitching on users please.

5. It’s a modal popup. I hate popups. You hate popups. Users hate popups. The only thing worse than a popup is a popup that forces you to interact with it.

It may have been necessary durning the 2.0 days when everything was single threaded, but now UIAlertView is a rotting crutch used by the stupid and the lazy. We’ve got blocks and GCD for doing data crunching in the background while keeping the UI responsive. We’ve got simple synchronization methods for updating the UI when the work is done. Just think about user experience for two seconds before using it. Please. That’s all I ask.

+++ tl/dr; Don’t touch UIKit from background threads. UIAlertView blows.

Way back in 2005, I bitched about Xcode’s autocomplete because it was always guessing wrong. It was super annoying because it wasn’t just a list of suggestions, it actually filled in the line and moved your cursor, so if you paused for a split second it gave you extra work instead of being a timesaver. Thankfully someone working on the source editor is a little less masochistic and switched it to a visual studio style list of suggestions.

The old asshole must have moved to working on LLDB, because now it has the same broken behavior the Xcode source editor used to have. Pause for a half second to see which account* object you want to inspect, and it “helpfully” fills in the wrong one, every time.

Between this and the awfulness that is OCUnit, it leaves me wondering if anyone at Apple ever uses Xcode to test or debug code, or if they all just use AppCode.