The Flying Jalapeño Lives

If you have done any iPhone development, you are already intimately familiar with table views. They are an integral part of UIKit. They are highly flexible and customizable.

However, making table views work smoothly with anything but a small, simple, static data set can be trying, to say the least.

Many Cocoa developers have come up with solutions to cope with scrolling performance issues, abstracting cell content, creating preference views, adding network awareness, etc…

Ideally much of this functionality should have been included in the Apple frameworks. Alas, this is not the case. We must use third party solutions to fill the gaps or “roll our own” solutions. Sometimes we need to combine the work of several developers into one class.

Recently, I had to create a network aware table view that also supported filtering with animation. Already having setup a UITableViewController for receiving network data, all that was needed was to filter my data and animate the change. Simple.

Well, not really. If you want to perform that nifty animation that Apple uses when viewing missed calls in the phone app, you will most likely need to make some changes to your current design.

To analyze the problem, lets look at the major components: data model, presentation model, view. We will stay away from code, and look more at the design to accomplish this.

For my typical table views, Matt Gallagher’s solution works fantastic.

The diagram is a bit simplistic, but illustrative (In reality, we have nested arrays representing sections within the table). There are two arrays, one to hold our model data and one to hold our presentation data. Also note, the structure of the data model does NOT necessarily need to reflect that of the table, but it seems logical to organize this particular set of data in this manner.

We have created a “Cell Controller” to manage individual UITableViewCell logic. The UITableViewController now only has the responsibility of creating and destroying these Cell Controllers. This moves the UITableViewController one step closer to adhering to SRP.

One undesirable aspect of this methodology is the requirement to instantiate every Cell Controller and link it to its model data upfront. In return you receive better flexibility and encapsulation without a noticeable performance loss (at least with the moderate sized data sets I have so far worked with).

So, lets look at our basic algorithm for creating our Cell Controllers:

1. Loop through each dictionary in the model data array.
2. Create a cell controller.
3. Add a pointer to the dictionary in the cell controller.
4. Add the cell controller to the array of cell controllers.

This approach works well for static tables and it is easily adapted for network aware tables. For static tables, you set up your relationships once, and your done. For a networked table, you must add a new object to handle network activity. Then they can communicate through any combination of notifications, KVO, and delegate methods.

This is pretty basic, but it is nice to see the relationships laid out.

Now we need to modify our approach to handle filtering. We need a way to represent the full data set and any subsets. Two methods of accomplishing this task are:

1. Create separate arrays for each set. One for the full data set and one for the filtered set.
2. Use a flag to mark filtered results.

Flagging is preferable for a two reasons. In reality, the data didn’t change, we just want to update the presentation. In this case we don’t want to actually modify our data. Additionally, it is more difficult to track several arrays and which one is the “real” data.

As we stated earlier, the presentation model needs changed to display the filtered results. In our previous design, the view controller “looked” at the model and created the cell controllers based on the structure of the data. Not much has changed, but now we just need an additional check. So our algorithm could be:

1. Loop through each dictionary in the data model.
2. If a dictionary has the flag set,
   • Create a cell controller,
   • Add a pointer to the dictionary in the cell controller,
   • Add the cell controller to the array of cell controllers.
3. Finally, replace the old (unfiltered) array of cell controllers with the new (filtered) one.

As we connect the Cell Controllers to their corresponding model data, we check our flag. If we did not want to animate our deleted cells collapsing, we would be finished. We need to devise a method tell our table view which cells have been removed (as well as sections).

There are a few ways to accomplish this. In place of the previous algorithm we could do the following:

1. In our view controller, loop through each cell controller in the array.
2. If a cell controller’s model dictionary does not have the flag set,
   • Add the cell controller’s index to an indexPathSet to removed from the array
   • Add the cell’s index path to the array of cell paths to be removed from the table.
3. Remove the cell controllers from the array of cell controllers.
4. Remove the table view cells from the UITableView.

Not too bad, but we have completely changed our algorithm. Instead of creating an entire new array of cell controllers, we now remove the ones . The motivation behind this, is that we need to give the table view a list of cells to delete. If we had used our previous algorithm, it would have been difficult to produce this list.

We have just one more issue, but you will not discover it until you try to update a remove all the cells in a section and you app crashes. UITableViews do not like empty sections after deletions. So make sure you remove any empty sections as you remove UITableViewCells.

