Question 211394 in Xcode Question posted in
Whether you're new to Xcode or an experienced developer, our archive has everything you need to know about this integrated development environment (IDE). From basic functionalities to advanced features, our archive covers a wide range of Xcode-related questions and answers. Browse our archive now and find solutions to your Xcode questions, and take your app development skills to the next level

Xcode – Bundling a dext into an iOS .ipa with Xamarin

I have an project that takes a two-step process to build an iOS app. There’s the native libraries and .dext built in XCode, and then those are linked to a Xamarin project that I use to finish building the app in C# on VisualStudio build. It’s simple to link the static libraries in the Xamarin project, and it’s simple to embed the .dext to some other native-only app that just in XCode, but I’m not sure how to embed the .dext in the Xamarin project app.

Can you just BundleResource in the Xamarin csproj all of the files in the .dext package (embedded profile, CodeSignature, Info.plist, and the built driver) into a SystemExtension folder in the .ipa? There doesn’t seem to be a way to get the signed .dext package from the Xcode build either; the Copy Files "Code Sign On Copy" checkbox is broken for specifically driver dexts.

Tags:

2

Answers


  1. Chosen as BEST ANSWER
    0

    Yes, I can use the BundleResources to copy in the .dext into the .ipa's SystemExtensions directory.

    The issue I was facing is that Xamarin also has the OptimizePropertyLists property, which will scramble the bundled .dext's Info.plist and make it unable to install. That property needs to be set false on the Xamarin app's build project.


  2. 0

    I don’t know about Xamarin, but I can answer parts of your question:

    There doesn’t seem to be a way to get the signed .dext package from the Xcode build either; the Copy Files "Code Sign On Copy" checkbox is broken for specifically driver dexts.

    This is because you really don’t want to sign the dext with the same code signing setup as the app. It has its own app ID, entitlements, and corresponding provisioning profile. However, the disabled tickbox just means the dext should already be pre-signed when it comes to embedding it in the app. If you build the dext target on its own in Xcode/xcodebuild, it should already come out signed – if that’s not the case, your dext target is misconfigured.

    So all that is needed to embed the dext should be to copy it into the correct location in your app’s bundle, and then sign the app normally (probably with the communicates-with-drivers entitlement). I can’t tell you how that’s done with Xamarin, however.

    I believe on iPadOS there is also a requirement that the dext has a bundle ID that starts with the app ID’s bundle ID, so something like: com.example.apps.myapp.drivername if the app’s bundle identifier is com.example.apps.myapp. Xcode normally enforces this for you, but if you’re assembling your bundle "by hand" there’s nothing to check this.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search