Adding several pods increases iOS app launch time by 10+ seconds

Question

I\'m doing an iOS app project in Swift 1.2, using Cocoapods 0.37.2, Xcode 6.3.2. After adding around 8 pods in my project, app launch time greatly increases (around 10 secon

Answer 1

There is a lot of discussion around this here: https://github.com/artsy/eigen/issues/586

Answer 2

Probably there is one Pod which increases launch time (in worst case more Pods). My advice is to remove one by one the Pods to is if your issue is fixed. Maybe it's easier to create another project to make this test.

If you have a framework or Pod which uses -all_load linker flag, it's a big chance that one to increase a lot the launch time.

Answer 3

After some research i found that issue actually not in cocoapods, but in embedded libraries (I was able to reproduce the same issue with carthage).

It's not reproducible on all devices (possibly only on 32bit). And this issue doesn't affect app store builds. And while it makes development slightly slower, it not so harmful.

https://forums.developer.apple.com/message/64556#64556 https://forums.developer.apple.com/message/82399#82399

Answer 4

There are a host of reasons that you might be observing slow application start situations such as low memory or disk space conditions, jailbroken and/or modded device, failed software update in need of a clean install, or even hardware failure. While there isn't a lot to go on with the info you've provided, there are a few things you can take a look at to try and eliminate potential causes.

I've cloned your sample project and tested on devices from iPhone 5 through iPhone 6 Plus and while I have not been able to replicate slow behavior you've observed locally, I have been in situations where both external and internal factors have caused slow startup performance.

First things first, given that we have only a portion of your crashlog you should do some quick verification to make sure we are heading down the right investigative path (Ideally it would be helpful to see the full crashlog) -- As you may or may not know, iOS employs a watchdog process to ensure that iOS apps respond in a reasonable amount of time. When debugging watchdog restrictions are not enforced to allow Xcode the time it needs to establish a live debugging session. Launching as a standalone app, that is, outside of a debugger, Watchdog restrictions are in full effect. Take a look at your crashlog, and check that the Exception Code is the 0x8badf00d (Read: "Ate bad food") -- on 64-bit devices this code will be padded by leading zeros: 0x000000008badf00d

Via TN2151 > Exception Codes:

The exception code 0x8badf00d indicates that an application has been terminated by iOS because a watchdog timeout occurred. The application took too long to launch, terminate, or respond to system events. One common cause of this is doing synchronous networking on the main thread. Whatever operation is on Thread 0: needs to be moved to a background thread, or processed differently, so that it does not block the main thread.

As you've pointed out that application:didFinishLaunchingWithOptions: isn't hit until after waiting that 10+ seconds, it suggests that the delay is occurring while the app's bootstrapping is happening -- your crashlog excerpt generally seems to agree. TrySlowSwiftApp.app's Thread 0 contains only stack frames for the dynamic link editor dyld. You also want to make sure that your crashlog is indicating that Thread 0 is the frame triggering the crash (I can't recall encountering a watchdog crash where Thread 0 wasn't blamed, but I suppose it is possible!). If another thread is being blamed, then we would need to see more about the crashlog you have on-hand.

TN2239 speaks to a host of iOS debugging tools, and includes a section of Environment Variables for the Dynamic Linker - We want to add DYLD_PRINT_STATISTICS with a value of YES to the current run scheme:

We should also enable 'Log Library Loads' in the Scheme's Diagnostic's Editor:

Finally, Xcode's console does not include timestamp information in the In-Xcode Console. You can, however, use Xcode's 'Devices' screen to view the live console with timestamps:

The Environment Variable we added will give you statistical information about what dyld spent its time doing, while the the 'Log Library Loads' options will show you the specific libraries that are attempting to be loaded. Because you are viewing this information in the Device's console you are able to see timestamps associated with each log entry.

Within the dyld statistics output, look for operations that are taking unusually long on your device -- for reference, here's one load on my iPhone 6:

Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total time: 1.9 seconds (100.0%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total images loaded:  148 (127 from dyld shared cache)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total segments mapped: 60, into 1756 pages with 164 pages pre-fetched
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total images loading time: 1.5 seconds (81.6%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total dtrace DOF registration time: 0.06 milliseconds (0.0%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total rebase fixups:  32,521
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total rebase fixups time: 24.03 milliseconds (1.2%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total binding fixups: 120,894
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total binding fixups time: 190.36 milliseconds (9.8%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total weak binding fixups time: 1.76 milliseconds (0.0%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total bindings lazily fixed up: 0 of 0
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total initializer time: 137.82 milliseconds (7.1%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>:     libSystem.B.dylib 
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: : 60.11 milliseconds (3.1%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: libBacktraceRecording.dylib 
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: : 0.39 milliseconds (0.0%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>:        libc++.1.dylib 
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: : 0.27 milliseconds (0.0%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>:       libobjc.A.dylib 
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: : 0.03 milliseconds (0.0%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>:        CoreFoundation 
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: : 3.40 milliseconds (0.1%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>:                vImage 
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: : 0.31 milliseconds (0.0%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>:      libGLImage.dylib 
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: : 0.08 milliseconds (0.0%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: libFosl_dynamic.dylib 
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: : 0.01 milliseconds (0.0%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>:             CoreImage 
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: : 0.57 milliseconds (0.0%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>:    libswiftCore.dylib 
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: : 1.74 milliseconds (0.0%)
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total symbol trie searches:    42394
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total symbol table binary searches:    0
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total images defining weak symbols:  17
Jul 22 16:44:02 iPhone-6 TrySlowAppSwift[939] <Notice>: total images using weak symbols:  44

Within the 'dyld: loaded:' lines, take a look at the timestamp accompanying each item that is loaded -- you are looking for places where it takes longer to load the resource than it does with surrounding resources.

Depending on what you find by using these diagnostic tools will help determine what the next diagnostic step should be -- This is left for you to interpret in light of additional information gathered with these steps.

As suggested by others, I'd start by double checking the behavior on a second identical model and OS device -- just to rule out something device specific. If you can replicate it there then you should direct more time to a software investigation, however if it doesn't replicate there, you should direct your time to diagnosing your affected device. A more drastic diagnostic step could involve wiping the device and performing a clean install of iOS. If you do this, I would be prepared to do it at least twice -- the first time not restoring from iCloud or iTunes backup and retesting the launch behavior, then reloading a second time to restore your content to the device.