Hopefully this helps some of you get a head start on your table views. We mostly went over design and algorithms which should help you produce your own code and cut down on much of the trial and error that goes into this problem. In a future post, I will include some code as well.

Let me know if you have already coded your own solution to this or are using open source code.

If you want to run Clang from a GUI you can using the tool at this site:

http://www.karppinen.fi/analysistool/

Not that the scan-build CLI is that intimidating, but if you have any problems getting reports (I just had an issue with a static library), it may help

Getting started in Cocoa can be hard. Just learning the frameworks is a challenge.

Once you get to that point, most or your journey still lies ahead. If you were like me, you probably learned a lot about iPhone programming from online tutorials and books. Then one day, after your 16th tutorial and 3rd book, you looked around and said, “Now what?”

The truth is that technologies like Core Animation, Core Data, and Core Graphics are just tools. They are only a means to an end.

A full toolbox does not make a carpenter good. You still need experience, planning, and vision.

With this in mind, I want to talk about Key-Value Observing. This won’t be a full coding example, per se, but a discussion of how you may use this tool in your code.

Many readers may know the gist of KVO, as well as KVC and bindings. Although bindings are beyond the scope of this post, we will give a quick definition of keys and Key-Value Coding.

KVC is a technology that allows you to access an instance variable by using a string referred to as a key. So using an example:

To access are aptly named dictionary, we can type the two equivalent statements:

They do exactly the same thing, but in KVC we use supply keys using the “valueForKey:” method available to all NSObject subclasses.

To set this property we can use either of the following statements:

This can get more complicated with key paths and some other things. If you would like more information, there are some great tutorials available here and here.

Now to KVO. For those who don’t know, KVO provides a mechanism to receive notifications that an instance variable, has been modified. Of course you know now we will be using keys to do this. First you register as an observer for the key:

(Note: I won’t engage in any “self=[super init]” talk here)

We simply registered the class to receive notifications about its own instance variable, but we could have easily selected an ivar of another object.

We also have set some options and a context here, but nothing that need be delved into for our discussion.

To receive the notification, we need to implement one method:

Every time the instance variable is changed, this method will be called automagically.

Now that we have a very, very rudimentary understanding of what KVO (and KVC) are, we can begin to talk about how to use them.

One very common use of KVO is model observation. On stack overflow, I see many questions like: “If I have a variable in view controller A, how do I pass it to view controller B?” Of course the real problem is that we are asking the wrong question.

The right question is: “How can I get two view controllers to know about changes of a single variable?”

We know now that we can use KVO. What we want to do is make our views observe our models. By registering view controllers as observers to the model, we can have an unlimited of views showing and/or using the same data. This also gives us well defined MVC boundaries. What’s more, is that we will write almost no code to accomplish this feat.

As you will read elsewhere, KVO has some (few) disadvantages. The one that sticks out, is that it may make your code harder to debug. This is because it is hard to sometimes tell who is observing who. Otherwise this is a very elegant solution that will eliminate some of your glue code.

If you want to go deeper into Key-Value Observing you can read more here, here, here, and of course you can use Apple’s documentation.

What are some uses and patterns of KVO and KVC in your programming?

After Scott Stevenson put out this question on Twitter and his subsequent blog post, it got me thinking. When I really started digging into Cocoa, I remember staring at UIViewController and UITableViewControler for hours, maybe days. Figuring out what all of those methods did seemed impossible.

In retrospect, I can see these classes represent some of the fundamental design patterns used in Cocoa (touch): delegation, composition, protocols, MVC, nibs, memory management, etc… Once I understood how to use a UITableViewController, I was able to dissect and comprehend the interactions and use of other classes much more easily.

There were many “ah ha” moments when learning those concepts. Previous to iPhone programming, I mainly wrote C and machine level code. It wasn’t my first foray into OOP, but it has been my deepest and most comprehensive.

Learning to write methods that you never actually call yourself was a huge mental hurdle. Splitting class responsibilities according to MVC was logical, but hard to do right (I know, a discussion in itself) the first few times.

Similar to MVC, was memory management. It’s so easy: alloc(or new or copy)+retain = release+autorelease. But when do you actually release? When should you just set to nil? Should you use the accessor or not? Maybe it is best to just use the assign property. Should I create an autorelease pool? Is it best to just “leave the object around” and just handle it if a memory warning pops up. You have a lot of design decisions to make even though the basic premise is simple.

