A neat use of RSS that I completely forgot to mention in my CocoaRadio interview is appcasting (and I am absolutely kicking myself).

Appcasting is a term coined by Fraser Speirs to describe the delivery of software via RSS. It works the same as podcasting: the RSS enclosure tag is used to point to the downloadable file but instead of an audio file, this is an application.

I’ve been running an appcasting feed for Reinvented Software since releasing Feeder in February 2005. However, the coolest implementation of appcasting in the whole world is Sparkle.

Sparkle is a Cocoa framework by Andy Matuschak that can make applications self-updating, uses appcasting to discover new updates, displays release notes and plenty more. It is made available under a MIT license. Even better, Feeder is recommended in the documentation. 😀

I have been planning to switch my apps over to Sparkle for some time now and it’s next on my list, honest.

Creating an Appcasting Feed with Feeder

To create an appcasting feed you will need to tweak Feeder’s default template a little. Here’s how to create a new feed, whether or not you are using Sparkle:

• Choose File > New Feed from the menu.
  • Enter the name of the feed (e.g. “Feeder Updates”).
  • Put the URL of your software’s product page in the Link field.
  • Put something appropriate in the Description.
• Click Continue.
  • With the Default template selected, click the Customize button.
  • Check the checkbox next to the Enclosure fields.
  • Click Save.
• Click Continue.
  • Check the filename and location of the feed is right for you and click Finish. A new item window will open.

Tip: if you keep a copy of your site on disk, and would prefer to save the feed in the structure of that site rather than in Feeder’s library, use Choose Another Location and select the folder where you want the feed kept. You should also enter a web-friendly filename in this case.

Editing a New Version

Each item in the feed refers to a new version of your software. You can create new items in your feed by clicking New Item in the toolbar.

• Enter the name of update in the Title field (e.g. “Feeder 1.3.4 Released”).
• Enter a link to your software’s product page or wherever in the Link field – you need to enter some sort of link or the feed won’t work in Firefox’s Live Bookmarks or OmniWeb.
• Click the disclosure arrow next to Enclosure field to show the enclosure fields.
  • Drag and drop your downloadable file (Sparkle supports zip, tar, tbz, tgz, or dmg) onto the enclosure area to have Feeder upload it when you publish your feed.
  • Alternatively you can enter the URL, click the action menu to the right of the URL field and choose Fetch Attributes from Web (or Fetch Attributes from File if it’s not yet online) to get the type and the length.
• Enter the release notes in HTML in the Description field.
• Close the item window to save the item.

You can then either click Publish in the toolbar to upload your feed or if you don’t want to publish your feed with Feeder, the XML file is always up to date on disk – you can just drag the feed from Feeder to your FTP client, command line or wherever to upload.

And if you’re a developer and using Feeder, or thinking of using it, I’d love to hear from you. Leave a comment or email steve at this domain. Thanks!

If you keep an eye on Adam Curry’s Weblog, this won’t be news.

PodShow are launching a number of new web services, and have set up a developer-oriented blog and podcast at developer.podshow.com where developers can find out more about PodShow’s upcoming technology initiatives including developer APIs, a mailing list and more.

In the inaugural podcast, Andrew Grumet and Scott Johnson discuss PodShow’s plans to create podcasting-related software and services and how PodShow will open these up to other developers.

It’s great to see PodShow getting off to a good start in being open about their services and getting developers involved from the beginning.

Think Mac‘s Rory Prior mentions that he’s switching from eSellerate to PayPal as his business’s payment provider. In a further post, Lowering Costs, he does a very useful comparison of different payment providers.

As you can see from Rory’s table, Kagi and eSellerate come out the same on modest annual sales. However, not mentioned is that Kagi actually offers incentives if you sell more in contrast to eSellerate’s attitude of taking 15% rather than 10% when your annual sales hit $15K. PayPal also offers incentives for higher sales.

I did a similar comparison before setting up this business and chose PayPal. However, during the first month or so some people said they couldn’t or wouldn’t use PayPal. At the time it may have been a requirement to become a PayPal member in some countries before PayPal would accept payment, and not all countries were covered (I don’t think that is an issue today). I had long been a member of Kagi, so added them as a choice. Kagi also has advantages if you’re selling to schools and such, as they will accept almost any form of payment apart from bartered cattle.

I was able to offer both Kagi and PayPal without too much hassle as both of these can contact your server when a payment is made, allowing you to generate and send registration codes. I rolled my own registration system, Rory will be switching to Aquatic Prime. I think it is highly recommended to have a registration system that is not tied to one particular payment provider, since you do not know what the future will bring. All this takes time, however, which is when payment providers’ own systems start to look attractive. But with them comes some measure of lock-in.

There are other fees involved in taking payments too. As I don’t live in the US, I have Kagi wire the payment to me. This used to be $30 but is now $15, making it cheaper than cashing a foreign cheque at my bank, which is £10, or about $17.50 and has the advantage that I get it in 2 or 3 days, rather than 7 to 10. Another consideration with PayPal, if your are selling in US Dollars but that is not your native currency, is that its exchange rate is a little lousy. Even so, the net amount still beats Kagi.

