Universal apps launch VERY slowly

[Willem Jan Drijfhout]

@Patrick Connor, any update on this? This post is again a month old. The duplicating app work around has worked for a while, but not anymore (related to an automatic Affinity and/or Big Sur update?). It is very frustrating to see that still after all these months Serif does not seem to be able or willing to fix a very annoying issue for its users. That fact is even more frustrating than the slow opening. Oh, and the Affinity apps are the only ones having this problem. All other apps have seen a smooth transition to Big Sur/unified apps. 

[Patrick Connor]

8 minutes ago, Willem Jan Drijfhout said:

The duplicating app work around has worked for a while, but not anymore (related to an automatic Affinity and/or Big Sur update?)

As you can see if duplicating the app makes it work for a while and then stop working (probably when Big Sur updated) it can be seen that this is being caused by the OS security features. I do not see what you think Serif should fix, when nothing has changed in our code between a your copy being faster and it slowing down again. Clearly it can start fast.

I accept that we have not seen other applications that do this why is a mystery. Affinity does use some cutting edge features of Big Sur that perhaps are the ones triggering the security level checking, so it is perhaps less surprising that other apps are not affected in the same way if that is the cause. We really do expect Apple to address this and as you can imagine we are frustrated ourselves that this persists despite Big Sur updates. I will ask the developers again if they have heard back from Apple about this.

[Willem Jan Drijfhout]

I'm sorry Patrick, but you're doing it again. You put the blame on Apple, don't acknowledge this is something Serif should fix and even suggest something along the line of 'Affinity is such advanced software that even Apple can't catch up'. 

And all of this because of a perfectly reasonable request to get an update after four months on a very annoying bug in your software that is acknowledged by your own engineering team.

As an FYI, I also posted the request for an update in the other thread that discusses this problem, so you may want to have a look there as well to ensure everyone is updated that it is everyone's problem and not Serif's.

Since it is clear that this is my problem to solve, I will subscribe to Adobe Photoshop now. A pity, as I really liked the new astrophotography functionality in AP 1.9. 

 

 

[Patrick Connor]

So here it is from Devs and Apple, hot off the press.

Big Sur applications are security checked by YaraScanService (Yara Malware Scan) . From profiling our machines we can see that is what is running to cause the slow first run. This is a standard part of the Operating System and completely out of our control.

All applications are scanned on first run and the information is cached in memory so it will be faster for each subsequent run. For extra security this is not written away so after a restart the scan is done again. Affinity apps have a very large executable (not just the package size, the executable code inside it) and that may be why we are slower than other applications (still waiting on a reply about that). The fact the work around seemed to avoid this test was probably a bug and seems to have been addressed in a Big Sur update, which makes sense but is super annoying for us. We will look again at whether there is anything about our executable that could be broken up or built differently, as although we have submitted a Radar report to Apple, it would likely only result in a progress bar rather then a change of approach to their security level. The annoying thing is that all Serif apps are notarized (a formal process for developers) and this should be enough to trust them. We will do whatever Apple says will help, as there do seem to be other big apps out there that do not have this.

It is a perfectly reasonable request for us to keep looking at it, but you are replying like we are not looking at it, we absolutely are at the highest level in Serif, trying things, profiling and communication all that to Apple. 

[Willem Jan Drijfhout]

Thank you @Patrick Connor for this response. This helps a great deal of understanding what is going on and fits the experiences exactly. So the conclusion is that there is something in the Affinity apps, which is different than other apps which causes this behaviour in response to stringent Apple security measures.

It keeps me wondering what would have happened if your first response would have been: 'you're right we're another month into it, still no solution, and workaround stopped working. Let me check with engineering', to come back a little later with the response above.  Probably the difference between a happy client and an unhappy client. Customer support is all about communication.

[Patrick Connor]

24 minutes ago, Willem Jan Drijfhout said:

So the conclusion is that there is something in the Affinity apps, which is different than other apps which causes this behaviour in response to stringent Apple security measures

We think so. I hope we can work out what or they can just tell us. It is absolutely under investigation.

 

25 minutes ago, Willem Jan Drijfhout said:

Customer support is all about communication

Sure, sorry but to be honest Apple only just picked up our support ticket from back then to until very recently there was not much more to say, and we have been releasing the 1.9.1 update and 1.9.2 betas too

[Patrick Connor]

Readers,

From a number of reports it seems the work around of making a copy of your application may have been "blocked" from working by a recent macOS update. If so it's no longer a suitable work-around. Frankly it was surprising that making a copy worked anyway, and if Apple have spotted the mistake and blocked it then that would seem logical, as all applications should be security checked.

We are working with Apple on this and having another look at why they are treating our application in a way as to not trust it each time the application is started after the machine restarts. We hope we have a possible solution and will try it internally. Rest assured we are working hard on solving this problem. 

[Ighor]