Nibs were simply awesome to layout my views, but learning to hook up the right things and how to use them effectively was no simple task. The outlets and actions themselves weren’t that confusing. The “things you don’t quite have to know until there is a problem” were hard to get my head around. For example: how to load nibs from other nibs, load UINavigationControllers in UITabBarControllers, what the proxy objects actually are, which controller classes to include in the nib, what “really” happens when objects are unarchived, realizing that “initWithCoder:” is called on classes that are defrosted from a nib, how to load UITableViewCells from nibs, etc…  There are many intricacies, most of which you never think about until your app doesn’t work.

After I had some time to think over these problems and Scott’s question, I came to realize (at least for me), Cocoa just took time to learn. Everyone comes from a different background with a different skill set. Add to that, the size and breadth of Cocoa. It should come as no surprise that everyone has to take there knocks when moving to Cocoa and Objective-C, no matter where there coming from (save Next developers).

So, how to wrap this up? To all of the beginner iPhone and Mac developers: know that you have a mountain to climb. Find information where ever you can. The Cocoa development community is great and there is no shortage of resources. Eventually you will reach the “critical mass” of information when you can begin to solve your own problems much more effectively. You will always have more to learn, but will develop an instinct to find what is wrong and begin to ask the right questions.

Is there anything that you think is missing from Scott’s list or that I glossed over? Let me know.

I have been using Xcode’s integrated subversion SCM for several months (against the advice of several articles). Overall, it has been pretty painless. Xcode has a simple set of svn functions, but meets 90% of my needs.  The biggest advantage is the integration within the IDE.  Moreover, if I needed advanced functionality, I could always go to the command line. So, I lived, and loved, with Xcode over the next few months.

I originally decided to try Xcode after some experience with Versions.app, my first SCM experience. Versions is a collaboration between Pico and Sofa. I used Versions during it’s beta. At this time, I was painfully inexperienced with version control. I frequently went back and forth between Versions and Terminal, picking up what I needed along the way.

Eventually, when Versions went 1.0, I made the decision to not purchase it. I could never get Versions to display all of the change logs of a working copy if it hadn’t existed locally since the creation of the repository. As I said, I wasn’t the best with svn at this time. I probably just couldn’t find the control to download the logs from the repository, but it shouldn’t have been that difficult nonetheless. This was something that should have happened “automagically”.  This and a few other quirks didn’t make a good value (for me) over Xcode and the command line.

Flash forward to last week when my repository host, beanstalk, sent a notice they were upgrading all repositories to subversion 1.5. This influenced me to look into upgrading my client side software to use 1.5 as well. At first, I figured I would just patch Xcode to use 1.5, but that seemed unnecessarily complicated. So once again, I decided to try an external solution, but armed with a much better understanding of my work flow and subversion itself.

I downloaded new demos of both Versions and Cornerstone. I had briefly looked at Zennaware‘s offering before, but this time I was able to examine it much more thoroughly. I setup Cornerstone first, and to be honest, I haven’t looked back.

Before I move on, this seems like a good place to get 2 (related) points of contention out of the way: DVCS (Git and Mercurial) and SCM GUIs.

I’ll address my need for a GUI first: I want a seamless and easy way to perform my version control. I already perform enough tasks extraneous to actual programming. I want this part of my workflow to be “point and click”, allowing me to focus more on delivering code.

As far as DVCS: I realize that Git is the new “hotness”. At this time, I operate primarily as a solo shop. Additionally, I now know how to get around svn just fine. For me there is no overwhelming advantage that switching to Git would provide at this time. I am almost never working out of internet range and I don’t collaborate very often. Moreover, there is no “great” GUI for Git yet. I am sure one is eminent, taking in account GitHub as an example of Git’s growth in both marketshare and mindshare.

Back to Cornerstone.

I really like its layout. It matches up extremely well with my “mental” picture version control.

The side bar is split: working copies up top, and repositories on the bottom. This is in contrast to Versions where the repositories are like “folders” and the working copies are subfolders.

The main window contains a file browser for the selected repository or working copy. When I pressed the space bar, I got a nice surprise: Quick Look. Located along the top of the main window are quick filters for “changed”, “modified”, “unversioned”, etc… These make it super easy to filter a long list of files.

When you make a commit, Cornerstone automatically asks if you want to begin versioning any files not added to the repository. Sweet.

