iPhone App development – part 2

A few weeks after my first post regarding iPhone app development, I’m slowly being driven more inane with the entire process. I’ve found my feet with Obj-C, but there are new headaches to contend with…

Enrollment

The first of these is the worst. I understand Apple’s reasoning behind allowing developers access to the SDK before having to pay for access to the full program, and this would be fine apart from the ridiculous enrollment process. So far it has been five weeks – that’s right, FIVE WEEKS – since first applying for the program, and only today, after several faxes and phone calls, could I actually pay. I’m still waiting for my activiation code.

Apple are making piles of cash from the App store – it has been their primary marketing focus for the last few months. A small delay is understandable, but over a month is just crazy. Not only is it irritating, but it hinders development significantly as the simulator simply isn’t a proper testing platform.

My advice is this: if you’re thinking about developing an iPhone App, enroll before you even crack open the SDK.

Limited support

Parsing XML is surely one of the most common operations that can be performed on a web-enabled device. So why do we only have access to a crappy SAX-based parser? There are a few 3rd party libraries out there but a native DOM-based solution using XPath wouldn’t be asking the world.

Memory leaks

Considering Objective-C on the iPhone has no automatic garbage collection, memory leaks can be a bit of a problem. Part of the pain can be eased with the Leaks application and a large dollop of guesswork. What doesn’t help is that there are several common areas where memory leaks seem unavoidable:

  • Synchronous connections with NSURLConnection. What looks like an internal bug with NSURLConnection means that synchronous requests leak, especially when run in a background thread (which are often used to avoid locking up the UI during the request).
  • The above bug has knock on effects with NSXMLParser, or with any class with an initWithContentsOfURL method such as the UIImage class.

Many people recommend using asynchronous requests instead, but implimenting these involves even more hassle, and didn’t resolve all my issues. We aren’t talking huge leaks here, but after spending days trying to iron Apple’s own issues, the urge to track down my legitimate leaks has waned.

Posted October 3rd, 2009 in Objective-C, iPhone.

Leave a response: