Cogitu

UPDATE: Budgee 1.5 is now live in App Store.  Direct link: Budgee

Just a quick update for anyone waiting on the 2 main features coming in Budgee 1.5 (multiple budgets & integrated web server)... The update was submitted to Apple a while ago, but Apple found an issue in the middle of the week last week. The issue was addressed and re-submitted last Wednesday, so the update should now be going live by Wednesday or so of this week unless things are delayed due to changes related to the Apple announcements on March 17th.

Budgee 1.5 will be available in the App Store early this next week unless there are unexpected delays during the Apple review process. There are two major features which are entirely new in this release:

Multiple Budget Support

One of the limitations on pre-1.5 Budgee is that you are always working with a single budget. If you wanted to keep budgets around from previous periods, you couldn't. If you wanted to track other projects, a kitchen remodel for example, you couldn't do that either - not unless that was the only budget you tracked. Starting with this release, Budgee will now support multiple budgets. If you want to delete a budget after you've exported it, you can still do that, but Budgee won't force you to do that if you don't want to.

Multiple Budgets

Budgee Web - an alternative to CSV export

Until now, the only way to extract budget info was via the CSV export to email.  Over the last two months or so, I've been getting more reports of CSV export to email failing for users.  I've released several fixes that attempted to work around the issues.  In the end, there is a bug within the core iPhone/iPod Touch itself that is causing these issues and there isn't anything I can do about it until Apple fixes it (there is an open bug report on the item).  So CSV export to email will remain in Budgee, but you'll get a popup notification if your particular data runs into the Apple bug.  With Budgee Web, all of those issues go away.  In a nutshell, Budgee Web is an internal web server built right into Budgee.  It only runs while you have the Budgee Web screen open and it is only accessible while on a Wi-Fi connection.  It allows you to browse to your iPhone/iPod Touch and download CSV data right from your PC/Mac using Safari, IE, Firefox, Chrome, or whatever you'd like.  Right now, Budgee Web only supports downloading transaction information in true CSV format, but the CSV data that was previously exportable via e-mail is also an option (just not as a .csv file).  This is simply the start for Budgee Web - it's one of the features I would really have liked to hold off on until 2.0, but I'd rather put it in place early so that anyone having CSV export problems can easily work around the email bug.

Budgee Web

Version 2.0 of Budgee will have several upgraded features as well as at least one new major feature. The "under the hood" components of Budgee are also being re-written to support future features and to greatly improve application performance & stability. The 2.0 release is currently targeted for on or before May 1st. Between now and the 2.0 release, there will be a series of minor updates to further improve existing Budgee functionality.

I know we're already well into 2009 at this point, but since I've been promising to post Budgee sales data for a while now, I'm going to go ahead and get this out there. This is the raw weekly sales data for Budgee for all of 2008.

For reference, Budgee was introduced in mid-October 2008 at price tier 2 (that's $1.99 US). It stayed at $1.99 except the last two weeks of December 2008 when the price was lowered to $0.99 for a holiday sale. During these few months, there were not a ton of updates - a few right at the beginning and then a couple scattered around after that. The dip the week of December 21st was caused by Budgee being removed from the app store for a couple of days prior to the holiday sale. (In short, I wanted the price to start at Christmas, but Apple was cutting off iTunes Connect access a few days ahead of that...so I had to change the release date to Christmas and then change the price...the result of that was that the app was removed until Christmas and I couldn't change it back.)

You can see that Budgee doesn't bring in enough revenue for one to live on - it averages ~$250/mo - but it is certainly a nice side job. Keep in mind, these sales were all made without any form of advertising. My goal for 2008 was just to break even with the cost of the iPhone SDK - so I've more than met that goal. Budgee is also one of the programs *I* really wanted on my iPhone for the longest time - so my intent was to make the app that I wanted and then if people enjoyed it and I made money with it, then all the better. For 2009, I'm trying some different tactics with Budgee - online marketing, more frequent updates, a major upgrade - so we'll see how all of that ends up changing things.

I have also included data on updates so you can see how the number of total users compares to the number of users running the latest updates. If you have any questions about this data, feel free to leave a comment and I'll do my best to answer. I'd like to be pretty open about Budgee since I've learned a lot from the iPhone dev community sharing information like this, so I'd like to try to give back when I can.