By clicking a checkbox, you can automatically setup your repository with the default trunk, branches, and tags folders. You can also set ignore files just as easy.

Corenerstone has an entirely different window devoted to file history. Simply select one or more files within the file browser and click the history button. You are then presented with a graphical timeline with a “node” for each past revision. Select any 2 nodes and they are opened for file comparison.

This presentation does have some drawbacks. Primarily, it just doesn’t scale well. Each file has its own timeline at the top of the window. This works well for a few files, as you can see. View many, though, can be cumbersome. It is possible to view a timeline for just the root folder of the repository which cleans it up a bit, but this wasn’t an immediately obvious solution.

Corenerstone has a decent comaparison engine built into the app. Versions performs its comparisons by using an external app of your choosing. I know many users love this because it enables them to use their favorite comparison tool. Personally, I prefer the speed of Cornerstone’s implementation. With a single click, I can compare any local changes to the latest revision.

When packing a large amount of information in to a GUI, some items will become focal points, while others will move to the periphery. For me, it appears as if commit messages and change sets are presented as second class citizens in this Corenerstone’s UI. They are regulated to a small info pane whose purpose wasn’t readily apparent. Versions, on the other hand, has the change sets and commit messages beautifully laid out in a seperate view.

I imagine that when I stop working on a 13″ Macbook and have a larger 24″ desktop, it won’t matter so much. This will also allow me to evaluate Cornerstone’s ability to switch froma an all-in-one mode to a multi-window mode, ala Xcode. With a large and/or multi-monitor setup, these issues will likely disappear. My interface complaints are mostly my fault for developing on a contrained consumer laptop.

Speaking of hardware limitations, Cornerstone did not seem to be bothered by the specs of my development machine. Not that you would expect a subversion application to give a modern Mac any such issues. All the same, I haven’t noticed any interface delays, network hangs, excessive disk access, or any other performance problems. This clearly demonstrates the skill, care, and time investment of the developer, who from my understanding operates a single-man shop.

Cornerstone’s interpretation of the svn domain is the most solid out of the apps I have seen (although I admit to not diving as deeply into all other solutions). I am currently running Cornerstone in its demo period and plan to purchase it soon. It has definitely made subversion painless to use while packing a fair amount of power into its interface. If you are seeking a powerful GUI for subversion, Cornerstone is the best you can get.

In case you’ve been missing out, there are 2 really great tutorial series out in the blogeshere.

First, is an excellent series on cocos2d for the iPhone by Keith Peters at BIT-101:

cocos2d Tutorials – TOC

Second, is an in depth look at at OpenGL ES for the iPhone at Jeff LaMarche’s (of “Beginning iPhone Development” fame) aptly named iPhone Development Blog:

OpenGL ES From the Ground Up, Part 1: Basic Concepts

Enjoy!

Your ability to find, qualify, and digest development information is extremely important. Whether you are a new developer of a seasoned vet, you are always learning. You need to find information fast and effectively.

When you have a question, it is easy to type it into a search engine and find an answer. Sometimes, though, you don’t know what question to ask.

Enter development blogs. A steady stream of information, tips, tricks, tutorials and great open discussion. I subscribe to over 50 feeds from development blogs using Google Reader as my RSS reader of choice.

Besides “doing”, this is the best learning tool I have. I consistently read articles addressing problems I haven’t thought of yet. I find sample code I can stock pile now and use later. The Cocoa community is extremely helpful and talented.

Most developers carry their tedious attention to detail into their blog writing. This leads to infrequent, yet highly polished and information rich posts which are easily scoured in your feed reader.

So, what feeds do I read?

Below is the list of web sites of who I keep in Google Reader (in no particular order).

I’m sure I left out some, so let me know if you have any good blogs that should be on my list.

Cocoa Samurai »

Cocoa Convert »

NotTooBad Blogging »

revetkn.com »

Manton Reece »

71² »

Jayway Team Blog »

toxicsoftware.com »

UI and us »

47 Hats »

Software by Rob »

markjnet »

Joel on Software »

iPhone Development Blog »

inessential.com »

BIT-101 Blog »

Mac Fanatic »

Coding Horror »

Fraser Speirs »

Theobroma Cacao »

Cocoia Blog »

Mac Developer Tips »

iPhone Development »

How to Make iPhone Apps »

Cocoa with Love »

iPhone Developer Tips »

