There are a few packages which seem to require ibtool. This binary comes from the full Xcode rather than cli tools for some reason, and that would make the package non-free.
In a moment of madness I thought - what’s to stop me from reimplementing it? Turns out there’s a project on GH already which can process some iOS xib files, but it’s extremely alpha and has bugs. But after a few changes, I can process the smallest of Transmission’s xib files. (With lots of attributes still missing, but still)
But before I dig too deep and polish the results to be 100% matching:
Has anyone tried to do that yet? Are there any known “this will not work because…” reasons?
Has anyone thought about it and collected any minimal .xib files? Just getting enough good samples is an annoying job.
I tried it once for the Vulkan-Tools cube demo, but it didn’t work. That may be one simple example. Another could be the Mac pinentry for GNUPG. There are translated nibs checked into nixpkgs, which might be useful as references for intended output. They’re not minimal, but the apps are not complicated.
Edit: Added pinentry links. The cube demo is using storyboards, which may not be what you wantz
I don’t think there’s any fundamental reason it couldn’t be done, just… nobody has wanted to do it If you got somewhere with it, that would be incredible!
Although I warn you that your next job would be to write a Metal shader compiler that targets an undocumented IR… (and xcbuild really needs a maintainer or a rewrite…)
Just as a followup, I’ve got a few simple/test xibs compiling correctly and one big one from Transmission. A couple more weeks and this may be actually usable.
Two more weeks were not enough. But I’ve got a few more files from transmission passing almost 100%. The remaining work is:
mostly just copy-pasting values for new control types
the small-but-annoying unresolved difference is frame size calculation which is off by a few px
The biggest time sink was discovering that some details and behaviours depend on the toolsVersion attribute in the Xib files. I’ll have to find the actual thresholds one day rather than depending on checking for >= value from test files I have. Apple’s ibtool preserves bug-for-bug compatibility going many versions back.
Anyway, building transmission should be possible soon™
As I get closer to some release (4 files from transmission succeed, all others are mostly ok), I’m starting to wonder what’s the good model for long-term maintenance.
The big issue with an open replacement is that there’s no good way to tell when an edge case is being hit. Even with lots of asserts and exceptions on unknown values, some areas are still basically magic. I’m trying to keep a reasonable set of manually recreated test cases so I don’t run into a “files from other project” licence issues, but that doesn’t stop new edge cases and new IB versions from appearing. Which means we’re virtually guaranteed to get a package update one day which looks funky but just via nixpkgs.
The only idea I’ve got at the moment is to have a repo with one submodule for each currently supported project and run a weekly summary, comparing my tool’s output to Apple’s for each xib found. This is likely going to be a pain but it may be the only way to catch issues before they land in actual future releases. And not keeping them in the same repo works around licensing.
Other ideas welcome. Of course it’s going to be easier if the project actually gets more people involved, but it’s such a weird thing I’m not holding my breath.
I thought this project can avoid “the other 90%” problem, but then discovered today that even basic xibs used in transmission can compile to recursive nibs. And I blame Apple…