It’s especially nice news coming back from WWDC where my good friends at Rogue Sheep won the Apple Design Award for .

While the MyBus.org site has been responding fine for the past few weeks, we’ve now seen multiple times over the past year when their site has been down and/or unresponsive to the point of breaking the Seattle Bus application. Hopefully this will fully resolve it. A future point update may allow users to choose between real-time trackers, but that hasn’t been coded in yet and I hope won’t be necessary.

I’ll post an update when it’s past review and is available for purchase again on the iTunes AppStore.

I apologize for the trouble and annoyances.

If you have the application already, it’s worth noting that the application does work periodically. Unfortunately, the data feed is just so inconsistent as to be nearly useless.

UPDATE:

I have a new parser functioning correctly with by MyBus.org and King County’s Metro Tracker site. The update should be uploaded to the AppStore shortly. I’ll post when I get the new version uploaded, and when it’s available.

I must say, it’s incredibly embarrassing that the King County site doesn’t even emit well formed HTML. The new parser is an interesting screen-scrape accumulation of regular expressions to pull out the relevant data. At least they’re posting it online…

The site that the application uses for it’s data source (mybus.org) has been intermittently available recently, and today it’s been down completely. This is a site run at the University of Washington, and I’m afraid I don’t have a direct contact with the administrators.

There is another site with similar data provided by King County Metro (not as well structured) – so I may end up re-writing my scraper/parser to pull data from that site as I have no details on when or if MyBus.org will come back online.

I wish there was a better way of providing this data to you – I’ll keep everyone informed through this developer diary as I have updates.

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.

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.

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).

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:

• Make sure the project default settings are “debug” and “simulator”
• Close Xcode
• open a terminal window and “cd” to the project directory
• run rm -rf /tmp/scan-build*
• run rm -rf build/;scan-build --view xcodebuild
• Open Xcode and fix errors

That’s been working great for me ever since.

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.

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!

Steve Demeter just announced his Trism revenue at Mobilize during VC panel Q&A: $250,000 since July 11th.

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.

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.

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 individual bus stop pages will have a refresh button to get updated information about that stop. (previously, you had to navigate back to a list view and then to the stop again)
• The color coding of the wait times has been simplified and nailed down. Green means there’s an expectation that the bus is on schedule, and red means it’s delayed.
• Added the display of “express” buses with an “X” next to the route
• I’ve added nearly 100 stops that had been missing from an earlier version of the application, and the associated code to handle seamless database updates (for this and any future updates).

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:

• SOUTH LAKE UNION STREETCAR BARN
• 2 AV NE & NE ALDER ST
• ATLANTIC BASE NW YARD
• SEACREST MARINA PARKING LOT
• FEDERAL WAY TRANSIT CENTER (ALL BAYS)
• KENT CITY HALL
• 104 AV SE at 26300 BLK
• KENT RAIL STATION (ALL BAYS)
• ISSAQUAH HIGHLANDS P&R (ALL BAYS)
• BURIEN TRANSIT CENTER (ALL BAYS)
• OVERLAKE TRANSIT CENTER (ALL BAYS)
• AUBURN RAIL STATION (ALL BAYS)
• SOUTH RENTON P & R (ALL DIRECTIONS)
• TUKWILA P&R (ALL DIRECTIONS)
• MEEKER/PARK COURT
• FAIRVIEW AV N & WARD ST
• KING CO AQUATIC CENTER
• PROVIDENCE POINT
• 15TH AV NW & NW LEARY WY
• 116 AV NE& NE 12 ST
• AUBURN GSA SOCIAL SECURITY
• RENTON TRANSIT CENTER (ALL BAYS)
• SEA-TAC AIRPORT (ALL BAYS)
• REDMOND TC BAY 6
• REDMOND TC LAY A
• 1 AV N & W TEMPERANCE ST
• SODO BUSWAY & S HOLGATE ST
• 4 AV SW & SW 146 ST
• KENT STATION 1 AV N
• EASTGATE P&R (ALL BAYS)
• KIRKLAND TRANSIT CENTER (ALL BAYS)
• AUBURN P&R (ALL BAYS)
• AURORA VILLAGE TRANSIT CENTER (ALL BAYS)
• NORTHGATE TRANSIT CENTER (ALL BAYS)
• SEACREST DOCK
• NEWPORT HS ROADWAY
• REDMOND TOWNE CENTER
• I-405 & NE 128 ST
• ISS TC BAY 1
• ISS TC BAY 2
• ISS TC BAY 3
• ISS TC BAY 4
• ISS TC BAY 5
• ISS TC BAY 6
• ISS TC LAYOVER

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.

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.

I’ve managed to finally upload an “accepted” copy of the SeattleBus 1.0.2 binary! That puts it into Apple’s application review queue, which means it will hopefully be available to everyone by the end of the week or early next week. Apple doesn’t provide any guarantees on review times, but I’m hopeful.

