1) The situation in general: 1A) I begun USB-DExt project for Mac & iPADsOS>=17. 1B) I started-from scratch with DriverKitSampleApp 1C) For these two different targets (Mac,iPAD; using IDE XCode15.0), I couldn't find another way to build the sample project from Apple, beside this: now I have two handmade sets of ini-profiles and two respective "command-files". 2) My current palliative solution comprises of two specific ~"command-files" (each one runs in a directory with specific DriverKitSampleApp.entitlements,project.pbxproj)_ : 2A) my current file "cpy.command" for target "MAC" ## Destination "Mac" ## DriverKitSampleApp.entitlements: "com.apple.developer.driverkit.userclient-access" ## item0: "com.ry.dexsample1.driver" ## Build Settings "DriverKitSampleApp":Signing:Code Signing Identity:"Sign to Run Locally" ## "NullDriver":Signing:Code Signing Identity:"Sign to Run Locally" ## "NullDriver":"AD_HOC_CODE_SIGNING_ALLOWED=YES" cp DriverKitSampleApp.entitlements ../DriverKitSampleApp cp project.pbxproj ../RyDExtSmpl1.xcodeproj 2B) my current file ~"cpy.command" for target "iPAD" ## Destination "iPAD" ## Build Settings "DriverKitSampleApp":Signing:Code Signing Identity:"Apple Development" ## "NullDriver":Signing:Code Signing Identity:"Apple Development" ## "NullDriver":"AD_HOC_CODE_SIGNING_ALLOWED=NO" cp DriverKitSampleApp.entitlements ../DriverKitSampleApp cp project.pbxproj ../RyDExtSmpl1.xcodeproj 2C) This state is inconvenient (predicting that I will switch between MAC and iPAD dozens thousands of times when debugging this project) 3) The question 3A) I need to build the Apple's sample project "DriverKitSampleApp" just selecting one of two possible targets (Mac,iPad) in XCode-IDE. 3B) Option1: what developer(or team's entitlements) do I need for "3A"? 3C) Option2: what adjustments of project's configuration files do I need for "3A"? .

The situation: 1A) On last week our development team applied on-line for three idVendors with the format as the following: USB-VendorID: 547h(1351), 3488h(13448),4B4h(1204) Describe your apps: it shall be functional equivalence of existing Android-SDK for X-ray sensor-models:...with 15..25 text lines of the description below 1B) We received auto-reply, that we granted all the the entitlements. We've expected to have entitlements like approx like the these: <key>com.apple.developer.driverkit.transport.usb</key> <array> <dict> <key>idVendor</key> <integer>1351</integer> </dict> <dict> <key>idVendor</key> <integer>131448</integer> </dict> <dict> <key>idVendor</key> <integer>1204</integer> </dict> </array> 1C) Unexpectingly (for us) ASCII-strings-fragment from our iOS-target-binary "com.rayence.dexta.driver" (built with automatic signing; seemingly this shall be our actual granted prvisionintg profile) looks as the next: <plist version="1.0"> <dict> <key>com.apple.developer.driverkit</key> <true/><key>com.apple.developer.driverkit.transport.usb</key> <array><dict> <key>idVendor</key> <string>*</string> </dict></array> </dict> 1D) Repectively, now we shall specify (in our dext's entitlements in XCOde-project) <key>com.apple.developer.driverkit.transport.usb</key> <array> <dict> <key>idVendor</key> <string>*</string> </dict> </array> In DExt's info.plist we have "normal": <key>IOKitPersonalities</key> <dict> <key>IOKitPersonality_EzHD</key> <dict> blah-blah <key>idVendor</key><integer>1351</integer> <key>IOKitPersonality_EzR</key> <dict> blah-blah <key>idVendor</key><integer>131448</integer> <key>IOKitPersonality_EzR</key> <dict> blah-blah <key>idVendor</key><integer>1204</integer> blah-blah Our ambiguities: 2a) Without exact "1D)", our DExt-installer-application never starts in iPAD. OS-loader generates obectievly-meaningless error-messages and seemingly-meaninglessly suggest to look "system-logs" (which seemingly don't contain relevant information) 2b) With exatct "1D)", 2ba) the reaction (presence/absence and timing of relevant console.app's messages) of our iPAD 17.4 on plugging/unplugging our gadgets look "non-logical". It isn't completly wrong but suspicious. E.g. our Swift-module randomly receive/dontreceive relevant events and can't connect communicate driver's instance for newly-attached physical gadgets. We realize, thses it could be our bugs; but we need disambiguation to debug the issues (or at least to be sure that the quirks are like in production system). 2bd) we would prefer debug/develop rather with real "idVendor=number nnn"s in provisioning profile (than with "idVendor=string *"). So we could be sure that quircs "2ba" are like in a production system. Respective question: Which format in on-line application ~1A) shall we use to obtain provisioning profile 1B)

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". 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" 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 for "a proprietary SDK with DExt" was/were assumed (as rational one) by architects of Apple-DExt-concept at all?

