3 Replies
      Latest reply on Jan 14, 2019 7:23 AM by Sega-Zero
      gg0512 Level 1 Level 1 (0 points)

        Hello,

         

        I am trying to submit my app to TestFlight. But the build didn't pass the tests. ITunes Connect rejected my build. The reason is "Binary Rejected: Guideline 2.1 - Performance - App Completeness We were unable to review your app as it crashed on launch. We have attached detailed crash"

         

        The app works well on my device as an internal tester (via TestFlight).

         

        I precise that I used Xamarin.iOS to develop the app.

         

        I have some difficulties to find the source of the problem, can you help me? Here is the crash log:

        https://pastebin.com/HyTLXiAY

         

        Thanks in advance for your help!

         

        Jérôme

        • Re: ITunes Connect - Crash report - Code 0x8badf00d
          eskimo Apple Staff Apple Staff (10,875 points)

          The 0x8badf00d (“ate bad food”) exception code means that your app was killed by the watchdog for being insufficiently responsive.  You can learn more about this in Technote 2151 Understanding and Analyzing iOS Application Crash Reports.

          To debug this you should look at two items in the crash log:

          • The backtrace of the main thread

          • The Termination Description field

          The backtrace of the main thread indicates that your app was blocked accessing the keychain when it was killed.  It’s possible that this blocking is the cause of your problem, but I don’t think that’s the case here.

          And that’s because of the Termination Description field, which looks like this (I’ve broken it up into multiple lines to make it easier to read):

          Termination Description: 
          SPRINGBOARD, 
          scene-create watchdog transgression: com.XandJsoft.MyFamily 
          exhausted real (wall clock) time allowance of 19.69 seconds |  
          | ProcessVisibility: Foreground 
          | ProcessState: Running 
          | WatchdogEvent: scene-create 
          | WatchdogVisibility: Foreground 
          | WatchdogCPUStatistics: ( 
          | "Elapsed total CPU time (seconds): 16.920 (user 16.920, system 0.000), 28% CPU", 
          | "Elapsed application CPU time (seconds): 0.437, 1% CPU" 
          | )

          Line 4 indicates that your app was given (roughly) 20 seconds to launch.  Now look at line 10, which indicates that your app spend roughly 17 seconds of that doing computation on the CPU.  That’s a big chunk of time, and I’d argue it’s way too long for a couple of reasons:

          • It skirts very close to the watchdog limit of 20 seconds

          • You’re making the user wait way too long

          My recommendation here is that you look at ways to optimise your launch time.

          Share and Enjoy

          Quinn “The Eskimo!”
          Apple Developer Relations, Developer Technical Support, Core OS/Hardware
          let myEmail = "eskimo" + "1" + "@apple.com"

            • Re: ITunes Connect - Crash report - Code 0x8badf00d
              gg0512 Level 1 Level 1 (0 points)

              Indeed, my applicationDidFinishLaunching method was a bit overloaded. It has been accepted now.


              Thanks you for your help.

              • Re: ITunes Connect - Crash report - Code 0x8badf00d
                Sega-Zero Level 1 Level 1 (0 points)

                @eskimo, struggling almost the same thing, but the reason is really suprising for me:

                 

                Termination Description: SPRINGBOARD, scene-create watchdog transgression: com.app.id exhausted CPU time allowance of 2.97 seconds | 
                ProcessVisibility: Background | 
                ProcessState: Running | 
                WatchdogEvent: scene-create | 
                WatchdogVisibility: Background | 
                WatchdogCPUStatistics: ( | "Elapsed total CPU time (seconds): 15.300 (user 15.300, system 0.000), 62% CPU", | "Elapsed application CPU time (seconds): 5.126, 21% CPU" | )
                Triggered by Thread:  0

                exceeded 3 seconds of CPU consumption?

                 

                Having this in a very rare cases, when receiving voip push that laucnhes the app in background. And, according to logs, I have an infinite (DBL_MAX) amount of background time available, but the app is killed by the watchdog 3 seconds after applicationDidFinishLaunching.

                What may be the reason of that short period of time available to the app before being killed by watchdog?

                 

                I would assume it's the pre-main time loading time, but according to our tests, this happens after a several laucnhes happened already, so the libraries should be cached already. My cold launch time is

                Total pre-main time: 1.3 seconds (100.0%)
                         dylib loading time: 1.0 seconds (73.8%)
                        rebase/binding time:  34.72 milliseconds (2.5%)
                            ObjC setup time:  45.06 milliseconds (3.3%)
                           initializer time: 275.88 milliseconds (20.2%)
                           slowest intializers :
                             libSystem.B.dylib :  10.16 milliseconds (0.7%)
                            SwinjectStoryboard : 207.26 milliseconds (15.2%)
                

                While a warn launch is

                Total pre-main time: 1.2 seconds (100.0%)
                         dylib loading time: 991.26 milliseconds (79.3%)
                        rebase/binding time:  29.23 milliseconds (2.3%)
                            ObjC setup time:  38.92 milliseconds (3.1%)
                           initializer time: 189.08 milliseconds (15.1%)
                           slowest intializers :
                             libSystem.B.dylib :  27.31 milliseconds (2.1%)
                            SwinjectStoryboard : 104.84 milliseconds (8.3%)
                

                 

                But not that 15 seconds I see in the crash report.

                I did some profiling and couldn't find anything heavy.

                 

                Is there any way I can workaround this? Happens rarely and always only in the background.