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.
