Current build scripts does not generate dSYMs which may cause warnings under Xcode 16

[vincentneo]

Issue pertains to usage of TDLib in Xcode 16 betas, hence only concerns Apple OS platforms. dSYM refers to a debug symbols.

When uploading an app that uses TDLib's framework to App Store Connect, Xcode 16 displays a warning(?) after it's uploaded:

Not sure what kind of real impact this currently has, as it was later reported by App Store Connect that the app did still complete processing. Unsure if this can impact actual App Store submission and review in future.

Tested platforms:
Xcode 16 beta 5 (16A5221g)
watchOS 11 SDK

Tested TDLib build: 1.8.33 (97ded01) (As iOS build scripts did not change in the meantime, this should be irrelevant)

[levlam]

Could you change the line options="$options -DCMAKE_BUILD_TYPE=Release" to options="$options -DCMAKE_BUILD_TYPE=RelWithDebInfo" and check whether build succeeds and is suitable for production?

[vincentneo]

I've given that a try:

• It builds fine
• Built binaries are much larger than before (likely due to RelWithDebInfo's optimisation level)
• No dSYM or DWARF files found within xcframework
• Other built files appears similar or the same (let me know if there's any files to look out for)
• Xcode gives same warning

Also, update on yesterday - TestFlight deployment does work, so as of now likely this is really just a warning.

[vincentneo]

Did a bit of reading and found a that there's a dsymutil command.

Running dsymutil libtdjson.dylib -o libtdjson.dSYM generates a 1.26GB dSYM file, so I guess that could be something. The .dSYM appears to be consistently around 10x larger than the original .dylib, with a .dylib in the DWARF directory of the .dSYM that is taking most of that space. Unsure if that is normal.

Running the same command on a typical Release mode libtdjson.dylib yields a very small practically empty dSYM.

[levlam]

Does Xcode accepts the empty dSYM? If so, then providing it could be the best option, given it is unlikely needed to debug TDLib internals.

[vincentneo]

Does Xcode accepts the empty dSYM?

Yes, Xcode uploaded with no warnings!

xcodebuild -create-xcframework -library <libtdjson.dylib> -debug-symbols <libtdjson.dSYM> -library <libtdjson.dylib> -debug-symbols <libtdjson.dSYM> -output "libtdjson.xcframework"

[levlam]

Then, it is fine.

[vincentneo]

If anyone wishes to have the actual dSYM in their submission, that works too (albeit a longer uploading time).
Note: In that case, App Store Connect reports about a 15% increase in install size, even after stripping the dylib, likely due to optimisation level differences.

The nice benefit obviously is the user will get TDLib symbolicated in the event of crash or if one wishes to debug.

[levlam]

There should be no optimization level differences between Release and RelWithDebInfo builds. After full strip the binaries should be identical.

[vincentneo]

My bias was based on some quick reading that suggest O2 optimisation level for RelWithDebInfo and O3 for Release - though the two aren't all that different on size it seems.

Regardless, I’ve seen in the past that the entire build path is everywhere inside the dylib (like if you decompile or when Xcode points to some breakpoint or crash) - often a longer path yields a larger dylib, though not by much. Could be a factor to my observation too since the RelWithDebInfo build was housed an a folder with a longer name.

(I’m probably embarrassing myself with my lack of compiler knowledge through whatever I typed above 😅, hoping I can learn something out of this though)

[levlam]

You are actually right, the flags often differ by default between Release and RelWithDebInfo builds, but nevertheless O3 shouldn't decrease executable size that much. Moreover, some optimization enabled in O3 increase executable size, and for mobile platforms -Oz/-Os are more preferable.

[Kylmakalle]

My two cents. App Store does not have a mandatory requirement to ship dSYMS. For example, official iOS App does not ship them. Developers preserve symbols in their build environment to symbolicate and investigate crashes later.
When shipping them to App Store, Apple may symbolicate crashes for you.

[vincentneo]

@Kylmakalle well, dSYM or not, it doesn’t really bother me, it’s just Xcode 16 beta’s warning that bothers me 😅