Why do I have to download upgrades externally for Designer and photo?

[dhayfule]

Hi,

Unlike other applications Affinity does not have upgrades internal to application. It asks to download a 400MB + sized application and then upgrade. Why cannot the application run internal upgrades instead of making user explicitly download a heavy file and then manually upgrade?

[GarryP]

Welcome to the forums @dhayfule
My guess is that this is at least partly due to the numerous difficulties in providing delta updates for three applications – Designer, Photo and Publisher – on three operating systems – Windows, OS X and iOS – with three distribution methods – Apple Store, Microsoft Store and Serif Store. (Publisher isn’t on iOS yet but I think it will probably come in time.)
Maybe someone who has published complex software on multiple platforms in the way you suggest can give more detailed information on this.

[R C-R]

I think @dhayfule is asking about what are usually referred to as "Delta updates" or just as "deltas" for short. (Upgrades usually involve large changes to the software so they usually are not distributed as deltas.)

As for why Serif does not offer them, my guess is because as Garry alluded to it is not easy to create a delta installer that actually significantly reduces the download size, does not inadvertently omit any files that have changed (including files where the only differences are in references to other files), & to do so correctly for each OS & store version.

This is a lot more complicated than it might seem. For example, in the Mac version of Designer as installed the liblibpersona.dylib file (what Apple calls a Mach-O dynamic library) is by itself almost 900 MB. Since that file might change in any update, even if the changes are tiny either a compressed version of the whole thing must be included in the delta, or some method included in the delta installer to apply those changes as patches to the existing file plus a method to determine which patches must be applied to what could be any of several different previously installed versions of the app.

Basically, it is much harder to make sure a delta update installer gets everything right & can properly update any prior version of the app than to replace the existing version with the new version in its entirety.

[Blende21]

You install the main program, version 1.2.3. Your OS is at a release state 10.17.2.

You work happily. OS Updates are coming, you install. Now you are at OS stat 10.18.1. You decide to skip the next OS releases. OS could be 10.18.6 now, but it doesn’t create problems for you to continue without.

A delta update of your favorite program is offered, to make it to version 1.2.4. You install. The delta update has a hard time, because it needs to find out in which environment to run the delta installer. It tries it’s best ...

Your emotional status changes to completely unhappy - you can’t work.

You try things: Upgrade the OS, uninstall and reinstall the app (Full install), search for your license key, somehow get to install your resources that got lost in the process ... hours of lifetime and billable hours lost to this IT garble.

And all this to save a few MB on the download of an upgrade ?

I am happy to get full updates that will install without tricking around. Mostly I wait a little after release before installing. I rarely have „issues“ ...

[v_kyr]

22 hours ago, dhayfule said:

Unlike other applications Affinity does not have upgrades internal to application. It asks to download a 400MB + sized application and then upgrade. Why cannot the application run internal upgrades instead of making user explicitly download a heavy file and then manually upgrade?

I recall that certain Affinity beta versions once had (maybe they still offer so) and offered an app internally update mechanism (binary diff/patch related) which reduced the overall download transfer in contrast to full version installments. There are a bunch of binary patch tools which allow to build an app internal specific update mechanism, also in a cross-platform manner. A bunch of cross-platform dev software I daily use has build-in update & version patch mechanisms, beside the seperate usual full version installer downloads.

Some good cross-platform working app examples here for those update things are, Firefox, Chrome, IntelliJ, VS Code ... etc.

[Alfred]

1 hour ago, v_kyr said:

I recall that certain Affinity beta versions once had (maybe they still offer so) and offered an app internally update mechanism (binary diff/patch related)

I wonder whether that was a Mac thing. There certainly wasn’t a patching mechanism for the Windows public betas.

Serif’s Windows-only ‘legacy’ applications all had update patches.

[R C-R]

3 hours ago, v_kyr said:

There are a bunch of binary patch tools which allow to build an app internal specific update mechanism, also in a cross-platform manner.

As I understand it, even though these tools are 'cross-platform' they still require developers to build different update installers for different platforms, & to build into their apps some mechanism to determine what specifically should be downloaded & installed to update the currently installed version to the newest one.

