Konrad Lawson at The AppleScript Studio Workshop has written a comprehensive tutorial about including Sparkle for automatic software updates in an AppleScript Studio project. The tutorial also mentions Feeder as a way to create the appcast feed:

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

Any developer will tell you that no application can remain simple for very long. This is good as further development of the application through ideas and requests means that the application can grow with a receptive audience. The difficult part is determining how.

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.

Reading Steve Jobs’s words on the Apple Hot News page, it really couldn’t be better for developers:

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! 😉

I appear as a guest discussing Search Kit, the framework for indexing and searching files and text on episode 14 of the Late Night Cocoa podcast, out 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.

Apparently, Feeder 1.3.3 has 1,843 more lines of code than RapidWeaver – 60,273 in total. That doesn’t include any third-party frameworks or my own Reinvented.framework, which is generic between my applications (mostly handles software registration and some other stuff, maybe not all used). That framework contains 3,043 lines of code.

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!