The problem did indeed turn out to be on my end. The code signing process can fail in silent and annoying ways that are damn near impossible to figure out on your own. Fortunately, I received some great help from Apple early this week and they helped me narrow down the problem.

I’ve filed a bug against Xcode for it not warning about the problem (radar 6095242). When the NDA is lifted, I’ll post more details about the specific issue, so that hopefully others will be able to find out how to resolve it

I finally opened a ticket with Developer Technical Support today – I’ve got two from my “Select” membership, so I might as well use one. I usually don’t use them – it’s as good a place as any, and I could really use the help right now. DTS reports that it is usually a couple of days for a response, so assuming everything goes swimmingly from this point forward – it’ll still likely be the middle of next week before I get something signed that the AppStore will accept. Anecdotally, I’ve heard DTS is even more backed up than usual – so we’ll just have to see.

The worst part about all this is I’m not sure how to even diagnose what’s going wrong. The AppStore wants a signed bundle – everything I can see in the logs shows that it’s getting signed. (A digital signature – not my handwriting. Everything in this set up uses digital signatures for verifying all sorts of bits about the code). I’ve become significantly more comfortable with Apple’s code signing program, learning the command line bits just to understand what’s happening. It all looks good – but when I upload it, I get the error

The binary you uploaded was invalid. The signature was invalid, or it was not signed with an Apple submission certificate.

It’s a fine error message, except as far as I can tell all the diagnostics need to happen on the receiving end of this process – where I can’t see anything.

I wasn’t sure if something got suckered up in the databases or such, so I even went to the trouble of removing all the current keys, certificates, provisioning profiles, and what-not – recreating them all from scratch and setting up my entire environment again. That was a pain and in the end it didn’t do the trick. At this point I’m stepping away for a little bit. I think it might be best if I wait for someone from DTS to get involved to help me with this, because I’m sure not making progress on my own.

In the meantime, if you have questions or feedback about SeattleBus – please, by all means, send me email and let me know! I’m responding to all the email I get, and I’ve even tried to respond to the reviews on the AppStore (a little tricky, since I have to guess at email addresses).

In the mean time, I’ve had folks pop by and ask “How’s it doing?”. Here’s the sad thing – I have no idea! Apple isn’t providing any metrics, so the best I have is anecdotal evidence that folks are purchasing and using my application. The most that I think Apple has committed to is providing monthly financial reports, so I think it’ll be a little bit before I have any sense of how well or poorly SeattleBus is doing.

And yeah – I’ve been working on updates. My like Brent posting his updates for NetNewsWire – I’ve got a few myself:

1.0.1

• fixed a number of memory leaks
• added in-memory caching to improve performance

1.0.2

• added in different constants for searching for nearby bus stops – working to make the “nearby” list more adaptive to areas without dense stops (the work I recently wrote about)
• ordered the resulting nearby bus stops by distance from the current location
• set Favorites to be initial view – re-organized views to enable that (favorites now left-most tab)
• Loaded the in-memory caches in the background for better startup performance
• changed initial image to show “Loading…” to make it more clear when the application is active

Now just as soon as I can figure out their interface for updating my Application, it’ll be in there and hopefully available to everyone shortly!

The goal of SeattleBus is first and foremost to provide real-time arrival information for stops. Finding the stops is, to some extent, secondary – but also the critical “first step” to being able to look up that realtime arrival information. Getting the geolocation for the stops was quick a challenge. I started reverse engineering the stops myself using Google’s geolocator API – it was clear enough I was going to have a long ways to go with that to make it really smooth. Metro Transit wasn’t providing the information (I’ve since started talking with them – maybe we’ll get some better data soon) – but in the mean time Adam Parast was great enough to share the same data he used to make a Google Map’s layout of all the bus stops – a mashup of Maps and MyBus.org.

So choosing the nearest stop turns out to be an interesting challenge. The geolocation API isn’t 100% accurate, so choosing a stop is really determining a list of tracked locations that are close. I thought about making a preference that someone could set, but one of the feedback components I received early on was to find and set a good default right off the bat.

I set a good default for the downtown locations, but with the release of 1.0 I’m afraid that it’s just too tight a lookup area for some of the outlying areas of those stops. If you check out Adam’s mashup, you’ll see there’s a huge density downtown and then it gets a LOT more spread out from there. So for version 1.1, I’m changing that lookup sequence a bit. When you’re in the downtown corridor (dense with tracked stops), the range for looking up stops will be pretty tight – maybe a couple of blocks. And when you’re outside of that area, I’ll loosen it up quite a bit.

Part of making this process better is getting better geolocation data for those stops too – I’m working on that now… The release of SeattleBus managed to get Metro’s attention, so we’ve got a conversation started there where I wasn’t able to get anyone’s attention earlier. Here’s to some more and interesting collaborations! (we’ll see what comes of it)