Cocoa Is My Girlfriend »

iphonedevelopmentbits »

iPhone SDK Articles »

iPhone Software Development »

Fiery Robot! »

iCodeBlog »

PrEV »

Trails in the Sand »

Mobile Orchard »

Red Sweater Blog »

NSCoriolisBlog »

Ben’s Dev Blog »

Hot Chocolate »

iApps Development Blog »

memo.tv – iPhone »

Ninth Division LLC »

coders »

Iphone Noob »

shanecrawford.org »

bbum’s weblog-o-mat »

BinaryMethod »

NSBlog »

Pieter Omvlee’s Blog »

Dubroy.com/blog »

Kickingbear »

Degutis.org »

Tech Thought »

Domain of the Bored »

Waffle »

Gus’s weblog, adventures in Flying Meat. »

stevenf.com »

Dave Dribin’s Blog »

Clickable Bliss Blog »

From a remote village »

rentzsch.com: Tales from the Red Shed »

Marc Charbonneau’s Blog »

Call Me Fishmeal. »

Lap Cat Software Blog »

Matt Legend Gemmell »

Michael Tsai’s Weblog »

I’m currently involved in a project where I need to load some photos from the web and I need a UITableview with some thumbnails and with Photo.app navigation.

Enter Three20. Three20 is a framework written by Joe Hewitt that abstracts much of the functionality of UITableViews, UITableViewCells, and networking away from the programmer. The way the components are abstracted is clearly MVC, but done in a more “web application” way. I believe Joe commented in his recent interview on the Mobile Orchard podcast.

When you download Three20, there is a nice sample app included with just about everything you can create. This provides a great overview of what is included within the framework.

The functionality of the UIKit classes has been abstracted to the point that you never really touch the usual delegate and datasource methods. You create view and controller objects through a completely different programmatic interface.

You can create tableviews and photo galleries very easily by just adding creating a data source array and the view classes basically take care of themselves. This was very cleanly done. For instance, to determine the type of cell that will appear in your table, you populate your datasource with a specific type of *Field object. A TTTextTableField produces a text cell, a TTSwitchTableField yields a cell with a switch, etc…

To create a Photo Browser View and/or a Photo Thumb View is slightly more difficult. You will need to define your own Photo Datasource class. In the example code, there is a mock photosource class setup that provides a good starting framework.

Unfortunately, the requirements for my current project didn’t allow me to use the Three20 classes as is. I had to dig a little deeper into the framework and modify it to suit my needs.

When you dive into the code, you quickly find all the Cocoa classes have not been merely subclassed, but have had there behaviors completely altered. I could use the basic, high-level classes, but I could not understand exactly how they worked behind the scenes. I needed to subclass the TTThumbViewController and I had to understand what I needed change to make it work for me.

To be frank, it is complicated. So complicated, I considered giving up subclassing it several times during my adventure. As I began to decipher the interconnections and roles of different objects, some design patterns began to fall out. An interesting note is Three20′s use of delegates. There are many delegates and controllers and controller delegates and datasource delegates, etc…  This was one of the main reasons it was hard for me to fully comprehend the framework. I literally had to pull a notebook out and start drawing the connections between the classes.

After a few hours,  I felt I had a decent understanding of the underpinnings of the relevant classes which I needed to alter. I began to make my construct my classes and finally accomplished my goal of customizing the thumbs view to the following:

I know, not very impressive on the surface. What I managed to do was add section support to the TTThumbsViewController. The stock class only supports a single section with no division between the rows of photos. Also, it only supports one photo source per view. I have changed it to allow a photo source per section (Even though it looks like one source, it’s actually 2 sources with the same data).

It’s not bug free yet, and [redacted] betas are a little picky. When I get a little more solid, I’ll see if I can get a fork going on GitHub and upload my additions there.

In the end, I think it was worth getting intimate with Three20 to get all of the networking and photo browsing goodness for free.

I encourage everyone to check out Three20. It works great for just about anything you want to do. If it was my decision, I would have just changed my design to accommodate the framework and save myself a weekend.

Let me know if any of you have used Three20 and what your experiences were.

If you have any Cocoa touch or Objective-C questions, don’t just limit yourself to Apple’s Dev Forums. There is a thriving community of Cocoa developers on Stack Overflow at your disposal.

