What could be a rational architecture of a "proprietary SDK with DExt" ?

  1. The situation

1a) I am developing an SDK for few "proprietary medical X-ray imaging gadgets" and MACOS, iPAD; 1b) The SDK would be used in near/middle future by 2..5 End-User-App-developers (ether by oldschool-teams and by young-startuplike-teams of different geography and mother-languages). 1c) The SDK necessarily incapsulates a DExt, respective installer-helpers also "API-to-decide", "sample-acquisition-app -to-decide".

  1. I am deciding the architecture to be convenient for expecting scope of End-User-App-developers

2a) I would like to make this SDK (with necessary proprietary DExt) convenient (in general) as ~ option 2a1) as a scanner within ImageCapture-Application-framework for older MAC-desktop ~ option 2a2) as an *.AAR in Android 2b) I would like to minimize my future communications with End-User-App-deveopment-teams and simplify further activities about "code-signing" and "provisioning-profiles"

  1. By my glance, Swift-packages are nearest approach to AAR. But AAR in Android never needs proprietary drivers like DExt. Respectively I have "general question about architecture":

3a) Is this possible (in a straightforward manner) to incapsulate proprietary signed "DExt.apk" and "DExt_Installer.apk" into a Swift-Package for 3rd-party application-developers ? 3b) What (speculatively,presumably) architecture<s> for "a proprietary SDK with DExt" was/were assumed (as rational one<s>) by architects of Apple-DExt-concept at all?

What could be a rational architecture of a "proprietary SDK with DExt" ?
 
 
Q