Xamarin-macios: Question : How to generate pkg file with app.dSYM package inside ?

[hanseul1795]

I'm trying to build a test app for iOS, tvOS and macOS.

I was able to add symbols folder inside the ios/tvos ipa files, using the xcode commands.

I'd like to do the same with macOS pkg file, but I could not find any info.

So, the question is,

is there an option (or a flag) that I could add to Xamarin in order to generate symbols package inside the .pkg file?

[spouliot]

No, there's nothing _out of the box_ for doing so, but .pkg are xar archives so you can expand/add/recompress (and sign) them if needed. Or you can create your own package... the default one provided for XM applications is very basic (package the .app bundle).

.dSYM are useful for the developer, not much for the end users, e.g. to symbolicate crash reports. They are also quite big so there's little value of bundling them in general.

Also .dSYM are not very useful for Xamarin.Mac applications, mostly because the code is JIT'ed. IOW the symbols don't have any address before execution, which makes the native stack traces less useful (but managed stack traces will have all the normal information).

Is there a particular scenario where you need this ?

[hanseul1795]

@spouliot Thank you for the answer!

• short answer:

Yes, for now, .dSYM file will be used for debugging purposes.

• long answer:

Apparently, if iOS and tvOS .ipa file without symbols (mSYM/dSYM) is uploaded, it will crash

automatically on the end user devices.

So I thought the same situation might happen to Mac, sooner or later.

This is the reason why I'm trying to add .dSYM file inside the .pkg file.

[spouliot]

I'm not aware of automatic crash without symbols, any link ? it sounds quite counter-productive (better reject the app) and does not help anyone.

TL&DR Unless you expect your users to debug the issue it's not really needed (for macOS).

Long answer

What happens is that

• (nearly all) iOS/tvOS apps comes from the App Store;
• what you ship to Apple's AppStore is not identical to what is sent back to your customers, e.g.
  
  
  
  • if you submit bitcode (default for tvOS, we don't do it for iOS and it's not used on macOS) then the application is recompiled;
  
  
  • that recompilation also means your symbols won't be correct (and you should download the updated ones from Apple);
  
  
• if you, the developers, do not have the matching .dSYM then you won't be able to see exactly where the crash happened (you'll see addresses, not symbols). This makes .dSYM very important for you to keep around (for released software versions) but it does not help customers.
• the .dSYM you give to the AppStore does not get into your customer's devices. Like I mentioned before the dSYM are for native code and most of your macOS applications (unless it's AOT'ed, which is not the default) is managed and JIT'ed - so you won't get much from it.

.mSYM are similar but it's for managed code (and from Mono, not Apple). It won't cause a crash if missing at runtime and it does not need to be shipped with the app either. You use the .mSYM along a stack trace (from a crash) and a tool [1] so you can see where a crash occurred without shipped large debugging symbols to customers. This requires extra steps which is why it's meant as a developer (not a customer tool).

As an alternative you can add debugging symbols (e.g. .pdb) in your macOS app bundle (so they will be part of the .pkg). This will produce better managed stack trace for your customers - but you still need a way to get the data back to you (e.g. a crash reporter).

[1] https://github.com/mono/mono/tree/master/mcs/tools/mono-symbolicate

[hanseul1795]

@spouliot thank you for the detailed answer, I clearly understood the concept of the .mSYM file.

One last question before I close this issue, what is the flag that I need to send (in .csproj file) to disable .pkg file generation?

[spouliot]

It's enable by default on Release and disabled on Debug. You can change this in the UI (easier) or in the .csproj. Here's a diff

-    <CreatePackage>true</CreatePackage>
+    <CreatePackage>false</CreatePackage>

You can probably remove the line too... but if you want it back it's easier to provide false (so you don't have to recall what needs to be done).

[hanseul1795]

@spouliot it's perfect.

I've found a way to add symbols in the .pkg
xcrun symbols to generate symbols from .dSYM file and pass --symbolication arguments to productbuild to pack symbols inside the .pkg file.
I don't know why some of the productbuild arguments are not documented but it's working.

Thank you so much for all your help!

Hanseul