Errors while uploading app archive to TestFlight

[nicolantean]

I could integrate the SFBAudioEngine framework and all the dependencies to my app successfully, but when I try to upload the archive to TestFlight Apple throws the following errors:

One of the errors (and I think the others are related to this one) is because the name of one of the dependencies has a character in its name (tta++). So as this is the name of the dependency I can't just change the name of it because the SFBAudioEngine will search it as tta++ anyways.

Has anyone experienced this? Is there an installation guide somewhere? Thanks

[svenoaks]

I also have these exact errors. Any update on how to fix this?

[sbooth]

https://github.com/sbooth/AudioXCFrameworks/pull/25 will fix the illegal bundle characters error.

[sbooth]

I've been experimenting with different ways to package SFBAudioEngine to make it simpler to build and include in other projects.

Initially I'd hoped the dependencies could be included as binary Swift package targets, but SPM doesn't handle dependencies for binary targets so getting, for example, the vorbis and flac frameworks to both depend on the ogg framework isn't realistically feasible. I think there are some gymnastics that can be done by making the binary target depend on an empty source target that then includes the binary sub dependency, but I don't really want to go down that road.

iOS doesn't permit umbrella frameworks so the current build strategy isn't viable.

To avoid building SFBAudioEngine as an umbrella framework the app using it will have to include the framework dependencies. Statically linking the code into a single SFBAudioEngine binary isn't an option because of LGPL requirements.

There are two options I've been contemplating for the dependencies:

1. Include the compiled XCFramework dependencies in the repo
2. Make the compiled XCFrameworks available as an external download

I'm leaning toward option 1 for simplicity.

[andykent]

I'm not sure if this helps but we currently use your ogg/opus frameworks in an internal package that is built cross platform. Our current approach isn't ideal but it is working for our limited deps. If the compiled frameworks were in the repo then this would help make things simpler.

Once built we copy the compiled frameworks into a Frameworks folder in the root of the Swift package and then use the following Package config...

...
targets: [
  .target(
    name: "MyPackage",
    dependencies: ["COpusFile"]),
  .target(
    name: "COpusFile",
    dependencies: ["ogg", "opus"],
    path: "Sources/COpusFile"),
  .binaryTarget(
    name: "ogg",
    path: "Frameworks/ogg.xcframework"
  ),
  .binaryTarget(
    name: "opus",
    path: "Frameworks/opus.xcframework"
  )
]
...

where COpusFile just includes the following dummy swift bridge.

#include <ogg/ogg.h>
#include <opus/opusfile.h>

#include "bridge.h"

void __dummy() {}

We are then able to add the package as a project dep in Xcode and import COpusFile in Swift land and everything seems to just work. No idea if this is the right approach or not, it was mostly trial and error to get this point but it does upload to TestFlight at least.

[sbooth]

@andykent thanks for that. Out of curiosity if you add vorbis or flac (which also have dependencies on ogg) to your package do you get warnings about duplicated targets?

Right now I am leaning toward the following approach:

1. Remove the XCFrameworks submodule and replace it with a directory
2. Check in compressed versions of the .xcframework files in the XCFrameworks directory
3. Create a target to decompress the xcframework archives as needed (using make most likely)
4. Update the examples to link the frameworks

I think this will go a long way toward improving the usability of SFBAudioEngine for developers.

[sbooth]

This should be fixed in #230. Any testing to verify the new build process would be appreciated.