You will find a variety of questions from novice to advanced. Stack Overflow has a policy of “no stupid questions”. Which means you won’t get attacked for asking a “easy” question. Jeff Atwood and Joel Spolsky stated on their podcast (which is also phenomenal by the way) that they want to be like a programming “Wikipedia”. That is why the like and encourage all levels of questions.

Go to Stack Overflow and start posting, commenting, browsing, and, of course, as answering many questions as you can.

As indy developers, we need to track our finances. Most of us can’t afford to staff an accounting department, so we look for software to fill the gap.

We need to track cash from sales of iPhone apps and/or iPhone contracting. I assume most of those reading my blog need both. (Side note: if you’re not in the iPhone contracting market, get there, another article…)

We have many contenders fighting for mindshare, loyalty, and sales, from the big boys to the indys. So how do we decide? What is important to us as iPhone developers, software vendors, and contractors?

Like good little programmers, we’ll logically split our problem into bite size pieces.  Here is what we need:

1. Invoicing
2. Job Tracking
3. Project Tracking
4. Bank Transaction Download or Import
5. Double Entry Accounting (for tax purposes)

When I say project management, I don’t actually mean how we as developers track our project progress (scrum, agile, issue trackers, etc…). I am referring to a means to group jobs and invoices under a common “umbrella”, not only by customer.

It would seem to me, and to most of the financial software venders that we have three distinct problem sets. The products I have been demoing specialize in a some combination of invoicing, accounting, and/or banking.

This separation of responsibility leads to an additional requirement: exporting and importing data between apps.

I won’t be doing full blown reviews, there are many available on the interwebs written by better reviewers than I. Instead, I will give a quick impression, some key points, and links.

Without further adieu, a look at the products:

Invoicing, Accounting, and Banking

Quickbooks

Lets get the elephant out of the room first. For me, Intuit’s offering is overkill. It does everything, with all the flair a professional accountant could ask for. As developers in the digital age, we are not tracking inventory and tend to have few employees and a little office overhead. Our needs are small and I don’t feel such comprehensive tool is required for most ISVs.

AccountEdge

MYOB has two relevant products. AccountEdge is poised to compete with Quickbooks. Suffice to say, it is not exactly on my radar.

FirstEdge

MYOB’s slimmed down, small business oriented product is much closer to what I am looking for in an accounting app. If you are looking for a solid accounting app with more features than you will ever need, while remaining as simple and Mac like as possible, look no further. FirstEdge gets high marks from the usual review sites. It’s not as complicated as AccountEdge or Quickbooks, but it’s still very “formal” in the way it handles your data. I know many consider this a feature, but with my limited knowledge of accounting, I think we can go even leaner.

Money

This app by Jumsoft is really nice. It has that familiar iTunes / Mail.app feel. It’s a nice one window interface with a sidebar used for selecting and presenting relevant data. It has decent reporting as well.

It has a template editor for invoices to make you look more professional. One strange quirk of Money is splitting invoice templates between “Styles” and “Layouts”. Styles are non-editable preloaded templates and Layouts are templates you can edit. The downside? You can’t use Money’s professional Styles as a starting point for your own templates. Just weird.

Importing bank data is also not automatic. It does include a “Web Bank” option which launches your bank’s website (in Webkit) within the app, but when I tried downloading transactions this way, it didn’t work. This may have something to do with the Safari 4 beta or not. Bank connectivity is a definite sticking point in an otherwise great app.

Accounting & Banking

iBank

Sure it has a cliché OS X name, but it is a great app. It is similar to Money, minus invoices, plus direct bank downloads. Additionally, IGG Software built in automatic connectivity with their Accounting/Invoice app, iBiz.  This is a great selling point.

IGG  has positioned iBank as accounting and banking with iBiz handling invoicing (with a bit of Accounts Receivable). This puts your Accounts Receivable (money coming in) within a separate app from your actual bank accounts and Accounts Payable (bills). This presents an interesting division of responsibility some may like and some may not. A downside is it may be a few more steps to see your total financial picture.

You can, however, create an asset account representing Accounts Receivable in iBank to which you can then transfer your invoices from iBiz. This works, but is slightly clunky. First my invoices sometime are imported as a withdrawal, instead of a deposit. This seems odd so I may be doing something wrong here. Second, moving a transaction from Accounts Receivable to a real account (on payment) is not automatic. I have to add the transaction to the bank (or download) and then deduct the amount in Accounts Receivable. As you can see from all of my words, this is not the workflow that IGG intended and is involves much extra work.