1) The situation: 8-bit grayscale still radiology-images, comparing to cheapest PC-displays: = appear "literally disgusting" on MacBook|M3; = appear "very bad" on iPAD|M2; = appear "just bad" on available iMAC (though this situation is ~correctable). Typical example (photo of 3 displays; the same 8-bit BMP or PNG by default view/preview on MacBook, iPAD, Windows): "https://ic.pics.livejournal.com/jbstphr/26474885/18157/18157_original.jpg" ** 2) The problem:** in cheapest PC-desktop/laptop a radiologist (or any human at all) distinguishes sRGB "gray 0..255 " (within 1..3 LeastSignificantBits) in default MacBook ~ 4 LSB in dark gray-tones disappear (i.e "gray 0" appears absolutely same as "gray 16") in default iPAD ~ 3 LSB in dark gray-ones disappear (i.e "gray 0" looks identical to "gray 8") 3) The question: = what could be stated in user-manual of a radiology-gadget to guide an end-user ?... = to adjust still gray-scale image_presentation of 8-bit BMP, PNG, GIF, TIFF, DCM (~sRGB-color-space) in: 3a) MacBook "AppleSilicon", 3b) iPAD "AppleSilicon"; assuming standard preview_app, Osirix, ImageJ; assuming that one places "3a,3b" near against cheapest PC-display on market; = so that: "gray 0..16" and "gray 240..255" are distinguishable in "3a,3b" not much worse tnan in cheapest PC-display 4) Comment 4a) Apple's PTC seemingly is weird S-like curve, to improve moving_imaging_impression sacrificing objective information of still-imaging presentation. 4b) Alternate color-profiles in MacBook's system_setting are 100% useless for the task. 4c) Adjust of white_point in MacBook,iPAD is <99%> useless for still radiology imaging (which needs adjustment of the black_point). 4d) Dedicated S-curve-like XLAT from PC-sRGB to APple's gray-scale isn't suitable, because of = the gadget is most world-wide-spread of it's case; = experience of existing Windows, Android-users can't be disturbed by few potential MAC-users; = double XLAT "sRGB => adhoc_color_space =>sRGB" (without overcomplicated & non_robust sentinels) causes pixellation (i.e. ~"gray 3.4.5" all become "gray 4")

=1) The situation: 1A) I make both a "DExt" and a "SDK" for still-imaging-USB-gadgets and MACOS>=14 ,iPADOS>=17 1B) One of the USB-gadgets needs warm_up after PlugIn (i.e End-User-App must know "now-TheMomentOfPlugIn" with precision ~1sec). =2) The question is how to do "1B" rationally? =3) My speculative guess: in BSD-descendant I expect existence (somewhere) of a "normal file" through "macports etc", which has normal "file creation time". Such a "file creation time" (accessible better via IORegistryEntry... at SDK-level; possibly via IOUSBHostInterface at DExt-level) is cognitive target of mine. =4) Additional constraints: Technically absent. I freely modify code either DExt (descendant of IOUSBHostInterface) or SDK-level (IORegistryEntryGetRegistryEntryID, IORegistryEntry...)