应用程序在发布版本中崩溃，但在调试中没有崩溃

Question

As I said in the title, I am writing an app for iPhone which runs perfectly in debug mode but when I build it as release and install it via TestFlight, it crashes. Due to the crash log it might have to do something with this lines:

let path = NSBundle.mainBundle().pathForResource("PrinterList", ofType: "plist")
if path != nil {
    let printerDic = NSDictionary(contentsOfFile: path!)
    let printerList = NSArray(array: printerDic.allKeys)
    printerNames = printerList as [String]
}

I am using an framework from Brother to print without AirPrint, but I think thats not the problem because the app crashes before doing something with the framework. It crashes only in this ViewController where I execute these lines. I need the framework only in this ViewController as well.

Answer 1

There are many reasons that an app might crash in release mode but not in debug mode (eg memory allocation differences showing up a bug that actually exists in both builds.) They can take a lot of work to track down, even with a non-beta compiler/language.

You say that the problem goes away if you do as I suggested and build for release with optimisations turned off. Given that the Swift compiler is still in beta and definitely still has the occasional problem—I've seen the compiler simply crash when building optimised builds—this may actually be an optimiser bug.

For now, therefore, I'd defer looking into it. Release without optimisations until we get a full release version of the compiler. Then, turn optimisations back on and see if you still have the problem. If you do, that's the time to start spending your energy trying to figure out if it's a compiler bug or a bug in your own code.

Answer 2

I've had the same problem. I finally fixed it by turning on whole module optimization . Combined with correct implementations of access control this should fix your crash.

Whole module optimization according to Apple:

Use Whole Module Optimization to infer final on internal declarations. Declarations with internal access (the default if nothing is declared) are only visible within the module where they are declared. Because Swift normally compiles the files that make up a module separately, the compiler cannot ascertain whether or not an internal declaration is overridden in a different file. However, if Whole Module Optimization is enabled, all of the module is compiled together at the same time. This allows the compiler to make inferences about the entire module together and infer final on declarations with internal if there are no visible overrides.

You can enable this in your project settings:

But be aware this option optimizes all of the files in a target together and enables better performance at the cost of increased compile time.

Answer 3

To catch the crash test the with the Optimization Level set to Fastest, Smallest [-Os] in Debug mode to more closely simulate the code that will be generated & running on the user's device.

You can set it in build settings, under Swift Compiler/Code Generation

Answer 4

Apple also describes a known issue . I describe it briefly in case someone is look for answer and the previous solution doesn't work.

Check your crashlog for errors like

Dyld Error Message:
  Library not loaded: @rpath/libswiftCore.dylib

or

[....] [deny-mmap] mapped file has no team identifier and is not a platform binary:
/private/var/mobile/Containers/Bundle/Application/5D8FB2F7-1083-4564-94B2-0CB7DC75C9D1/YourAppNameHere.app/Frameworks/libswiftCore.dylib

and follow apple guidance if you have similar crash output like the one above.

PS: You could check the log easily even under Window ->Device in XCode. click to the device and click view device logs.