Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question : How to generate pkg file with app.dSYM package inside ? #7495

Closed
hanseul1795 opened this issue Nov 26, 2019 · 6 comments
Closed
Labels
macOS Issues affecting macOS need-info Waiting for more information before the bug can be investigated question The issue is a question
Milestone

Comments

@hanseul1795
Copy link

hanseul1795 commented Nov 26, 2019

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?

@hanseul1795 hanseul1795 changed the title Question : How to generate pkg file with app.dSYM package inside ? Question : How to generate pkg file with app.dSYM package inside ? Nov 26, 2019
@spouliot spouliot added macOS Issues affecting macOS question The issue is a question labels Nov 28, 2019
@spouliot spouliot added this to the Future milestone Nov 28, 2019
@spouliot spouliot added the need-info Waiting for more information before the bug can be investigated label Nov 28, 2019
@spouliot
Copy link
Contributor

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
Copy link
Author

hanseul1795 commented Nov 29, 2019

@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
Copy link
Contributor

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
Copy link
Author

@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
Copy link
Contributor

spouliot commented Dec 2, 2019

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
Copy link
Author

@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

@ghost ghost locked as resolved and limited conversation to collaborators May 1, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
macOS Issues affecting macOS need-info Waiting for more information before the bug can be investigated question The issue is a question
Projects
None yet
Development

No branches or pull requests

2 participants