As the not-so-mysterious September 10th Apple event approaches, it’s widely anticipated that the final version of iOS 7 will be released at the same time. Along with it will come a new version of XCode. While XCode is a pretty awesome development environment (in my opinion, at least), there are a few things that just irk the heck out of me. So, if anyone at Apple happens to be listening, here’s my laundry list of things I’d like to see fixed.
Keychain Madness
Although managing provisioning profiles and the associated keys is a lot better than it used to be, it’s still painful at times. Perhaps the most aggravating snag you can hit is ending up with two private keys in your keychain with the same name. Thankfully, XCode provides a sane error message now, rather than the obscure errors that used to occur, but it’s still a pain, especially if you happen to end up with two profiles that use different keys with the same name.
While we’re at it, can we get rid of the whole “upload a certificate request” dance that’s required to get a new profile started? Why can’t that all be handled on the portal side? For that matter, I’d love the portal to keep a copy of my secret key for me, so I don’t need to worry about losing it, and download it as part of syncing profiles in XCode. Right now, every developer working on a project needs to be sent a copy of the key to add into their own keychain, which is a pain.
Add Static Framework Support
I’m a big fan of using the iOS Universal Framework package to create common frameworks that I can use between projects. However, it’s still a second class citizen compared to the frameworks that Apple provides. For one thing, because it’s not part of XCode proper, it tends to break with new versions of XCode. It also doesn’t behave quite like a real framework; you have to manually add all the bundle resources into child projects and keep them up to date as the framework changes.
It’s well past time for Apple to add frameworks to the list of things you can build in XCode for iOS. There’s been static framework support for MacOS forever, so it shouldn’t be a heavy lift to Apple to extend the support to iOS.
Finish the Play on the Simulator
The iOS simulator is amazing, but there are a few things it doesn’t handle well. For one, the only way to simulate losing network connectivity is to turn it off on your Mac, which isn’t very nice. You also can’t change the time or timezone on the “device,” so you have to change it on the Mac as well. I’ve had more than one occasion when I checked in code with the wrong timestamp because I had forgotten to switch back from a test date I had set on my Mac.
The other big missing piece of the simulator is notifications. It would be truly lovely if the simulator could fake out being a device enough to receive notifications, as the only way to test them right now is on a physical device. And while I’m at it, how about letting developers use a webcam to simulate the camera?
Automation, Please?
The single biggest frustration iOS developers have is the lack of decent UI automation testing tools. Neither the automation build into Instruments, nor the capabilities in XCode itself, really allow QA people to create thorough UI testing suites.
What we need is the iOS equivalent of Selenium. It needs to be usable by non-developers, provide the ability to do pixel-perfect verification of apps, and handle all the UI gestures that a real user can generate. I know that testing tools aren’t as sexy as new features, but there is an army of development teams out there all struggling with the same problem.
And since I’m God for today, make it work from the command line. If I can’t integrate a testing tool into my Jenkins continuous integration toolpath, it loses a lot of its utility.
Oh yes, and can I have a pony too?