Finicky, now for iPhone

I released a version of Finicky for iPhone earlier this week. It’s up and running in the app store.

Design Differences
You’ll notice that it looks somewhat difference from the Android version. This is by choice. In trying to get the iOS version working, I noticed significant issues with the UI we had designed and the iOS version. However I was still able to capture the feeling I wanted through color and font, without having to compromise too much on the design.

Feature Differences
I was able to support pretty much all of the features on both devices with the exception of mapping. I had issues getting the maps to work in production build. Worked fine in both the desktop debugging version of AIR and the fast compile version of the iOS app. It only failed on the full compile version of the iOS version. I anticipate having them working in an upcoming version.

Coding Differences
My original path was to have 2 separate code bases. I know, I know, this is all about not having to do it twice, but I was weak. The major reason behind this was that the iOS version had to run leaner, because, well, you know, performance is king. There was a good amount of Android specific UI and features that I just set to visible = false. That did terrible things for speed. So I stripped out all Android specific code, removed anything from the UI that I wasn’t showing on iOS, and generally improved performance.
However, after awhile I found two code bases presented a lot of problems. See, I’m not the best coder. I know, shocking. But I had bugs in my code. And I found a lot as I was going through and tweaking for iOS. But I had to manually copy them back to the Android project, as my git-fu is not so great.
I went back to one code base, but instead of ripping out Android specific UI and features, I loaded them conditionally. This gave me comparable performance, but allowed me to run both apps from the same code base.

2 Targets 1 Code base
If I had to do it again, what would I do different? First, off, due to some advice, I made a couple of good calls early. Kevin Hoyt pointed out, and Renaun Erikson echoed: design for iPhone 4 first, in terms of design assets. Everything else is a step down in terms of resolution. However, I developed for Android first. I’m not sure if this is the right move. I think it’s easier to add things, then it is too take them away. My process had me taking a whole bunch of things away. If I had it to do over I might develop for IOS first, then selectively add features for Android, BUT release for Android first. Maybe… I dunno. The thing I love about releasing on Android first is that I get stupid bugs out of the way on a platform that allows me to iterate through releases as fast as I can fix bugs. This isn’t necessarily a shot at iOS or Amazon or Nook or BlackBerry. I think their approval system does make you think harder about whether or not you have bugs before you submit. But, that being said my problem is not that I do not think, but rather that I often don’t think the right way. Being able to quickly react to real issues, is better then having me ruminate on what I think might be happening.

So there you have it. One app two platforms. Will be getting it onto Amazon and Nook next.