1. It does not break the apps signature as we patch the signature files as well. After the update, the application is correctly signed. I personally don't like to re-download the entire application any time there is a minor update. How many times was I disapointed that I can't install a new version of app to my iPhone without Wi-Fi cause it was over 100MB although there were just minor changes.
2. I work for Avast so I have the insights. I am asking someone from Apple, to provide documentation on how the enhanced runtime and notarization actually work together. When does the gatekeeper come into play? When is the notarization stamp checked? Does the system hold the notarization info somewhere in the system after the package was installed or is it just attached to the .pkg/.dmg and used during installation and then never again? There is documentation on how to notarize things, but the interactions during the apps lifetime are not properly documented. Maybe I just wasn't able to find it. Right now it seems, that a notarized application can load a library that has not been notarized but is signed by the same developer. This is in complience with the TechTalk on WWDC 2018. I want to make sure that this will continue to work in the upcomming version of macOS. Notarization process is said to take "up to an hour" and delaying an antivirus definitions update for an hour might be a long time when there is a new aggressive virus we need to catch.
For your claim that AV companies are slow to react to Apple changes. It is because we support our users also on 10.9 systems with program updates and 10.6 systems with virus definitions. We need to be able to work/debug on these systems as well. It is about 10% of our userbase. They are not "source of revenue" as you called it, but we do our job primarily for the people and their online safety. The status of development tools does not help us here. Xcode 10 does not allow us to build Swift 3 code and Swift 4 aware Xcode can't be installed on older systems. That makes it impossible to transition to latest Xcodes + SDKs + Swift as it would be very difficult/impossible to debug any issues on older versions of OS without the tools. Furthermore, most new features Apple introduces are not properly documented. There is a documentation for some simple use cases, but for really complex SW it takes a lot of experimenting to figure out how things realy work together and we are never sure, whether it will not change with newer versions of macOS. Thats why we tend to stick to things that have been working for a long time and seem to be stable.
FYI we were wondering why some users stay on older systems, and most of the times it is because they are using some software, that is no longer working on the newer versions of macOS, but they want to keep using it.
3. Since the notarization was introduced, I was trying to talk to guys in Apple to explain our use case and figure out, what is the correct replacement in case this will stop working. I doubt we are the only company that is providing customized installers to their users. It really simplifies and improves user experience and that is something Apple always had in mind. If the only way will be to re-notarize the dmg, we will have no other option then to spam notarization servers with thousands of notirazation requests with the same binaries but slightly different data inside a .dmg. I do not see any point in doing that. The .pkg is notarized and unchanged and all executable code is inside the .pkg. All we are changing is some textual data inside the .dmg. If there is a plan to disable this option, please reconsider it or design and describe a flow that would allow installer customization.
Best regards,
Jakub