They may elect to build more than one version, the smallest 'delta' ones containing only the changes made since the last update & larger 'combo' ones capable of updating any older version. Ideally, there should be built-in 'sanity checks' sufficient to make sure all the files to be patched are uncorrupted & otherwise unchanged from the originally installed version, & fallback mechanisms to install replacement files if they are not.

Obviously, these installers should conform to whatever security requirements are enforced by the OS, which may be different depending not just on which platform they are designed for but also depending on the installed OS version. There may be additional restrictions imposed depending on the store the app was purchased from.

It all sounds like a lot of work to me, tools or no tools.

[v_kyr]

1 minute ago, R C-R said:

As I understand it, even though these tools are 'cross-platform' they still require developers to build different update installers for different platforms, & to build into their apps some mechanism to determine what specifically should be downloaded & installed to update the currently installed version to the newest one.

Tools like InstallAnywhere etc. are made exactly for such purposes, they offer the whole bandwidth of installer based features and functionality (release and patch design etc.).  Further every serious evolutionary software development keeps track of version numbers, UIDs, hashcodes etc. together with version control systems, which in turn know what has been changed since the last release or update branches. The later are nowadays are also coupled with automatic build and deployment processes. - Thus a software knows which version numbers it has and if those are lower or higher in diff to other version numbers.

All that is common usage in software dev. Thus if other software (and their dev teams) can handle that, Affinity can generally too.

Work? - Show me something in software development that has nothing to do with work. Nothing does by itself, finally that's what devs and sys admins are for and why they are paid for their daily work!

 

[R C-R]

3 hours ago, v_kyr said:

Tools like InstallAnywhere etc. are made exactly for such purposes, they offer the whole bandwidth of installer based features and functionality (release and patch design etc.). 

Maybe so, but according to the website it allow developers to track who downloads their updates, which sounds like it would not be suitable for updates distributed through either of Apple's stores. Know anything about that?

[v_kyr]

8 minutes ago, R C-R said:

Maybe so, but according to the website it allow developers to track who downloads their updates, which sounds like it would not be suitable for updates distributed through either of Apple's stores. Know anything about that?

Their tools offer a range of options and settings that allow you to enable or disable certain features you want, so you can customize installers to behave as you want and to comply with Apple's guidelines and policies. For further informations read the InstallAnywhere docus, FAQs and HowTo samples etc. - Their latest versions also support Mac OS X Notarization etc.

Quote

Mac OS X Notarization

Starting in macOS 10.14.5, all new or updated kernel extensions and all products from developers new to dispersing with Developer ID must be notarized so as to run. Starting in macOS 10.15, by default, the notarization is required for all products.

Notarization likewise ensures your users if your Developer ID signing key is uncovered. The notary service keeps up a review trail of the product appropriated utilizing your signing key.

In InstallAnywhere 2020, you can automatically notarize your application with ease. InstallAnywhere now supports notarizing macOS or OS X–based installers with a Developer ID Application certificate during the build time.

The process of notarizing your authentication wrappers, your installers, and your uninstallers varies, depending on whether you are performing the notarizing step at build time on the InstallAnywhere build machine or on a separate designated notarization machine.

You can specify whether and how you want InstallAnywhere to notarize your OS X–based installer at build time. If you notarize the installer, end users can download your installer from outside the Mac App Store and install the product without being blocked by the Gatekeeper. The App Notarization settings in this area are:

• Notarize the Generated Installer

• Developer Username

• Developer App Specific Password

• Notarization Response Timeout (min)

Mac Authentication Compliance - Installers created with InstallAnywhere 2020 conform to the standards for Mac authentication.

...
...

 

[R C-R]

4 minutes ago, v_kyr said:

"If you notarize the installer, end users can download your installer from outside the Mac App Store and install the product without being blocked by the Gatekeeper."

It sounds like they are saying that if you use their or a separate designated machine to build the installer it won't be blocked by Gatekeeper, but only for apps that are not purchased through the MAS.

AFAIK, Apple only permits its own App Store app to update MAS purchases.

[Blende21]

Personally I prefer to run apps from direct installs than from the AppStore.

