Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>You might want to look at otool. Specifically, you probably want to use the -l flag which displays all the load commands (a.k.a. the sections and segments) that make up your binary.</p> <p>Having said all that, you would usually find that the resources are more significant than the code you write, so I'm wondering what problem you’ve encountered that you’re trying to solve. Our applications have a fair bit of code yet are still only a few MB. Maybe you’re statically linking to some big libraries—I don't know.</p> <p>If most of your code is Objective-C, very little of it will be removed with dead-code stripping (for obvious reasons), so that won’t make much difference.</p> <p>What will make a difference is the debug information which will be substantial. Your object files will include this, but you'd typically have it stored in a separate dSYM bundle when you link it so it won't be included in the final binary (or at least this is what you should be doing).</p> <p>Your code will be in the __TEXT, __text segment/section.</p> <p>I'm pretty sure the linker will coalesce equivalent strings so the total will be less than the sum of the parts for these sections, but, I guess, typically not by much.</p> <p>I would also expect your relocation and symbols sections to be less than the sum of the parts. You should strip your linked binary of unneeded symbols to save space (which isn't the same as stripping debug information). See the "Strip Linked Product" setting in Xcode.</p> <p>One other thing to remember is that your linked binary will be a FAT binary, whereas the object files usually aren’t.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload