Auto-update of native application bundles

[Rick Walker]

Auto-Updater Feedback / Wishlist:

We are keenly interested in the auto-updater and we greatly appreciate the
efforts of all, especially Igor and Daniel. We anticipate posting app
updates on a tight cycle – a week or two will be routine. So a clean,
reliable auto-updater will make our users’ lives vastly simpler.

Our app will require the user to log in and authenticate before launching
the auto-updater. We would prefer to zip up our latest app jars and post to
a predetermined location on our server. If the JRE does not change with an
update, the updater should ignore it and retrieve only our app jars and/or
updated T&C (see below).

Regarding jar signing, we expect to retrieve our app jars from our server.
Even though we generally sign jars, we do not imagine performing a
jar-signing check with each auto-update.

We want to be able to tightly control auto-updates - we may ask users to
pay for some updates. We are concerned that, by placing our jars at a url
accessible to the auto-updater, we might also be inadvertently exposing
them to anyone who might point a browser at the same url. Adding some level
of indirection might help.

Regarding updates to Terms and Conditions or EULA, it would be a great
advantage to post an RTF (perhaps with a version number included in the
file name) alongside our updated app jars so that the updater could
determine whether the user ought to view and agree to the new T&C.

I believe we include an RTF on the installer side (with NSIS or Inno) so
it’s no extra work to also post it for the updater. We also routinely post
updated T&C on our website, so I suppose a simple alternative might be for
the auto-updater to simply point to that url.

>From our perspective, it seems there are three components in play for the
updater, each separately tracked for current version: the JRE, our app
jars, and the T&C.

Regarding user notification, we plan to use auto-updating to make sure that
all users are using the same version of our app – just as if we deployed as
an applet. User notification can therefore be bare bones – “a required
update is now available’.  A "what's changed" document isn't required in
our case.

The download display can be modal – there is no need for the download to
take place in the background.  An incremental progress indicator would be
nicer than an indeterminate display.

Graceful recovery in the event of a failure state (stalled download, file
i/o probs etc) is of course essential.

Cheers to all,
Rick