UPDATE: This bug is fixed with the iPhone OS 3.0 release.  It doesn't sounds like Apple plans to ever update the 2.x OS with a patch for this, so check out the suggestions in the comments if you plan to continue 2.x support...some very good stuff there.

To the Budgee Users

First off, to anyone still having CSV export issues with Budgee - I apologize.  The bottom line is that there is a bug in the OS itself that is preventing it from working (more detail below if you're interested).  After getting a couple of new bug reports since the last update, I've been able to create an example of the problem and have sent it to Apple - but the reality is that the next OS update will be the earliest it will be fixed.  I'm looking into alternatives to the current export method at this time, but do not have a solution at this point.

To Developers Thinking of Using mailto: or Currently Seeing Bugs with mailto:

Since the first version of Budgee, I've been using a simple CSV export method that passes the encoded data to the iPhone/iPod Touch's Mail application.  It's worked great - no issues at all - until about two months ago.  I don't remember which OS update started causing problems...it seems like it was one of the 2.1 releases.  The export code is really simple - it goes like this:

1. Build NSMutableString with data to export
2. Url encode said string so it is safe to use in an url (i.e. convert a space to %20 etc)
3. Tack on a mailto: with a subject & body parameter passing in the url encoded data
4. Call the shared UIApplication's openUrl method

Pretty basic stuff.  Well, as the OS has evolved, the openUrl method has gradually been getting more and more screwed up.  There is no feedback as to what went wrong when you call it - it simply returns "NO" randomly now...which means it did not pass the url to the Mail application...which means my customers can't get the CSV data out of the iPhone app.

My first thought was that I didn't encode things properly.  Sure enough, there were "reserved" characters getting through the encoding process.  I should have done more extensive testing, but from reading the docs (and the method name), one would think using NSString's stringByAddingPercentEscapesUsingEncoding would kinda do what it says.  But that wasn't the case...it escapes some things, but not all things.

So the next approach was something I found on the Apple devforums.  The suggestion there was to use CFURLCreateStringByAddingPercentEscapes to do the escaping.  It certainly looked a little nastier than the NSString method, but whatever works right?  Well, the most recent Budgee update used this new method of encoding.  On my development device, this new fix did indeed make things better and export started working again.  After releasing the update on the App Store, I had several reports of users seeing CSV work again as well - so all was good right?  Wrong.

This weekend, I had more reports of CSV breaking.  After testing for about 4 hours with all kinds of different data, I saw that openUrl seems to fail arbitrarily.  Budgee is a budgeting application where you enter categories and transactions and it tells you how much money you have remaining in your budget.  Well, when I added a new category, just one, the export would sometimes work.  When I took away that category, the export would sometimes fail.  The thing is, the data is more or less the same each time...the is a new record for the new category and the message has a new timestamp, but other than that, nothing changed.  But openUrl refused to actually open Mail about 1/2 the time I tried the export.  After more testing, it seems that even the timestamp can change the url enough to cause openUrl to fail - so it's not just the category data that is causing the problem.

At this point, I have verifed the URL I'm passing to openUrl is correct and encoded properly.  In fact, I went overboard and encoded everything other than basic ASCII letters - that should be overkill, but I saw reports of openUrl failing when periods were in the url (which should be legal)...so I opted to encode the heck out of the thing.  I passed the url to openUrl and guess what?  No dice - still refuses to open.  It does this 100% of the time as long as I hardcode this url into my test application.  So, the good news is that I've opened a bug with Apple (bug #6635825 if that is useful to you) and attached sample code that should reproduce this error consistently.  Before I opened this bug, there were posts by an Apple employee (also on the devforum) stating that they know there are issues with mailto: links, but they essentially haven't been able to track down what is happening to cause the issue.  Maybe the sample code I posted to them will help.  The bad news is that my customers still can't export data sometimes and I have no workaround other than to try adding a new category, transaction, etc. and then trying the export again.  That is totally unacceptable for me - but the only other workaround I can do is to totally re-write the export to use a method other than a mailto: link...but of course, that's not a trivial thing to do quickly.

The bottom line for developers is that if you're thinking about using a mailto: link to export data, be ready to hit this issue and have to wait on Apple.  It still isn't clear what triggers it.  It may be the complexity of the data I'm exporting, but it's just not clear.  There are quite a few reports around the different forums where people are having similar issues - so I know Budgee isn't the only app exhibiting this problem.  It looks like the only reliable way to get this data off the phone is to send it yourself via web service calls, export to google docs, built-in web server, etc...all of which are considerably more involved (for the dev and/or end user) than the mailto: link.

Things have been pretty quiet on this blog for a while, so I thought I'd share what has been going on over the last two months.

Budgee Updates

If you've been following this blog, you've seen a couple of updates for the current version of Budgee were released over the last two months.  The problem has been that Apple's iPhone/iPod Touch OS updates are causing some internal functions to work differently after the update.  Specifically, the code that encodes text so that it can be used in a URL seems to be very finicky.  Recently, this caused Budgee's CSV export to not work since the URL wasn't being generated properly.  The issue should be fixed for everyone now with the most recent updates, but it sure would be awesome if Apple would release the new OS update to developers a couple of days earlier than the general public AND provide accurate release notes as to what changed...but until then, I'll do my best to get patches out as soon as I find them or hear them from you guys.

Budgee Version 1.5/2.0

Speaking of Budgee, about half my time is currently being spent on the revamp for version 1.5/2.0.  I'll be posting more about the specifics as it gets closer to release, but at this point, the non-UI code is the main focus.  The first release of Budgee ran ok, but things were/are far from optimal under the hood.  With this new release, all of that is changed.  It'll run much faster, but the real reason for the change is that it allows for features to be added much more quickly in the future.  I'm also looking at the ability to automatically report errors after they happen and potentially allow bugs/feature requests to be submitted right from Budgee.  This new release is going to be quite awesome - it'll still be simple to use, but there will be more advanced features that can be enabled if you'd like.  I'm still undecided whether the new release will be version 1.5 or whether it will be 2.0.  I know what I'd like 2.0 to do, but I may go ahead and release 1.5 with the new backend and a couple of features...then build up to version 2.0 with incremental updates.  The problem is, I really, really want to get 2.0 out there - it is really the product I envisioned when I first started writing Budgee.

Paper Defense

The other half of my time is now being spent on a new project.  Originally, I started working on a game called ROLLAB - we got about 80% complete with it and then hit a couple of snags.  Some were technical issues (e.g. frame rate was way too low to be acceptable) and some were design issues (e.g. the game just didn't feel quite as fun as either of us would have liked).  While thinking about how to fix ROLLAB, we accidentally stumbled upon a new game idea that we both liked much better.  If you were looking forward to ROLLAB, don't worry, it will still happen eventually. We just need to revise the game concept before we go much further and this new project will give us the proper game engine that we can then use to power ROLLAB.  So what is this new project?  Well, I'm not ready to reveal all just yet - but it's still a 2D game, it's up and running right now with some alpha testers, and it's already quite fun to play.  It's called "Paper Defense" so you can probably guess the general idea of the game from that alone.  More details soon.

Forming an LLC

I've decided to turn Cogitu into Cogitu LLC.  The paperwork has been started, but it'll probably be a month or so before all of the changes are finalized (apparently it takes a while to change things in the App Store).  I started Cogitu as a hobby six months ago.  I wasn't sure how well things would go, so I didn't want to get too much into setting up a formal business structure (since that means a ton of paperwork and a lot of extra costs).  I don't make a ton from Cogitu right now (I'll post Budgee's 2008 sales data this week) - usually around $250 a month - but my goal is to get that to at least $2500 a month within the next six months.  Even if I don't though, as long as the $250/mo+ holds constant, I'll be at the point that I should be filing additional business taxes, so if I'm going to be doing that, I might as well have the legal protection of a business as well.  Honestly, I think the LLC will be overkill - but it's one of those times when I'd rather spend $500 now and never use the legal protection as opposed to needing the legal protection in the future and not having it.  I don't know what the future holds, but my goal is to at least get Cogitu to the point that I could live on the income if I wanted to.

New Blog Posts

I've also been working on a couple of new blog posts that will be coming out this week.  I'm going to start sharing more of my "lessons learned" - mainly from a technical/developer perspective.  I will be posting some about the business aspect as well - including Budgee sales data - just to provide information to anyone thinking of doing the same type of thing I am.  My goal is to have this blog be more about these types of posts instead of just product annoucements - I've just been so busy with everything else that it's hard to sit down and write out a post that I'm satisfied with.  Starting this week, I'm going to set aside an hour or so a day to work on these types of posts and see if that helps.