Hello Forum! We recently received an email regarding using the "Latest Code Signature Format" from Apple for our Enterprise apps. The email / article states the following: https://developer.apple.com/documentation/xcode/using_the_latest_code_signature_format?language=objc "In a future release, the new format will become mandatory, and the system won’t launch apps with the old signature format." We have many Enterprise apps that are being used by legacy users. The top brass wants to know if there is an actual estimate on exactly when these apps will stop launching. For example, will it stop working in iOS 15, or would it more likely be in iOS 16? The answer to that question will determine whether we continue to support the legacy app, or upgrade them all to the latest version in an emergency update. Also, I see that if I simply download one of the .ipa files from our distribution page, run the script to re-sign the app in Catalina, and then upload it back to our distribution page, the app functions perfectly. Is this all that we will need to do to take care of this requirement, assuming that upgrading the codebase is not a viable option? Thanks!

Good Morning Everyone!I am experiencing a strange phenomenon with my app.Context:My app needs to work completely offline. As a result, it needs to download massive amounts of data, as well as hundreds of thousands of images during the initial sync.Once this content is downloaded the first time, the app performs delta updates, so only the first sync takes a long time (~6 hours).The syncing is handled across many threads, each managed by NSOperationQueues and/or NSURLSession tasks.The Problem:The problem I keep running into is that after ~20 minutes of syncing the first time, the app crashes. The only report I can access from the device logs state that I am using too much CPU.Specifically, the log I get is "exceeding limit of 50% cpu over 180 seconds."The environment varies, but usually the app is running on an iPad Pro (various gens) running iOS 12 or iOS 13.I am not 100% sure that this is a crash log and not simply an energy log, but the timing of receiving this message and the app crashing is too correlated to not be related.Bottom Line:Bottom line my question is this: will iOS kill my app for high CPU usage IN THE FOREGROUND? And if so, is there a way to either disable that, or appeal for a higher CPU usage limit?I am aware that high CPU usage will get my app killed in the background, but mine is getting killed in the foreground repeatedly and consistently, whilst performing user-initiated work!Strangely, my 2016 iPad Pro (1st gen 9.7"), running iOS 12, has not crashed at all! I'm not sure if this is a new limiter added in the newer hardware, or something added in iOS 13, or what. But my 2016 device has no problems with my app syncing!I have tried to analyze the usage with Instruments, but physics is physics, I simply have so much content that I need to be using multiple threads to sync.I am using between 10 and 20 threads to manage all of my syncing, broken up by content type.I'm really at the end of my rope on this one. I have tried all the usual tricks:Implement NSURLSessionsImplement NSOperationQueuesPerform the sync in batchesBetween each batch, put the threads to sleep to allow the system to reallocate resources.I don't know what else to try and am hoping someone here has a new trick to teach me!Any help is greatly appreciated!Thanks,~ArashEDIT 1 (08 OCT 2019 1325 EST):I thought it worth clarifying that I have run the app with instruments and do not see unbounded memory usage, leaks, or zombies while the app is syncing.While I do see the CPU is being used heavily (90%), this makes sense, as my app is performing foreground work and trying to do it as fast as possible on behalf of the user.There are also no other crash logs from the devices relating to my app.EDIT 2 (09 OCT 2019 1000):It seems I have found a way to cure the CPU usage.The way that my NSOperationQueue operations work is by firing up an NSURLSession task, and then using an NSCondition to wait for the task's asyncronous completion handler to fire.In the completion handler for the task, if I call [NSThread sleepForTimeInterval:0.025], the CPU usage drops from being well above 100% (in some cases even above 200%) on the simulator, to being ~30%.While this does keep the CPU usage low, it significantly reduces the speed with which the app is able to download it's content.Another workaround, which I admit is not ideal, is to let the original process go at full bore, and simply set up a timer to suspend the queue every 2 minutes for 5 seconds. Using this approach, the CPU is NOT being used above 50% for 180 seconds, as the Duet CPU Activity Scheduler complains about, because the tasks never holds the CPU for more than 2 minutes. This works, but could be a moving target if Apple decides to change the limiter values.I'm thinking that the better solution would be to use synchronous download tasks, and avoid using the NSCondition all together.Anyway, hope this info helps someone!Thanks,~Arash