[GH-ISSUE #39] iSH killed by iOS due to high CPU usage when installing app

kerem commented

2026-03-04 00:23:14 +03:00

Owner

Originally created by @ViRb3 on GitHub (Apr 9, 2021).
Original GitHub issue: https://github.com/SignTools/SignTools/issues/39

This only happens sometimes, likely with bigger files, and it could be attributed to either an out of memory error, or failure to emulate an instruction on ISH's side. More debugging is required.

Originally created by @ViRb3 on GitHub (Apr 9, 2021). Original GitHub issue: https://github.com/SignTools/SignTools/issues/39 This only happens sometimes, likely with bigger files, and it could be attributed to either an out of memory error, or failure to emulate an instruction on ISH's side. More debugging is required.

kerem

2026-03-04 00:23:14 +03:00

closed this issue
added the
bug

help wanted
labels

kerem commented

2026-03-04 00:23:16 +03:00

Author

Owner

@ViRb3 commented on GitHub (Apr 9, 2021):

To quote @42ism from #37:

My iSH setup is not that stable anyways to be used with the iOS Signer web service, for some strange reason it keeps crashing during the run (while installing the signed ipa file), I suspect it is an out-of-memory issue since the entire iSH crashes and then the ipa install fails. Thank you again for this great work!

it actually wasn't that large of a file 67 MB so I found it somewhat strange.

@ViRb3 commented on GitHub (Apr 9, 2021): To quote @42ism from #37: >My iSH setup is not that stable anyways to be used with the iOS Signer web service, for some strange reason it keeps crashing during the run (while installing the signed ipa file), I suspect it is an out-of-memory issue since the entire iSH crashes and then the ipa install fails. Thank you again for this great work! > it actually wasn't that large of a file 67 MB so I found it somewhat strange. > > ![image](https://user-images.githubusercontent.com/6178252/114190385-3f4a5400-9919-11eb-8a8d-e26d6faa0bea.png)

kerem commented

2026-03-04 00:23:16 +03:00

Author

Owner

@ViRb3 commented on GitHub (Apr 9, 2021):

@42ism can you please try this old version of the installation guide, which uses ngrok instead of cloudflared, and see if it changes anything? Note that step 3.1.2.1 will NOT work as it will install the most recent script. You'll need to use this command instead:

curl -sL https://raw.githubusercontent.com/SignTools/ios-signer-service/v2.1.8/install-ish.sh | sh

@ViRb3 commented on GitHub (Apr 9, 2021): @42ism can you please try [this old version](https://github.com/SignTools/ios-signer-service/blob/v2.1.8/INSTALL.md) of the installation guide, which uses ngrok instead of cloudflared, and see if it changes anything? Note that step `3.1.2.1` will NOT work as it will install the most recent script. You'll need to use this command instead: ```bash curl -sL https://raw.githubusercontent.com/SignTools/ios-signer-service/v2.1.8/install-ish.sh | sh ```

kerem commented

2026-03-04 00:23:16 +03:00

Author

Owner

@rzbergme commented on GitHub (Apr 9, 2021):

Oh wait, I just realized I wasn't reading it correctly and you asked me to use an older version. I will give it a try soon and report back. Thanks!

@rzbergme commented on GitHub (Apr 9, 2021): Oh wait, I just realized I wasn't reading it correctly and you asked me to use an older version. I will give it a try soon and report back. Thanks!

kerem commented

2026-03-04 00:23:16 +03:00

Author

Owner

@ViRb3 commented on GitHub (Apr 9, 2021):

I think I just figured out what the problem is. On your iOS device, if you go to Settings -> Privacy -> Analytics -> Analytics Data, you should see at least one iSH crash log. Open it up and check the content. Mine says the following:

Event:            cpu usage
Action taken:     Process killed
CPU:              48 seconds cpu time over 49 seconds (97% cpu average), exceeding limit of 80% cpu over 60 seconds
CPU limit:        48s
Limit duration:   60s
CPU used:         48s
CPU duration:     49s
Duration:         49.47s
Duration Sampled: 45.53s
Steps:            21

So the issue is Apple kills apps that use the CPU too much in the background. One way around this is keeping iSH in the foreground, but that's obviously not ideal. We should benchmark cloudflared, ngrok, and ios-signer-service itself, and see which one uses the CPU too much to optimize it.

@42ism can you please check what your logs say?

@ViRb3 commented on GitHub (Apr 9, 2021): I think I just figured out what the problem is. On your iOS device, if you go to Settings -> Privacy -> Analytics -> Analytics Data, you should see at least one iSH crash log. Open it up and check the content. Mine says the following: ``` Event: cpu usage Action taken: Process killed CPU: 48 seconds cpu time over 49 seconds (97% cpu average), exceeding limit of 80% cpu over 60 seconds CPU limit: 48s Limit duration: 60s CPU used: 48s CPU duration: 49s Duration: 49.47s Duration Sampled: 45.53s Steps: 21 ``` So the issue is Apple kills apps that use the CPU too much in the background. One way around this is keeping iSH in the foreground, but that's obviously not ideal. We should benchmark cloudflared, ngrok, and ios-signer-service itself, and see which one uses the CPU too much to optimize it. @42ism can you please check what your logs say?

kerem commented

2026-03-04 00:23:16 +03:00

Author

Owner

@rzbergme commented on GitHub (Apr 9, 2021):

@ViRb3 that is exactly right. I was about to update you that I tried both versions (older ngrok and cloudflared) and noticed that in both cases if iSH was in the background (e.g. me staring at the Github page waiting for CI to complete) it crashed and the Analytics data shows CPU usage for all these crashes. But if I stay on iSH patiently until the process completes (both for CI and during the install itself) then they complete successfully without iSH crashing.
I think it is pretty reasonable to keep iSH in the foreground (can be a note on the readme). Maybe the ios-signer-service can output the status (complete etc.) to the console so that the user can know it is safe to switch back to Safari?
At this point, I am tempted to set up the signer using docker on my Unraid server and not worry too much about signing locally using iSH but it is good to have options.

@rzbergme commented on GitHub (Apr 9, 2021): @ViRb3 that is exactly right. I was about to update you that I tried both versions (older ngrok and cloudflared) and noticed that in both cases if iSH was in the background (e.g. me staring at the Github page waiting for CI to complete) it crashed and the Analytics data shows CPU usage for all these crashes. But if I stay on iSH patiently until the process completes (both for CI and during the install itself) then they complete successfully without iSH crashing. I think it is pretty reasonable to keep iSH in the foreground (can be a note on the readme). Maybe the ios-signer-service can output the status (complete etc.) to the console so that the user can know it is safe to switch back to Safari? At this point, I am tempted to set up the signer using docker on my Unraid server and not worry too much about signing locally using iSH but it is good to have options.

kerem commented

2026-03-04 00:23:16 +03:00

Author

Owner

@ViRb3 commented on GitHub (Apr 9, 2021):

@42ism Do you only get the crashes when you are installing an app, not when uploading? I am attempting to sign a 281MB app, and it crashes in the last stage of uploading. I think what happens is that, because ngrok/cloudflared is used, the file gets slowly transferred to them first, and only when that's done then they push the content to the signer app. I suspect it is in this last stage that the CPU usage raises significantly for me, causing the crash. We could implement some form of CPU or transfer speed throttling to combat this, but I can't figure out exactly what is causing the CPU usage. I tried using top in iSH, but it doesn't seem to show accurate CPU usage. Do you have any ideas? Telling users to keep the app in the foreground will definitely work, but I want to investigate a bit more before committing to a solution.

@ViRb3 commented on GitHub (Apr 9, 2021): @42ism Do you only get the crashes when you are installing an app, not when uploading? I am attempting to sign a 281MB app, and it crashes in the last stage of uploading. I think what happens is that, because ngrok/cloudflared is used, the file gets slowly transferred to them first, and only when that's done then they push the content to the signer app. I suspect it is in this last stage that the CPU usage raises significantly for me, causing the crash. We could implement some form of CPU or transfer speed throttling to combat this, but I can't figure out exactly what is causing the CPU usage. I tried using `top` in iSH, but it doesn't seem to show accurate CPU usage. Do you have any ideas? Telling users to keep the app in the foreground will definitely work, but I want to investigate a bit more before committing to a solution.

kerem commented

2026-03-04 00:23:16 +03:00

Author

Owner

@rzbergme commented on GitHub (Apr 9, 2021):

As far as I know, I got the crashes while uploading (before CI started) as well as during the install. But I admit that I did not conduct clean tests, it is more of an anecdotal observation. I can try it again over the weekend and report back.

@rzbergme commented on GitHub (Apr 9, 2021): As far as I know, I got the crashes while uploading (before CI started) as well as during the install. But I admit that I did not conduct clean tests, it is more of an anecdotal observation. I can try it again over the weekend and report back.

kerem commented

2026-03-04 00:23:16 +03:00

Author

Owner

@ViRb3 commented on GitHub (Apr 9, 2021):

This would confirm my behavior, so it makes sense. I will do some more tests and reply here when I decide how to tackle the problem.

@ViRb3 commented on GitHub (Apr 9, 2021): This would confirm my behavior, so it makes sense. I will do some more tests and reply here when I decide how to tackle the problem.

kerem commented

2026-03-04 00:23:16 +03:00

Author

Owner

@ViRb3 commented on GitHub (Apr 9, 2021):

I sort of addressed this in v2.2.3 - logs are now much easier to read, and I added a notice in the installation instructions. This is only a temporary workaround, though, so I will leave this issue open until we find a better solution.

@ViRb3 commented on GitHub (Apr 9, 2021): I sort of addressed this in v2.2.3 - logs are now much easier to read, and I added a notice in the installation instructions. This is only a temporary workaround, though, so I will leave this issue open until we find a better solution.

kerem commented

2026-03-04 00:23:16 +03:00

Author

Owner

@rzbergme commented on GitHub (Apr 10, 2021):

I like the new formatted output. are the logs saved somewhere? I don't see a log in the iSH folders.

@rzbergme commented on GitHub (Apr 10, 2021): I like the new formatted output. are the logs saved somewhere? I don't see a log in the iSH folders.

kerem commented

2026-03-04 00:23:16 +03:00

Author

Owner

@ViRb3 commented on GitHub (Apr 10, 2021):

It's not being saved anywhere, no. You can always pipe the output to a file. If you have a specific use case feel free to open a new issue.

@ViRb3 commented on GitHub (Apr 10, 2021): It's not being saved anywhere, no. You can always pipe the output to a file. If you have a specific use case feel free to open a new issue.

kerem commented

2026-03-04 00:23:16 +03:00

Author

Owner

@ViRb3 commented on GitHub (Jun 2, 2022):

Closing since this is no longer a supported use case. Please use Heroku or self-host instead.

@ViRb3 commented on GitHub (Jun 2, 2022): Closing since this is no longer a supported use case. Please use Heroku or self-host instead.

Rows
Columns

[GH-ISSUE #39] iSH killed by iOS due to high CPU usage when installing app #27