@relikd thanks for the PR!
Can you rebase this one and make sure spaces are used everywhere for indentation? Mix of spaces/tabs makes git diffs more complicated.

Not sure if I fixed it. A rebase was too complex so I merged by ignoring your commit (it contained only tab conversions anyway). In this branch there were no mixed indentation, only tabs. But I converted it all to spaces as per your request. (btw. you already had mixed indentation before my first PR). Now it is uniform.

Also, I just looked at the diff, and I think its easier to just look at the code than the diff. There are simply too many changes 😄. But thats just my opinion.

Thanks for the update, I will go over this in coming days. It's a huge work, so I'll need more than a quick look :)

you already had mixed indentation before my first PR

That's right, I've noticed it! It wasn't obvious until we had some big diffs.

Did you have any time yet to look at the PR? :)

@relikd yes! but that's a lot to digest (4000 lines of changes!)
I'll dedicate more time to it, but can't guarantee that we'll merge it very soon.

If you have time and energy and can slice it into smaller PRs ("show iTunes Metadata", "replace zip helpers", etc), we'll get it much faster.

Thank you for your contribution anyway!

Some questions to start:

• Where CoreUI framework comes from and how is it used?
• Why Pinch/ZipEntry is used, what are the benefits?

can slice it into smaller PRs ...

unfortunately that is not easily possible because the refactoring of the code structure is what makes the most changes. Otherwise I would have created multiple PRs.

Where CoreUI framework comes from and how is it used?

CoreUI is private API and used by Apple internally. Thats why there are only header files and no source code. This framework is used to read "Assets.car" files (app icons). I placed a bunch of checks to fallback to an undistrubed execution in case the API changes (or isnt available at all which should never happen).

Why Pinch/ZipEntry is used, what are the benefits?

To read the zip content without relying on a sys-call to unzip. This improves performance as it does not need to spawn sub-processes. Again, I've added some checks to fallback to the unzip sys-call in case the in-memory extraction fails (or CRC check fails, though I think the unzip utility simply ignores CRC).

I have a similar fallback for the codesign sys-call (which now uses direct execution too)