I have encountered problems in the past with an AppStore version that was identical (at least from the release number Including the build) to the direct install. But since It came from the AppStore it always executed in a sandbox, which caused problems. When I installed directly, the problems were gone, and it is smoothly working since.

We will have to see when the switch to Apple silicon happens whether this will still be an option. But when installing directly, it is better to always make a full (re-)install than try to do it incrementally.

[R C-R]

12 minutes ago, Blende21 said:

But since It came from the AppStore it always executed in a sandbox, which caused problems.

What kind of problems have you had, & with what MAS apps?

[v_kyr]

52 minutes ago, R C-R said:

It sounds like they are saying that if you use their or a separate designated machine to build the installer it won't be blocked by Gatekeeper, but only for apps that are not purchased through the MAS.

AFAIK, Apple only permits its own App Store app to update MAS purchases.

They described there the mechanisms for code signing macOS or OS X–based installers, aka signed Installers which allow to be directly used on the OS without being purchased/downloaded from MAS. - Either way you always need actual Xcode IDE versions and all of its default SDKs for code signing (no matter if using InstallEverywhere or not, they are always needed). And the Apple dev tools do offer everything needed for creating and signing App Store sandboxed apps.

• Requirements for Code-Signing Support for macOS or OS X–Based Installers

• Code Signing Your macOS or OS X–Based Installers and Including Authentication Support

• ... and so on (check their docs).

Even more interesting than to build some seperate Installers is, how to hook an update mechanism in a well behaving/graceful manner inside an app, so an app can recognize, download and update itself when needed, or on demand. Personally I like the way Firefox and IntelliJ do handle that across platforms.

 

 

[R C-R]

5 minutes ago, v_kyr said:

They described there the mechanisms for code signing macOS or OS X–based installers, aka signed Installers which allow to be directly used on the OS without being purchased/downloaded from MAS.

But that is nothing new or unique to the InstallAnywhere or similar apps, right?

Either way, I don't see anything that suggests that if an app is purchased through the MAS it can be updated through any other mechanism than through the MAS. Considering how many Affinity apps have been MAS purchases, maybe this is why Serif has elected not to provide patch updates across the board?

[v_kyr]

1 hour ago, R C-R said:

But that is nothing new or unique to the InstallAnywhere or similar apps, right?

There aren't much cross-plattform Installer tools, especially not for various platforms and among those then MacOS too.

1 hour ago, R C-R said:

Either way, I don't see anything that suggests that if an app is purchased through the MAS it can be updated through any other mechanism than through the MAS.

I believe that would be a MAS violation then from Apple's point of view, if you were to skip their AppStore mechanisms then for updates from an initial MAS app. Probably your app will then be banned from MAS, or you will loose your dev status there (all in all in a similar fashion as Apple blocked Epic Games' developer account on Friday after the previous dispute over the 30 percent levy in Fortnite etc.). Apple has a strong dictatorship there, once bound, always bound to it, all according to their own strict rules.

So the whole is more interesting for none MAS bound but still legally signed MacOS versions. So software versions, which don't have to be distributed and strictly bought via the MAS. Pretty much of how it's handled in the Win world, either buy from the respective software company or the MS Win Store etc.

[dhayfule]

Hi folks, 

Thanks. I got it. BTW all the discussion seem to be around Mac OS. I forgot to mention that I am using Windows 10 OS

Regards

[v_kyr]

28 minutes ago, dhayfule said:

BTW all the discussion seem to be around Mac OS. I forgot to mention that I am using Windows 10 OS

On Win there are quite more possibilities and tools for such things (Installer generators, Update managers etc.) available. It's overall not as much restricted as MacOS in this regard.

[Blende21]

9 hours ago, R C-R said:

What kind of problems have you had, & with what MAS apps?

Issues with Evernote, editing with other apps using the „Open with“, when saving back, syncing problems. It stopped when I completely uninstalled using AppCleaner, and reinstalled the direct install from the web site. It was completely identical to the version from the AppStore, but does not run in a sandbox.

When I tried to find out what was going on before, the only difference was the sandbox mode you inherit when installing from the AppStore. Regarding EN this was confirmed by their support. Since then I try to install directly. To make administration easier, I use MacUpdate for an automatic search for updates.

[Jowday]

Only an answer from Serif would make sense here.