I have an iOS app that includes a local Swift package. This Swift package contains some .plist files added as resources. The package also depends on an XCFramework. I want to read these .plist files from within the XCFramework.
What I’d like to know is:
Is this a common or recommended approach—having resources in a Swift package and accessing them from an XCFramework?
Previously, I had the .plist files added directly to the main app target, and accessing them from the XCFramework felt straightforward. With the new setup, I’m trying to determine whether this method (placing resources in a Swift package and accessing them from an XCFramework) is considered good practice.
For context: I am currently able to read the .plist files from the XCFramework by passing Bundle.module through one of the APIs exposed by the XCFramework.
Your app has this layering:
app
|
v
package
|
v
XCFramework
You’re goal is to do this:
app
|
v
package <----+
| |
v |
XCFramework --+
Regardless of the mechanical issues you’re having, I don’t think that’s a good idea architecturally. Your XCFramework is library code. In general, you should strive to make library code independent of the context in which it’s running. If don’t then you’ll run into lots of weird problems. For example, imagine you want to create a test module for your XCFramework:
test runner
|
v
test
|
v
XCFramework ---> ???
What should it do in that case?
So, my advice is that you modify the XCFramework to accept some sort of configuration option that requires its client to either:
-
Supply a URL to these properties lists.
-
Or supply some other data structure that with the equivalent values.
-
Or both!
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"