On 3/12/2021 at 11:46 AM, Patrick Connor said:

So here it is from Devs and Apple, hot off the press.

Big Sur applications are security checked by YaraScanService (Yara Malware Scan) . From profiling our machines we can see that is what is running to cause the slow first run. This is a standard part of the Operating System and completely out of our control.

All applications are scanned on first run and the information is cached in memory so it will be faster for each subsequent run. For extra security this is not written away so after a restart the scan is done again. Affinity apps have a very large executable (not just the package size, the executable code inside it) and that may be why we are slower than other applications (still waiting on a reply about that). The fact the work around seemed to avoid this test was probably a bug and seems to have been addressed in a Big Sur update, which makes sense but is super annoying for us. We will look again at whether there is anything about our executable that could be broken up or built differently, as although we have submitted a Radar report to Apple, it would likely only result in a progress bar rather then a change of approach to their security level. The annoying thing is that all Serif apps are notarized (a formal process for developers) and this should be enough to trust them. We will do whatever Apple says will help, as there do seem to be other big apps out there that do not have this.

It is a perfectly reasonable request for us to keep looking at it, but you are replying like we are not looking at it, we absolutely are at the highest level in Serif, trying things, profiling and communication all that to Apple. 

It is not only delay on first run. It is happening every time if app closed for a few hours. I'm never restarting MacBook unless macOS updates released.

So if you start Affinity Photo once per day, you always get the delay.

According to Apple the delay should be only first time after any app update, right? But it is not happening that way, so maybe there is something they missed and could fix.

I am waiting a fix for that for a 5 months already. I was happy to use Affinity Photo only for first 1 month, since I bought it 6 months ago.

 

[Willem Jan Drijfhout]

The behaviour you describe @Ighor is what most people experience. Only if you open/reopen the app in short succession (i.e. within 10-15 mins), it starts quickly. Any other time it will be a slow start. So if you open the app 10 times a day, you will probably experience the problem 10 times a day.

As per earlier communication the issue appears to be the unusually large executable code that Affinity Photo is built on. I'm not a software engineer, but if that's the case, I would not be surprised if a solution would still be a long way away....

[Ighor]

3 hours ago, Willem Jan Drijfhout said:

The behaviour you describe @Ighor is what most people experience. Only if you open/reopen the app in short succession (i.e. within 10-15 mins), it starts quickly. Any other time it will be a slow start. So if you open the app 10 times a day, you will probably experience the problem 10 times a day.

As per earlier communication the issue appears to be the unusually large executable code that Affinity Photo is built on. I'm not a software engineer, but if that's the case, I would not be surprised if a solution would still be a long way away....

Yes, I understand, but it is something what is really hard to believe. Just look at this:

iMovie                -    2.78 Gb    -    35954 files        -    start time    16 seconds
Affinity Photo    -    2.5 Gb      -    10785 files        -    start time    ~3 minutes

[ianhg]

On 3/12/2021 at 3:34 PM, Patrick Connor said:

Readers,

From a number of reports it seems the work around of making a copy of your application may have been "blocked" from working by a recent macOS update. If so it's no longer a suitable work-around. Frankly it was surprising that making a copy worked anyway, and if Apple have spotted the mistake and blocked it then that would seem logical, as all applications should be security checked.

We are working with Apple on this and having another look at why they are treating our application in a way as to not trust it each time the application is started after the machine restarts. We hope we have a possible solution and will try it internally. Rest assured we are working hard on solving this problem. 

From memory it all seemed to start being an issue when you made your apps open on Apple M1 and Big Sur seemed to make it slow again. I tried adding the apps to system preferences >User Groups>Login items and this didn't slow the actual start up on my iMac but the all three AF apps bounced about 30 times before starting. 

[loukash]

On 4/8/2021 at 9:03 PM, Ighor said:

Just look at this:

iMovie                -    2.78 Gb    -    35954 files        -    start time    16 seconds
Affinity Photo    -    2.5 Gb      -    10785 files        -    start time    ~3 minutes

Package size and file count isn't everything.

• iMovie is a Mac only app, built by Apple and heavily relying on built-in MacOS frameworks.
• Affinity apps are being developed as multi-platform, thus built and structured differently so that the underlying code can be shared with their Windows versions. (Not that I'd personally think this is a Good Thing™ in terms of Mac usability experience, but there you go. It's ultimately a business decision on Serif's part.)

In other words, it is literally comparing Apples with Oranges.

[Ighor]

4 minutes ago, loukash said:

Package size and file count isn't everything.

It is directly related to a processing time of calculating hash (Reading all app contents) and verify signature of files (Apple security measures).

Or do you think there is some magic behind of it? Yes I think there is no magic also, and possibly there is other reasons of slow delay, since calculating signatures can't take so long time.

[Patrick Connor]

My latest post on this topic can be found here, which adds to understanding, but unfortunately not a solution yet.