For those who are not familiar with iPhone development, Apple recently required that all iPhone apps be compatible with their upcoming iPhone OS 3.0, otherwise, they would be rejected from the App store. As our current Darkroom version is not OS 3.0 compliant and together with an increasing number of users questioning the lack of support for OS 3.0 beta, we submitted an updated Darkroom to include just the support for OS 3.0 beta to Apple.

For some reason or another, our latest update was rejected. We are scratching our heads here because we updated Darkroom so it can support OS 3.0. But after reading the email from Apple, it was not an issue with OS compatibility, rather it was an issue with us modifying or extending an undocumented API. Say what?!

The fact is, we have always been using their published APIs when developing Darkroom. Sure, we need to transverse into camera’s subviews and access the button event control programatically to delay the shutter action (so that we can check the steadiness of the device), but we only use published API (UIControl’s API) to accomplish that. Therefore this certainly complies with iPhone SDK Agreement section 3.3.1. All core features of Darkroom, such as steady mode, timer mode, and full screen shutter mode require an extra interface for the camera. Otherwise, such functions will not work if it’s not for the custom interface.

Apple has been approving this since we started developing Darkroom, but why this sudden rejection? We believe that other camera apps, such as Night Camera, CameraKit, Camera Zoom, QuadCamera, ProCamera, CameraBag, Pano, Fast Tap Camera, Self-Portrait and many others are also using this method to create their own camera interface as well.

We’d understand if Apple decides to reject apps when they first make their way to the app store, but when our existing app is updated specifically to meet Apple’s new policy (OS 3.0 support) and it gets rejected, we see discrepancies in their approval process and it’s misleading developers. Ultimately though, users and especially the paying customers will no longer have access to the functionalities which they paid for.

Are you a iPhone app developer? Feel free to comment if you have had similar issues with Apple’s approval process?

Two of the issues that have been bugging our Darkroom and Darkroom Premium camera apps are the slow photo saving time and the lack of EXIF information, such as geo-tagging, in the saved photos. Of course, there are various factors that could affect the performance and functionality of the application, but the core cause of these problems is in the API provided by Apple to perform such functions.

(more…)

At the moment, iTunes store has no mechanism to provide free trials to users. Developers have three choices to offer similar experience:

• Refund? Actually, there are no refunds allowed on the iTunes store as stated on Apple’s policy. Even though some customers did successfully receive their refund, but some didn’t.
• Offer a limited time free download on your app initially.
• Create separate Free and Paid versions. Free version should have some basic but useful functionality, and hopefully the user will find it useful enough to purchase the paid version with premium features.

(more…)

It is quite common to have to display time information in your app, be it the current time, news feed’s creation date, scheduled meeting time or birthday reminders. However, not all of them are displayed the same way and may require different formatting. To do that with Objective-C for iPhone apps, NSDateFormatter is what we need.

(more…)

Sales and download analysis is an important task to improve your software and its marketing. I am glad that Apple provides a daily and weekly report on my iPhone App sales. The problem is that they purge the historical data on a regular basis (after 7 days), so it’s important to download and save it to somewhere for later analysis.
(more…)

After upgrading to iPhone SDK 2.2, we encountered this error when building one of our projects (others built fine).
(more…)

Recently, we have run into the problem of trying to determine the optimal path to take when planning for a multiple destinations trip. It is the kind of problem that we face quite frequently in our everyday life, such as planning a holiday trip to various cities overseas; setting up business meetings with various people in different parts of the city; or delivering goods to different locations in a given area. The goal is to find the order of destinations to visit, which requires the least amount of effort (cost/distance/time) needed to spend on such trip. This is a classic example of a TSP, the Traveling Salesman Problem.

(more…)