Adding Automatic Update Support to your Application

How the Automatic Update Workflow Works

When a program can reach out to a server and ask if a newer version exists, a few simple steps keep the whole process tidy. First, the client hits a URL and downloads a tiny data file – a few kilobytes – that tells the application what the latest build number is and where to fetch the update package. Once the client knows the server’s version, it compares it with the version that it’s currently running. If the numbers match, nothing more is needed. If the server reports a higher value, the client starts a download that usually ends with an installer or an archive that the application can unpack and install itself. Because many programs need to overwrite the executable that’s running, the update logic typically spawns a helper process that does the replacement after the original instance shuts down.

There are a handful of constraints that a robust updater must respect. It should keep the user’s workflow uninterrupted – a large file should download in the background while the user continues working. If the network connection drops, the download should pause gracefully and resume once the connection is restored. And if the update requires the executable to be replaced, the updater must close the running instance safely, install the new binaries, and restart the application automatically. Meeting these requirements keeps the experience smooth and minimizes frustration.

The core logic – fetching, parsing, comparing, downloading, and applying – stays the same across almost all frameworks. What differs is the language, the libraries you use, and the way you store the metadata. In the examples below we’ll focus on Delphi, using a lightweight XML file for the metadata and the Clever Downloader component for the network transfer. The same pattern could be translated into C#, Python, or any other language that offers HTTP clients and XML parsers.

Because the user sees only the “update is available” prompt and the “installing now” splash, the internal steps are hidden behind well‑structured classes. A simple class called TclWebUpdate keeps the whole flow in one place: it loads the XML, checks the version, kicks off the downloader, and listens for completion events. The helper process that performs the self‑update is launched only after the original application signals that it can exit safely. That way the user never has to manually restart the program after an update.

By keeping the updater logic in a single, reusable component you can drop it into any project and get the same behavior without rewriting code. You can even add more sophisticated features – like checking for digital signatures on the update package or logging download progress – without touching the rest of the application. The key takeaway is that the whole process is driven by the small XML file hosted on your web server, and the rest is just glue code that connects that metadata to the file‑system and the network.

Setting Up the Update Metadata

All the decision points – which update to fetch, how to verify it, what to do after installation – are stored in a tiny XML file that lives on your website. The file is simple: it contains a product node with information about the vendor and a child update node that describes the latest package. The update node holds attributes such as url, version, size, and runparameters. The runparameters attribute lets the installer know how to start the program after replacement.

Here’s a minimal example that matches the structure expected by the demo code. Save it as webupdate.xml and host it somewhere reachable from your clients.

Once the file is online, the client downloads it and parses it with a DOM parser. The code below shows how to read the attributes and populate two records – one representing the metadata fetched from the web, and the other storing the last known update state on disk.

The LastUpdateInfoFile is optional. It lets the updater remember the last version it installed, so that a fresh install can skip an update that the developer intentionally released as a patch for a previous build. If the file is missing or the version field is empty, the updater treats the local state as “unknown” and will always check the server for a newer version.

Comparing the server’s version string with the local one is straightforward when you use a simple integer scheme like 1, 2, 3 …. But most applications follow the major.minor.release.build convention, e.g. . The demo contains a helper that converts each component into a numeric value so that you can compare full versions with a single integer comparison.

When the comparison routine returns True, the updater knows it has to fetch a new package. If the comparison says nothing is newer, the client simply keeps running the current build.

Downloading and Applying Updates

Once the updater decides that a new version exists, it has to bring the new binaries to the client. The demo uses the Clever Downloader component, which abstracts the underlying HTTP/HTTPS/FTP protocols and gives you a simple interface. By setting Async := True, the downloader runs on a background thread and immediately returns control to the main application. This allows the user to keep working while the update file streams in.

The OnProcessCompleted event fires when the download finishes. Inside that handler you typically call ShellExecute to run the installer or to open the archive, depending on your deployment style. The sample below shows a minimal call that will launch the default program for .zip files – usually WinZip or 7‑Zip.

If the updater must replace the running executable, it is safe to do so after the original process terminates. The demo includes a small helper that checks whether the application is ready to exit, raises an event that can be handled by the developer, and then calls Application.Terminate. Once the old instance shuts down, the installer runs and restarts the new version automatically.

Because the downloader component supports resuming interrupted transfers, you can pause the update, close the computer, and later pick up where you left off without losing progress. The library keeps a temporary file on disk and records the number of bytes already downloaded. When the next session starts, the component tells the server to send the remaining bytes and completes the file.

When everything is in place – the XML file on your site, the TclWebUpdate component in your code, and the Clever Downloader handling the network traffic – the user sees nothing but a friendly “Your application is up to date” dialog. If a new build is available, the updater fetches it quietly, applies the changes, and brings the user back to the main window with the latest features.

Getting Started with the Demo and Component

The entire solution is bundled in a few easy‑to‑download archives. The demo1src.zip) shows a simple single‑click update prompt. The second demo (demo1exe.zip and