Add ios_dylib rule

[brentleyjones]

I need to add tests, but we use this internally to create SwiftUI Preview thunks, and others have expressed interest in having this rule, so I thought I would open the PR earlier.

[keith]

Are the dylibs produced from this valid? Looks to me like their install names are incorrect:

bazel-bin/Modules/Logger/libLogger.dylib:
        bazel-out/ios-x86_64-min11.0-applebin_ios-ios_x86_64-fastbuild-ST-7786d55448f4/bin/Modules/Logger/libLogger_bin (compatibility version 0.0.0, current version 0.0.0)

[keith]

huh looks like the macos_dylib rule produces one with a similar name, but I don't think that's right? Doesn't that need to be @loader_path/Frameworks/libFoo.dylib or something similar?

[keith]

It kinda seems like right now you can't use this how you might want by bundling a tree of dylibs into a ios_unit_test, in these cases it seems that you're fighting between what attr to put them in first, such as dylibs, and then you end up statically linking the transitive dependencies still.

[brentleyjones]

Yeah, it works for our specific use case of making a single dylib for use with SwiftUI Previews (and an XCBBuildService proxy). It mirrors how the macOS one works. My use case is taking the resulting binary directly, so I didn't look into bundling inside another app yet, but I can look into that and make sure it works. As for the transitive dependencies, we don't hit that in our use case so far, so I don't have many opinions about it yet.

[brentleyjones]

As for the transitive dependencies, we don't hit that in our use case so far, so I don't have many opinions about it yet.

I assume we should be able to make it work though, and ideally just through deps instead of frameworks.

[keith]

I can't think of another example where a packaging rule can be directly depended on via deps like this, and I assume this is why apple_binary has a dylibs attr 🤔