The best thing about PayPal is that you can get your hands on your money whenever you want. Kagi waits until the 21st of the following month to issue payment. So, if I sell a copy of Feeder on March 1st, that payment won’t be sent out by Kagi until April 21st and won’t reach my business account until around April 23rd.

Other things to consider with payment providers are situations such as refunds. With PayPal, you can issue a refund up to 60 days after the payment was made for no fee, right from your account page. With Kagi, if a customer wants a refund, they have to contact Kagi, who contacts you and informs them of your decision – it feels very cold. Kagi keeps its transaction fee regardless and refunds the customer the whole amount, the only person who loses is you. I’ve had this happen when someone chose to buy KIT when they meant to buy Feeder. I was the only party who suffered.

Another advantage that Rory’s first post reminded me of is that European customers don’t need to pay VAT if they use PayPal. This is because PayPal leaves the decision to charge VAT to me, and I am sole trader whose turnover is less than £55K a year (the UK VAT threshold), so I don’t need to charge it. Kagi and eSellerate automatically charge VAT for European customers. That makes me angry.

With all that in mind, I can definitely recommend PayPal to anyone selling software or taking payments over the web.

2005 has been the most amazing year for me. After writing the last post on this blog I remembered what I was doing on Christmas Eve the year before. I was utterly broke, I had been applying for jobs I didn’t want and thought my dream of making a living – no matter how modest – from creating my own Mac software was doomed.

However, for some weeks before I’d been sketching out my ideas for an RSS editing application called Feeder. I saw a gap in the Mac market for a good RSS editor so people could put news feeds and stuff on sites where they didn’t have a blog or content management system to do all that for them. Safari in Tiger was gaining its own RSS reader and I felt this was certain to make people want to host feeds of their own come Tiger’s release in the summer.

I was also vaguely aware of podcasting at this time thanks to early releases of iPodder (now Juice) and iPodderX. I designed Feeder for web designers and had no idea if podcasters would want to the app, but made sure it had some features for them anyway. Besides, podcasting was simple back then; you entered a title, a description and an enclosure with your audio file and that was it.

And so I found myself on December 24, 2004, with just enough money for another 6 or 7 weeks, starting the app that would be make or break for me. I worked on it day and night in quite a disciplined fashion. During the day I coded away on my iMac, working through an OmniOutliner document of features. At night I would do a deployment build, copy that onto my PowerBook – away from the source code – and focus on testing it all, making lists of bugs and necessary tweaks. The next day I’d deal with the bugs and tweaks and start again on the features.

I think this meant that I ended up getting two days’ worth of work out of every one and allowed me to switch personalities between developer and user. I hardly spoke to my friends during that time and barely left the house; I showed my friend Hans Kim some early builds to get his feedback and stuff and he was really excited about it. All my planning and design had paid off – by February 9th I released Feeder 1.0 and it was well received, both by people who wrote to me and in magazines such as MacUser UK, where it got a full 5 mice.

I was delighted. Initially, it only made me just enough money to survive, but that was exactly what I needed. As the year wore on, podcasting started to become more popular and ridiculously so once iTunes was released. Feeder started to get mentions everywhere, including some very popular podcasts such as TWiT, the MacCast, Inside Mac Radio and host of others, Macworld magazine in the US and the UK, PC Magazine (where it beat two of its Windows rivals), the Podcast Solutions book and many other places.

My inbox was swamped and sales grew to such a degree that in a few months I could pay off my credit card bill (I had resigned myself to being permanently around £1200/$2200 in debt), book flights and a ticket for Podcast Expo, continue to eat, buy some decent clothes and most importantly be sure I could continue doing what I love the most: creating Mac software. I also managed to move home in the meantime – twice!

I’ve barely caught my breath since that summer of madness but I’ve got some great ideas for 2006. I hope to kick off the year with Feeder 1.3, which packs in all those other features I’ve been longing to add since the summer and some more that were on my version 1.0 list but never made the cut. For the first time in over a year I’m working on a release that doesn’t need to be done in a screaming hurry to ensure my survival and so I hope it will be the best one yet.

I want to thank everyone who has stood by me in 2005 and helped make it one of the best years I can remember.

Happy New Year!

Anyone who runs a recent Omni Group application will know (because they make it very clear) that their software update process sends some information along when it checks for new versions. For transparency’s sake you can see what is sent, etc, so there is no personal information and nothing evil going on. If there were, users of Little Snitch could soon blow the whistle.

Anyway, Omni make this information visible on their site at http://update.omnigroup.com/ and as a developer this is not only interesting but very useful. It seems most people are using Tiger, with only around 10% on Panther (Mac OS X 10.3.x) and under 1% on Jaguar (10.2.x). It also shows things like CPU type and speed, number of processors, installed memory, etc.

Of course this is limited to people who use Omni Group’s software at a version that reports this information, all of which only runs on Mac OS X, but I wouldn’t be surprised if it were roughly representative of Mac OS X’s user base as a whole. As far as I’m concerned, I’m going to continue to support Panther and later with my apps until their next major versions (i.e. 2.0), both of which are a while off, unless something technical means I can’t do that.