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.

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.

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.

Hopefully, everything will be approved in another day or so...usually the approvals do not take longer than a week unless Apple finds something they want changed first (in which case, it takes about 2 weeks for them to let you know what is going on).  I'll post an update here once I get the green light from Apple.

I'm currently working on a fix and should have the update submitted to the app store late this evening.  I'll post again once everything is in the App Store, but hopefully the update will be downloadable from the App Store by Wednesday Feb. 4th if not earlier.  

In the meantime, if you'll hold off on resetting your budget until Wednesday (and track new expenses via an alternate method temporarily), you'll be able to export your existing data again.  If you don't care about doing an export, then you can just keep using Budgee as usual.

Additional export/backup/sync option(s)

I realize that the CSV export Budgee provides is useful for archival purposes, but the current CSV export was never meant to be the only way to get data out. I'm writing another post about the whole data export situation on the iPhone, but the short version is that the CSV export was the easiest and most "universal" format to add and I didn't want to ship Budgee without some form of export. Going forward, there are several different paths to choose from, but at this point, Budgee will likely get a small desktop app for Windows & OS X. What that desktop app will allow (other than exporting Budgee data) is TBD at this point, but this approach seems to be the most appropriate way to go.

Import option(s)

Along with the backup/sync feature, the other big feature that Budgee needs is a way to import data. If you backup your budget via CSV, you can do whatever you want with it on the PC/Mac, but you can't get it back into Budgee. In a future version, you'll have at least one way to restore the data...so if you end up needing to reset your device for some reason, you don't have to worry about re-entering your budget and transactions.

Multiple budgets

Right now, Budgee only supports tracking one budget and then you reset that budget when you're ready for the next budget cycle. One situation I've wanted to use Budgee in, but couldn't, is where I had my main "household" budget, but then I had a couple of small projects (e.g. kitchen remodel) that I wanted to keep a budget for as well...which I couldn't do. So, in the future (probably in the 1.5 release), Budgee will allow for multiple budgets to be used at one time. Along with this will will come the ability to name a budget. With this new functionality, you'll also be able to keep a budget for each month, week, year, etc. if you so choose (although I still feel that there are going to be better apps out there if you're really wanting to keep detailed budget statistics on the phone).

Shared budgets

This feature will be one of the last to be implemented, because it's the most complex to create and the most expensive to maintain. Budgee currently works pretty well for a single individual, but if you're really wanting to do budgeting the right way, everyone with access to the same finances (husband & wife, entire family, significant other, etc.) should be sharing a common budget even if everyone uses a different device. If you don't do this, then even though Bob & Jane budgeted $200 this month for food, Bob can spend $200 and Jane can do the same, but neither will know the other had spent that amount until it's too late. At this point, I'm expecting this particular feature will be one of the big features in Budgee 2.0.

Income tracking

An ideal personal budget is one that is zero-based - meaning you spend every dollar you make on paper such that:

budgeted income - (budgeted expenses + transfers to savings/investments) = 0

If you really want to do this today, you can enter categories and transactions with negative amounts, which will negate your budget expenses and allow you to do this, but Budgee 1.5 will make this a little more elegant for those that want to keep a zero-based budget. This will also give you the ability to see how much money you should have left AFTER all of your budgeted expenses (if you don't use a zero-based budget).

User Requested Features

There are several features that have been requested by current Budgee users, the top ones being:

• Numeric keypad to enter transactions more quickly
• Ability to "turn off" certain categories for a particular budget (without deleting them)
• User specified currency for budgets (effectively overriding the device's built-in regional setting)
• Set overall budget amount explicitly instead of summing up all of the categories
• Protect access to your budget(s) with a PIN/Password

Plus several other smaller enhancements to make things flow a little better, be easier to read, etc. Most of these will be options that are turned off by default, but you as the user can opt to enable them if you so choose. Budgee is still going to focus on being the most simple, elegant, and useful budgeting app out there - so the default configuration will still be as straightforward as ever, but hopefully Budgee will be adaptable to meet just about anyone's needs with these enhancements.

Various internal changes

Starting with version 1.5, Budgee will be using an entirely new architecture and most likely, a new design (although it'll be in the same spirit as the current design). Other than some visual tweaks, what this means to you is that Budgee will be more stable, better performing, and more streamlined.

If you have additional ideas you would like considered, feel free to leave a comment on this post or let me know at support@cogitu.com

So what's the good news?  Well, in order to fix this issue (and really finish polishing things up), I've decided to hold off on minor updates for now and focus on doing a major upgrade to the internals of Budgee which will result in version 1.5.  In doing so, Budgee will become faster, more streamlined, more stable (particularly if you keep a large number of transactions in it), and most importantly to you guys, it'll have some new features that have been requested for a while now.  The reality is that Budgee was the first iPhone app I created (yep, there are more, but they aren't public just yet...) and it has some things under the hood that need to be improved based on things I've learned since it's release.  I originally planned to hold off on a re-write for a bit, but to really do things right, I need to just bite the bullet and revamp things.  In the end, it'll work out better for everyone - it's easier for me to maintain (and hopefully do more frequent release cycles) and Budgee's users will get the new features they want more quickly and the app itself will be more fun to use.

So how long until this update is out?  Well, it's going to be a little while...it'll be Q1 2009 for sure, but whether it's a couple of weeks or 2 months, I just don't know.  What I can say is that it'll take as long as it needs to get it done right so things are as polished and rock solid as they can be.  Tomorrow, I'll be posting what to expect from Budgee in 2009 - I'm excited about it and hope you guys are too.

In the meantime, if you have any major issues that need to be corrected before 1.5 is released, please e-mail support@cogitu.com and be as specific as possible about the issue.  If no major issues come up, 1.5 will be the next official release, but if there are any large issues that need to be addressed before that time, an interim version will be created.  Stay tuned to this blog for details on Budgee 1.5, Budgee's future in 2009, and the next major product from Cogitu...

In addition to the sale, version 1.0.4 of Budgee has been submitted to Apple.  This update may or may not make it for the holidays (I don't know what Apple's current approval turn around time is...lately it's been taking closer to a week), but it will be live relatively soon.  This update was going to contain a couple of new features, but after re-evaluating the issue list, it became clear that the new features need to wait just a bit longer (I'll explain more in a future post later in the week).  So what made it in?  Well, mainly a couple of internal changes...you'll likely notice very little, if any, difference in your daily use of the app, but it should be slightly more stable and anyone with a lot of transactions and/or categories may notice a slightly smoother scrolling list (there are more improvements to scrolling in the works as well).