Nov 12 2008
I saw this from Daring Fireball: How people really use the iPhone.
It is a fantastic, professional user-experience overview of a variety of applications - but most importantly some real information on how folks are using the interface. If you’re developing iPhone applications, this is a must see!
I was very glad to see that I hit most of my own UI elements right with Seattle Bus.
Nov 01 2008
I found out this morning that I have competition for Seattle Bus!
Barry Kaplan made a damn-near copy of my application and is selling it on the App Store for $0.99. From the initial reviews, he apparently started selling it for free. He also appears to have completely ripped off the icon from Zhenwang Yao - author of iBus-Portland (a similar concept application, except aimed at Portland’s transit system).
Good way to get some notice, no doubt about it. I’m giving huge points for being original. Of course, I give those same huge points to Microsoft quite a bit, and they’ve done OK.
Unfortunately in the iTunes search, his is showing up where mine isn’t on the search results page. Not surprisingly, my sales have dried to nearly nothing.
I’ve dropped the price on Seattle Bus to $4.99 now - I’d originally intended to do this as a one week sale to see how elastic or inelastic the price was on the market. I’m afraid that’ll be almost impossible to tell at this point.
If Barry (author of Seattle Metro) was hoping to rake in the big bucks with this fancy app, I’m afraid he’s going to be disappointed. I am glad to see more applications along these lines out there - if nothing else it will at least encourage King County Metro to realize that they’ve got a completely unfulfilled need out here. Not that I expect them to be able to make a decent application, at least based on existing efforts.
From a pricing perspective, I wonder if the application market can sustain the niche efforts at the incredibly low price points of $0.99 and the like. I staked my price higher because I believe in the value first and foremost - not comparing it to other applications (shoot, it’s free on the web) but to the value that you’re getting from the application compared to other things you’re paying. A ride at peak on Seattle Metro (outside the free-ride fare zone) is $1.75. That put Seattle Bus at roughly 6 rides. Seemed like a very fair recompense, especially considering that I didn’t have any base data to work from and put together all the points myself.
The money I have made on the application to date would not have been enough to pay a decent contractor for the exact same work. I seriously doubt that Barry will be able to make up the time he spent on the application with any reasonable wage.
In the larger market, I can see where a $0.99 application might just win for everyone. Low cost, impulse purchase, and a potentially huge market. You’ve fundamentally got to have the scale to make that work. For the niche applications like mine, it’s a much more limited demographic market - the scale just isn’t there.
Oct 11 2008
This isn’t new news - just bits that I couldn’t post because of Apple’s NDA on the technologies behind the iPhone. I wrote the results a little while ago - but I wanted to put something up here for Google to find and help out other folks in case they run into the same issue.
When a distribution binary is created, it gets signed with provisioning profile that has some specific certificates embedded within it. The whole kit gets cryptographically signed, and that signature gets embedded within the application bundle. Buried inside your application, there *should* be a file named embedded.mobileprovision. The file is a serialize plist with a bunch of certificate and signature information embedded within it. If your build settings are incorrect or otherwise screwed up (which was happening in my case), the signature process simply doesn’t create this file. The AppStore won’t even accept a binary without this file inside it and with the appropriate signatures.
The specific problem was that I’d put in a target specific build setting some time in the past, and when I changed the project build settings according to the directions for distributing a binary, it was getting overwritten with the target specific settings that were incorrect. Instead of giving a warning or erring out when the provisioning file I was pointing to didn’t exist, it just continued on it’s merry way - the log looking for all the world like it was working just fine.
I’ve filed a bug against Xcode for it not warning about the incorrectly specified provisioning profile (radar 6095242).
Oct 11 2008
Like a number of other Mac developers, I caught the word and then the bug for using Clang Static Analyzer. I remember when I first caught wind of it, hearing about it on twitter and spotting a number of del.icio.us links to it. The note that really caught my attention was someone mentioning it and saying “too bad you can’t use it with the iPhone development…”.
That completely surprised me, because the first project I tried it on was SeattleBus. It was great for identifying a few memory leaks and missing -dealloc methods, I was hooked right off the bat. It wasn’t until later that I started trying to figure out that statement and realized that the analyzer doesn’t support analyzing ARM binaries. It does a great job on intel binaries though, so I realized that when I set my project to default to building for the simulator, I could use the analysis program.
My workflow after I’ve really worked on the codebase is now:
rm -rf /tmp/scan-build*rm -rf build/;scan-build --view xcodebuildThat’s been working great for me ever since.
Sep 25 2008
Seattle Bus version 1.1 took 12 days to clear through the App Store review process. All that and I had a really, incredibly stupid bug in it that basically screws up your favorites when you upgrade.
Pretty much a one-liner typo “looks right” until you realize it isn’t bug. I’ve got it fixed in version 1.1.1 - in fact, that’s pretty much the only thing in version 1.1.1. I fixed the bug and uploaded it to the App Store to put it into review.
If you haven’t upgraded from 1.0.2 or earlier to version 1.1, then consider waiting for this update to clear. If the timing is the same, it’ll be available roughly October 8th. I’m afraid I don’t have any control over how fast it moves through the App Store approval process, so hopefully sooner and not later.
It’s one of the sides of the App Store/sales channel setup that I really wish I could change. If I was delivering this application myself, then that update would be out right now and damage limited to the few folks who upgraded in the past 8 or so hours that the broken update was available. At this point, I’ll have to guess a large number of folks will get the 1.1 update/upgrade before I can get out a properly fixed version. I’ve got a good sense of how many customers I have - so I’ll keep track. I hope it’s a low number, but I fear it won’t be.
Sep 25 2008
Damnit!
I missed something in my testing, because when I upgraded my copy of Seattle Bus to version 1.1 (now available in the AppStore), my favorites were all switched around to stops I didn’t recognize. Damnit.
It’s easy enough to reset, but I’m very annoyed that I missed that bug. I expect a lot of you will be too.
I updated the description in the AppStore so that folks upgrading will at least have a chance of knowing about the breakage before it hits them. Since I don’t have any other means (aside from this blog) of contacting my customers directly, that’s all I could think of doing. Well, and writing this entry.
I think it’s still very worth updating for the other features. This update also happens to have an updated bus stop database associated with it, and it’s the code that “upgrades” your database with the new information that’s obviously flawed. I even explicitly tested that functionality, but clearly I missed something too.
My apologies to all of you for breaking your favorites!
Sep 18 2008
Raven Zachery posted the following on twitter late this afternoon:
I about fell of my chair when I read that. I know a lot of folks have nice sales with the iPhone applications, but that just completely blows through any sort of expectations I ever had. As far as I can tell, Trism is pretty much one person’s extremely intensive work on a very innovative game. Boy howdy, that shit sure paid off!
Part of me is instantly jealous and kicking myself for writing something as lame as a “bus application”, when I “could have” been writing something like Trism and then spending the next year traveling around Europe with Karen or something. (Ok, the reality is that I’d likely be far more conservative with the income than that…) Then I sit back, applaud this dude’s really effective work, and realize that I probably wouldn’t have done it at all. In fact, I clearly didn’t.
For me - well, I need a driver. Something to really motivate me for making the application. Seattle Bus was something that I wanted to have myself. That made all the difference to me in developing it. In truth, I never expected to see as many sales as I’ve received to date (sorry, not posting numbers on the blog…)
Even at dinner tonight with Vas I was surprised when Vas said, “You know, if you really put some more work into it…” and went on to describe the things he really wanted in Seattle Bus. I’ve gotten far more suggestions and ideas for things that people would like in the application that I ever originally conceived. Frankly, I think updates to Seattle Bus could keep me solidly busy for the rest of the year (if not more)!
Since I’ve just uploaded an update to Seattle Bus (pending approval now), I’m very curious as to how an update release will effect sales. In a desktop application, there’s usually a spike of increased sales that falls off (after some amount of time) back to a previous or potentially slightly elevated sales level. Seattle Bus is cruising along at a reasonably consistent sales level, so I’m curious if the same thing happens when your distribution outlet/platform is the iPhone App Store. Obviously, I rather hope so.
That quote is still rattling around in my head, even hours later. It makes me think I also need to take some more time and spend a little bit of it diversifying and getting another application out there. My moleskine isn’t short of ideas - I’ve been chucking them in there with carefree abandon (had to buy more ink today, in fact).
What comes next is some consolidation of the ideas, and taking a good hard look at the ideas to see what gets me the most motivated. The iPhone applications are a side deal for me, so I’ve got to get my motivation from just making the app - not just betting on a handy bit of cash that it might generate.
Sep 15 2008
I think “I’m ready to go!”, I’ve got it loaded and have been playing with it for the past week or so. Then the other night I happen to look at the application at 11:55pm. Ah yes, that was a mistake.
As it turns out, the date parsing for what I’m trying to do is a tricky little bugger, and looking at the timestamps that resulted at 11:55pm for 3rd & Union downtown showed me a few glaring flaws.
I’ve fixed most of them - the remaining pain point I’m hoping to verify later tonight. It seems that if a bus is scheduled to arrive at 11:55pm, and the current time is 12:01am - the system thinks you’re waiting for the bus that following night at that time, and you get a wait time of something like 1440 minutes.
It also appears that the web system from transit has a slight flaw with their own time display. They display 12 midnight at 12:00pm. I don’t know about you guys, but I always thought that was noon, not midnight. Ah well - another special case in an already messy bit of code, because parsing time from simple strings is frankly just rather fraught with difficult situations.
So with any luck I have this nailed down and ready to go… I’m going to check tonight, and then I’ll be getting it uploaded to the site. Even if I haven’t quite got the bugs all nailed down, I suspect I’ll get it uploaded to the site. I think this bug has been around since day one, so waiting a little more for the fix is better than holding up the other good stuff I want to get into your hands.
Update: As of 7pm PST, September 16th - version 1.1 has been uploaded to Apple and is pending review. There remains a known issue with date parsing and determining “wait times” when you’re looking them up just after midnight. I’m continuing to work on that, and will release an update - but I didn’t want to hold up the other features for that bug.
Sep 05 2008
I know it’s been quite on the topic of SeattleBus lately… so here’s an update.
I’ve been working through some updated interface designs and getting an update ready to go. I ended up developing and then throwing out a number of attempts and ideas after getting them down on the device. The biggest issue wasn’t the specific look - they didn’t look particularly bad - but that the end result wasn’t as concise. (Of note: getting section titles formatted in any reasonable way for a grouped UITableView is a real pain.)
Experiments for this round complete, I’ve landed the programming pieces of an update that I’m happy with, and which will represent the 1.1 release when I’m ready to push it out the door. The key features:
The only thing holding up the release is getting some of the details ironed out from that last update feature. Basically, I’m missing some location data for some stops, and I need to figure out the physical locations to finish this up. The places that are still pending:
Some of these are obviously easy… a little time with Google Earth and I’ll have them nailed. Others, well - I’m not quite sure what or where “ISS Transit Center” is, let alone Seacrest dock or Auburn GSA Social Security. Guess I’ll be learning. If you have a suggestion on what or where some of these are (specific geolocation data would be most helpful), I’d love to hear from you. In the meantime, I’ll be hunting down the last of this data to get an update out the door.
Aug 08 2008
I imagine that sounds like a very strange statement, but it’s one that has been occurring to me more frequently lately. Apple was fairly slow off the gate to provide any sales/trend information about how my application was doing, and it was frustrating as hell. I would get the periodic “support” email from someone who had clearly purchased the application, but I had no idea who I was selling to let alone how much…
I’m very glad that Apple has put together a sales trends setup for iPhone developers deploying their applications. Not surprisingly, I wish it was a little better - in particular, I’d love to have an API where I could get that data programmatically. I’m more than happy to store it and do whatever additional analytics I like - but right now getting it out of the system is a very manual process. I think I’m going to set aside some time to knock out a script with twill or mechanize that will do this work for me and automate it.
I suppose in a sense, it does not matter “who” for any individual customer. But frankly, that bugs the crap out of me! I’m a big believer in the potential power and influence of the individual, so knowing my “customer” is a philosophical imperative. When I look across the road at my Mac developer compatriots who know with fair detail who their customers are. It’s an aspect of working through the iTunes AppStore that I never considered, and now find frustrating.
I would love to be able to contact my customers. I’d like to send an email to everyone who’s purchased my application, let them know about updates that are available and proactively ask for feedback. Craig Hockenberry talked to this a bit in his blog post Listeners found this review helpful. The closest the AppStore provides are the reviews - very much a one-way street. In a very sense, I feel I’m barred from communicating with them outside of the application that I produce. I could put something in the application description on the store itself “Would like feedback, please email me” but that seems rather lame and very impersonal. Likewise I don’t want to bind in a “feedback” link in the application itself - getting me feedback is not something I think the application should be focused on. I’m very certain that I want the application to be laser-focused on it’s particular task. I don’t want to trip that up with extraneous bells and whistles, and a “feedback” link seems like exactly that.
I’m incredibly grateful for folks who have written into my “support” email address to date. I’ve received some great feedback and been able to help a number of folks. I wish and hope that Apple will come up with something to solve this frustration of mine, but frankly I kind of doubt it. I think some (someone) within Apple perceives it’s in Apple’s best interests to “own the relationship” with the customer. They do at least pass along a link to our websites and an email address, but I don’t expect that to change. I fully expect we (iPhone developers) will continue to be at “arms length” from our customers.