Rixstep
 About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Home » Learning Curve » ACP Guru

On Manicuring NIBs

From the ACP/Xfile update 18 March 2017.


Get It

Try It

This update's about the NIBs that needed to be manicured.

A few words first about how it's done.

This NIB manicuring is necessary because Jony Ive, in addition to all else he's done, signed off on a fundamental GUI metric recently which means that apps with tableviews with column headers that have directional arrows must be heightened by six pixels to keep their layout correct.

NIBs today are *compiled* by Xcode. They weren't compiled by Project Builder. For along came Apple's 'keyed objects' (which we never use) and things were very messy for a while with ridiculous extraneous NIB helper files adding tens of megabytes to ordinary OS updates, thus giving rise to tools such as those from Ankur Kothari.

So to create a new modified NIB, one must *build* an entire app.

We've done this now for 8 (eight) ACP apps.

The punch line (the punch in the gut) is a 'Swift' one. For later Apple compilers, for now equipped with the childish 'Swift' capability, add puerile bulk to decent binaries even if that LLVM language isn't used. Talk about demented.

The closest we see to this is the 'fake' entry point used on Windows which adds about 2.5 KB to an executable. This, however, is in a class of stupidity all its own.

To wit:

Here are the totals for the eight bundles with the current binaries:
89 items. 821,592 bytes. 1,872 blocks. 0 bytes in extended attributes.

Here are the totals where the only change is in the binaries themselves:
89 items. 975,292 bytes. 2,168 blocks. 0 bytes in extended attributes.

Can you see the diff? *153,700* bytes. For 8 binaries. That's *19,212.5* bytes per binary. And you know how tight our code already is. The diff is staggering.

App           Apple  Ours   Bloat
---           -----  ----   -----
ACL           58592  42540   38%
ASM           39024  18788  107%
ASMX          61396  45496   35%
Clipotheque   60984  44936   36%
TempEdit      34608  18312   89%
TIFFCompress  34604  14268  143%
XaBatch       52444  28160   86%
Xbase         52180  27732   89%

There are two binaries there that are over twice as big. Those are all 'release' binaries. (Something the amateurs on the platform don't even know how to create.) They're the exact same code. The code's not been touched at all.

Use either binary in the same bundle - same results. Why the diff? What's all that additional code for?

It's for STUPIDITY.

And this is why we keep legacy boxen. So we don't have to appear as fucking demented as the rest of the Landed Gentry. We won't tolerate it. It's disgusting.

*

See Also
Xfile: Free Test Drive
CLIX: Learn How to Fish

About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Copyright © Rixstep. All rights reserved.