I've been working on iTimeZone 1.4 iPhone and iPod touch for a long time. iTimeZone 1.3.5 shipped in May 2010, which ended a serious of releases containing incremental bug fix and feature adjustments. I had originally intended to finish an iPad version of iTimeZone for release in early summer, but it got totally derailed. Here's what's coming in iTimeZone 1.4 and what took so long.
iPhone 4 Retina Display Graphics
As iOS developers quickly discovered, the increase over original iPhone - 3GS in required pixels for images means a redo of all assets. I certainly didn't have enough foresight to create all my image assets @2X the needed size, some probably did. iTimeZone 1.4 won't be the last app to get Retina Display images, but in hindsight, should have got the images done and shipped 1.3.6 until holding them until now.
iOS 4 Multitasking
No big deal, it's just a simple recompile right? Yes and no. Yes, you get multitasking enabled in your app for "free" once you recompiled with a 4.x SDK. But you still had to handle those state changes gracefully, for example dumping unnecessary memory caches to be a good citizen. Also, apps that use the Settings app have to handle settings changes once an app is brought out of sleep and made active. Sounds easy, but it took more time to get right than I would have thought because changing the way your app starts exposes all kinds of bugs you never dreamed of.
Better Location Detection
iTimeZone 1.3 added location detection so users could look up cities based on where they were. In my testing before that release, it worked really well. A developers famous last words. Through user feedback post-release and subsequent testing, I realized that the algorithm I used was just not working well enough in large cities. This was a case of App Store reviews being fair, for some it wasn't working and I was getting "1 starred" for it, and rightly so.
I don't know how tough of a problem correlating location data to a database of cities is for other apps or developers, but this has been by far the hardest feature to get to "It Just Works". This feature alone has taken months of development, and caused numerous cascading refactors. The biggest refactor was for the database controller code. I had wanted to clean up this technical debt for other upcoming features, but it burned a lot of time.
There is more testing to be done but in iTimeZone 1.4, location detection is much much better. If more testing confirms, it might even be "It Just Works" good using a combination refinements to the algorithm I used in 1.3 and a reverse geocoding service. This was my first web service call in iOS, so a lot of learning on how to do that right as well. This happens in parallel so as soon as the app gets location info from the device, the user should see results very fast, and should never be left with "Couldn't determine location" unless the device doesn't give it to the app.
This is also the main culprit for iTimeZone for iPad not shipping, I didn't want to ship another big release without fixing this feature.
70,000 More Cities, Fastest Searches Ever
Users always ask for more cities, even the tinniest cities, so I want to give them that. iTimeZone 1.4 is using the biggest city database my existing data provider freely offers. When you increase the size of your data by 4.5X, query performance usually goes down. I saw a decrease in search times putting the new database in 1.3, not even making some of the other changes I wanted to for grouping results.
Grouping the results really slowed things down, and I hate waiting for a device to give me data. Since I was partially refactoring the database controller for the location querying requirements, I just decided to go the whole way to get the maximum parallelism I could using modern OS structures, NSOperationQueue and NSOperation, instead of a query thread with critical section locks in numerous methods. On iPhone 4 and iPhone 3GS with iOS 4.x, a queries first result returns in 1-2 seconds, with lower importance results streaming in a little later.
User Experience Improvements
All of the above are certainly UX improvements, but this part is purely about app flow. In iTimeZone 1.3, when you first opened the app, you immediately got herded into the "Find Current City" screen. If location detection didn't work for you, you had a really bad experience. Now, the app loads into the main screen with some simple directions for the user on what to do. There are a couple other places this happens as well, I think by going just a little slower, the app feels better because users understand the spatial model of the app as soon as the open it. The previous approach could be categorized as "why are you prepared, just go".
The other feature I am constantly asked about is how to change the current city. For a long list of releases, if the user double-tapped any city in their list, it would swap places with the current city. There were also specific buttons in a couple that could be tapped on, but not on the main screen. Problem with a gesture like that, users have to know it's there. So I added a tip on the bottom of the user's city list table telling them how to change the current city. I will definitely be tweaking this again in upcoming releases, maybe implement something on swipe as well, but I hope this makes it more obvious.
Pruning The Source
For the source code to remain healthy, some things had to be removed. Upgrading from the 2.5 year old iTimeZone 1.0 user city storage format was dropped. This slowed every app load down, and highly likely no one left in the world is on iTimeZone 1.0.
iTimeZone 1.4 will only support iOS 3.2 and higher, so long 3.1.3. I posted about SQLite versions in iOS the other day because the SQLite build on iOS 3.1.3 is just not working with one of my queries. Every other device I have & simulator with iOS 4.x works great. Don't think I'm going to revisit this, Apple has moved on, so am I.
What Didn't Make It?
iOS 4 for some reason dropped a lot of time zone abbreviation data iTimeZone was using. I'm going to add my own data set for this, including military time zone names, in iTimeZone for iPad 1.0 and iTimeZone for iPhone 1.4.1
What's Next?
A beta release to private testers in the next couple days, more testing, and then start putting the iPad version back together. I have multiple Subversion merges to look forward to.
