Link: The AppleScript Studio Workshop – Adding a Check Updates Feature

Some applications suffer this problem more than others. The most dangerous aspect of this for a developer is to introduce something that becomes a problem, and in the worst case, a millstone around their neck. It’s not easy to remove features, even if they are problematic. Likewise, insufficiently implemented features will generate more work in support requests than they took to add in the first place. The key to keeping this manageable is to work within the scope of the application.

My two applications are oceans apart in this respect. Both have grown in ways I could never have imagined, but none more than Feeder. It started as a fairly straightforward RSS reader, but then became involved in the anything-but-simple world of podcasting. Now it’s an RSS editor, an audio / video file tagger and FTP client all wrapped up in one package.

And yet, on the surface, Feeder hasn’t changed much at all. Someone who bought the 1.0 version for creating a standard RSS feed won’t feel like the app has become something different or unsuitable. The features have integrated seamlessly because they are right for the application. There are many requested features that didn’t make the cut, and I’m satisfied that those decisions proved correct over time.

Together’s potential scope is much broader than Feeder’s to the point that I am still implementing features I thought of four years ago. On seeing the app, people have many ideas about what it should do or be. In the two months since Together’s 2.0 release I have done little more than answer emails and during that time have collected over 100 valid feature requests, filtered through what I see as the scope of the application.

Together’s scope is no different to version 1.0 and that is to store, organize, preview and search files as elegantly and efficiently as possible. In time, the scope might expand without detracting from the fundamental nature of the application, but for now, with strong demand for features that will likely take years to fully realise, there is far too much to be done. Of course, these features cannot be added all at once. People expect regular updates, so each release will prioritise the most needed requests.

Interest in Together has been so great as to be overwhelming. Even with all the work put into the 2.0 version, the potential for the application is huge and some people will be happier with its progress than others. Thankfully, there are lots of options out there, so there should be something for everyone. Obviously, I can’t keep sprinting on the support treadmill, so I’ve set up the forums and placed much more emphasis on the FAQs to try and bring the situation back under control.

As I mentioned when I announced the application, version 2.0 sets the platform from which the app will grow over the next few years. Some things are going to take time, but the future for Together looks very promising, not least thanks to everyone who has supported and contributed to Together and KIT so far. The 2.x series is shaping up to be very exciting indeed.

Third Party Applications on the iPhone: “Let me just say it: We want native third party applications on the iPhone, and we plan to have an SDK in developers’ hands in February.

Much sooner than I was expecting! I would have bet on WWDC 2008, which will probably be the iPhone WWDC now, unlike the last one, which was just pretending to be that (and failing miserably).

It will take until February to release an SDK because we’re trying to do two diametrically opposed things at once—provide an advanced and open platform to developers while at the same time protect iPhone users from viruses, malware, privacy attacks, etc. This is no easy task. [...] Nokia, for example, is not allowing any applications to be loaded onto some of their newest phones unless they have a digital signature that can be traced back to a known developer.

Technologies such as Leopard’s Code Signing would support this, which is a good sign (pun, sorry) as any developer can do this.

While this makes such a phone less than “totally open,” we believe it is a step in the right direction. We are working on an advanced system which will offer developers broad access to natively program the iPhone’s amazing software platform while at the same time protecting users from malicious programs.

It was always going to take Apple a while to create the tools for iPhone development and usually you get no word from Apple about something until it’s ready to be seen. Looks like with all the recent noise, Apple felt they had to make a statement. This goes a long way to removing worries that iPhone development will be restricted only to those whom Apple deems worthy. Should be interesting!

Between this and getting Leopard out on time (although no GM build to developers just yet, we’re stuck with the last buggy effort), Apple has made this Mac developer and user very happy. For now!

For anyone who doesn’t know, Late Night Cocoa looks at a different topic every week with a guest developer and is suitable for both novice and experienced Cocoa developers. It stands out because its host, Steve Scott, aka Scotty, does an excellent job producing a podcast that is not only useful and informative but also sounds good too. A lot of work goes in behind the scenes to make that happen.

And, as always with a podcast, you can listen to what you want when it suits you, so if one topic doesn’t interest you, there are bound to be plenty more that do. So if Cocoa development interests you, check it out.

Who’d have thunk? OK, maybe nobody but me!

In reality, that sort of difference is negligible. Actually, in reality it’s a completely meaningless figure and subject to many variables, but it is good, clean, pointless fun to find out about this stuff.

For example, such a count could depend on how you do your brackets. I do them on one line unless it’s a method definition, a condition that spans two lines or I simply don’t feel like it:

    if ([name length]) {
        return name;
    }
    else {
        return [[[self localFilename] lastPathComponent]
                   stringByDeletingPathExtension];
    }

But many people do them like this:

    if ([name length])
    {
        return name;
    }
    else
    {
        return [[[self localFilename] lastPathComponent]
                   stringByDeletingPathExtension];
    }

So that could add a few thousand lines to my count.

Perhaps more telling is this: Feeder 1.0 was 24,679 lines. How it’s grown!

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!

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.

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.

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!

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.