Invoicing

A note: there are many invoicing apps available for OS X. I probably missed some, or just didn’t include them.

iBiz

I’ll cover this first to keep it close to iBank. As I mentioned briefly, iBiz is attempting a bit of double duty. It has full Accounts Receivable capabilities. It can track open invoices, and send payments to iBank. This workflow is pretty nice. I think the interface is a little lacking, especially standing next iBank, but it isn’t the worst I’ve seen. Also it has reporting, but it’s not dead simple an maybe expects iBank to perform the “heavy lifting”.

It has an invoice editor, but invoices are created using HTML. My job revolves around coding, I really don’t want to mucking around in HTML just to make an invoice. I really feel that any invoice editor should be WYSISWG. iBiz’s users aren’t necessarily coders. I have to think overly complex template editing alienates some potential users.

Profit Train (formerly Billable)

A great, dead simple, invoicing app. It doesn’t waste a single button or window. It allows you to have multiple businesses that you can invoice from. More importantly, switching from one to another is scary easy. It also tracks expenses, and you can bill clients for expenses. Profit Train is still in beta and not feature complete, so I can’t be give a definitive ruling as of yet. Even in beta, Profit Train is extremely solid, with what I feel is the best interface of all of the invoicing apps.

Billings

Market Circle has a great app that many swear by. It clearly divides the interface between work and billing. I think this is good, but I don’t quite like the implementation of slips. They seem needlessly complex. Not that I am saying reduce the functionality of slips, it’s just that the default slip UI should be simple. Billings does allow you to group slips by project and invoice multiple slips. Billings also has many, many reports. Another great plus is that Billings will soon launch a companion iPhone app. Billings also has one of the best invoice designers. Billings also has export ability, but I did not test it.

GrandTotal

GrandTotal is an interesting entry. It fills most of my invoicing requirements and has export capability. It’s interface is pretty nice, but something is a slightly off. I think the structure has layout has something great going for it, but just needs some polish. Not “bling”, which it uses effectively, just some shuffling around of controls. The invoice editor/designer is good, probably second to Billings. GrandTotal has a free iPhone companion app with MobileMe syncing. This is a solid all around pick.

On The Job

Another solid pick. Very simple, very Mac like. I think it has a great invoice designer except for the fact there is no “save”. Don’t mess up, because all changes are permanent! I think the straightforward thought interface goes a long way in this app. It’s hard to write much more about it, you just have to use it to understand what it brings to the table.

Involver, Invoices, Invoice, etc..

I’m not delving into these products for one reason or another. Most do somethings well, but may be unpolished or don’t differentiate themselves from the pack.

SAAS

I’m not really evaluating these, I don’t see a need to keep this data in the cloud. However these are viable options with many in the link provided.

(Long) Conclusion

Overall, I find that none of the solutions are ideal. I’m sure that this is most view their accounting software. I am probably being a little picky and will likely be told so in the comments, but I don’t think I am being too demanding. However, I am self-aware enough to realize I am a UI snob which is heavily infuences my software decision.

I applaud the developers of all these products for creating complex software that is expected to perform perfectly or it is deemed a failure. Customers have (understandably) high expectations when it comes to safeguarding their financial data. With that said, I think that small business accounting and invoicing apps are still going through major maturation.  As a Mac user, you and I have insist on a great user experience. Couple that with the complexity that is accounting, and it gives these developers a tough UI problem to solve. I think several of these apps are on a great trajectory with a lot of room for growth and polish.

So what will I do?

Well, I’ll have to settle on an invoicing app soon. I can’t keep bouncing back and forth.

I like the simplicity of Profit Train, but want to see it in it’s 1.0 (really 2.0) form.

On The Job has much of the simplicity of Profit Train, with a WYSISYG invoice editor.

GrandTotal is solid. It’s a little crashy (Safari 4 beta problems, I believe), but it has promise.

Billings has everything the above three do, a better invoice template editor, but a a lesser UI.

For a one stop shop, I think Money is really close. I want this to be the app. It just seems so odd not have automatic transaction downloads in 2009.

I’ll have to pick one of the above invoicing apps and hope I can export my data to an accounting application I select in the future.

In conclusion, I  have a lot of thinking to do… (And most likely a second post).

After your considerable time investment in reading this post:

Don’t forget to tell us what you use!