Hi everyone, We are experiencing an issue with SMS messages sent from our banking app (iOS) to our customers. The SMS are being delivered by the carrier, but on iOS devices some of them appear to be filtered or blocked, and users don’t see them in the Messages app. This seems to be related to new SMS filtering rules on iOS (possibly affecting financial institutions and transactional SMS). • Has anyone faced a similar situation? • Are there specific Apple guidelines or best practices for SMS sender IDs / content to avoid being filtered? • Is there any official documentation from Apple regarding these new SMS filtering mechanisms? Any guidance or experiences would be greatly appreciated. Thanks in advance!

I have a USB-device with three interfaces: Vendor-Specific Bulk CDC Serial Control CDC Serial Data To configure the vendor specific bulk endpoints I need to send vendor specific control requests to endpoint 0. I'm using libusb for this task. As long as the interfaces for the CDC serial port are present I get an access error when trying to send vendor control requests. If I disable these CDC interfaces I can send vendor control request without any problems: Is this by design or ist there any possibility to send vendor control requests to the USB device while a CDC driver is active?

Hi, Is it possible for a macOS (or iOS/ipadOS) app to communicate with a CCID-compliant reader using the CCID interface (i.e., directly sending the PC_TO_RDR_* messages) instead of using the CryptoTokenKit API? Apple's CCID driver (/System/Library/CryptoTokenKit/usbsmartcardreaderd.slotd) seems to support all the PC_TO_RDR and RDR_TO_PC messages: https://blog.apdu.fr/posts/2023/11/apple-own-ccid-driver-in-sonoma/#enable-my-ccid-driver The background for this question is that we develop smartcard products and we'd like to use the finer grained settings provided by the CCID specification for testing/demo purposes. Thank you.

Hi, On macOS 11 and earlier versions, we provided users with the following script to uninstall our kext driver: sudo pkgutil --only-files --files com.magewell.ProCapture | tr '\n' '\0' | xargs -n 1 -0 sudo rm -vf sudo pkgutil --only-dirs --files com.magewell.ProCapture | grep ProCapture[^/]*$ | tr '\n' '\0' | xargs -n 1 -0 sudo rm -rvf sudo pkgutil --forget com.magewell.ProCapture sudo kextcache -system-caches However, this script no longer works on macOS 13 and returns the following error: It looks like you're trying to update the system caches. As of macOS 11, the personality cache is no longer in use for keeping kext matching information up-to-date. For more information, see `man kmutil`. This indicates we can no longer use kextcache -system-caches to clear our driver cache. This creates an issue where even after installing the new dext driver, the dext driver cannot run due to the presence of the old kext driver. We've tried various methods but haven't been able to completely uninstall the old kext driver - after every new system update, the old kext reappears. The specific process is as follows: This is the sequence I followed in my latest test - Device is running macOS 13 Ventura w/ 4247 Pro Capture kext driver installed kmutil inspect | grep -i magewell - this returns references to the kext files in /Library/Extensions, which is expected because I have not yet removed the 4247 kext driver - then I ran the following combination of your removal script and my removal steps: cd / sudo rm -r /Library/Extensions/ProCaptureDriver.kext sudo rm -r /Library/Extensions/ProCaptureEvent.kext sudo rm /System/Volumes/Preboot/*/boot/*/System/Library/Caches/com.apple.kernelcaches/kernelcache.auxkc* sudo pkgutil --only-files --files com.magewell.ProCapture | tr '\n' '\0' | xargs -n 1 -0 sudo rm -vf sudo pkgutil --only-dirs --files com.magewell.ProCapture | grep ProCapture[^/]*$ | tr '\n' '\0' | xargs -n 1 -0 sudo rm -rvf sudo pkgutil --forget com.magewell.ProCapture sudo kextcache --clear-staging sudo kcditto sudo kmutil install --update-preboot sudo shutdown -r now - After this I ran 'kmutil inspect | grep -i magewell' and got no results, which seems good but... - then I ran the upgrade to macOS 15.7 Sequoia - Afterwards I ran 'kmutil inspect | grep -i magewell' and it returned references to the old /Library/Extensions kexts again, although the files no longer exist in /Library/Extensions - I then ran my cleanup process again (slightly different for Sequoia-available commands): sudo rm /System/Volumes/Preboot/*/boot/*/System/Library/Caches/com.apple.kernelcaches/kernelcache.auxkc* sudo kextcache --clear-staging sudo kmutil rebuild sudo kcditto sudo kmutil install --update-preboot sudo shutdown -r now - Then I ran 'kmutil inspect | grep -i magewell' and got no results again - As a next test I ran a minor update to macOS 15.7.1, then ran 'kmutil inspect | grep -i magewell' and the references to the old kexts came back again We have indeed identified a solution to address this issue: kmutil trigger-panic-medic --volume-root /Volumes/<YourVolumeName> However, this method requires booting into Recovery Mode, which is unacceptable for many of our customers. Especially for those who need bulk remote management, having personnel physically operate each machine one by one is simply not feasible. Therefore, is there a method to completely uninstall the kext driver while in normal mode? Thank you!

I want to turn off this effect and maintain the style before iOS18. Do I need to add content about iOS26 to the info.plist? Specifically, which content is it? I want to turn off the glass effect on the button

Hi everyone, We are in the process of migrating a legacy KEXT for our external multi-disk RAID enclosure to the modern DriverKit framework. During the performance validation of our KEXT, we observed a large and consistent maximum throughput difference between Intel-based Macs and Apple Silicon-based Macs. We would like to share our findings and hope to discuss with others in the community to see if you have had similar experiences that could confirm or correct our understanding. The Observation: A Consistent Performance Gap When using the exact same external RAID hardware (an 8-HDD RAID 5 array), driven by our mature KEXT, we see the following results in high-throughput benchmarks (AJA System Test, large sequential writes): On a 2020 Intel-based Mac: We consistently achieve a throughput of ~2500 MB/s. On modern M-series Macs (from M1 to M4): The throughput is consistently capped at ~1500 MB/s. This performance difference of nearly 40% is significant and is present across the entire Apple Silicon product line. Our Hypothesis: A Shift in Architectural Design Philosophy Since the KEXT and external hardware are identical in both tests, we believe this performance difference is not a bug but a fundamental platform architecture distinction. Our hypothesis is as follows: 1. The Intel Mac Era ("Dedicated Throughput") The Intel-based Macs we tested use a dedicated, discrete Intel Thunderbolt controller chip. This chip has its own dedicated PCIe lanes and resources, and its design appears to be singularly focused on maximizing raw, sustained data throughput for external peripherals. 2. The Apple Silicon Era ("Integrated Efficiency") In contrast, M-series Macs use a deeply integrated I/O controller inside the SoC. This controller must share resources, such as the total unified memory bandwidth and the chip's overall power budget, with all other functional units (CPU, GPU, etc.). We speculate that the design priority for this integrated I/O controller has shifted from "maximizing single-task raw throughput" to "maximizing overall system efficiency, multi-task responsiveness, and low latency." As a result, in a pure, single-task storage benchmark, its performance ceiling may be lower than that of the older, dedicated-chip architecture. Our Question to the Community: Is our understanding correct? Have other developers of high-performance storage drivers or peripherals also observed a similar performance ceiling for external storage on Apple Silicon Macs, when compared to high-end Intel Macs? We believe that understanding this as a deliberate architectural trade-off is crucial for setting realistic performance targets for our DEXT. Our current goal has been adjusted to have our DEXT match the KEXT's ~1500 MB/s on the M-series platform. Any insights, confirmations, or corrections from the community or Apple engineers would be greatly appreciated. Thank you very much! Charles

Hello, I'm trying to make a DEXT for a thunderbolt device. I started from the DriverKit template that does a very simple Hello World. I added the DriverKit PCI (development) entitlement in the developer portal. The dext is installed and activated but when I connect my thunderbolt device this is what I see in the console log: kernel DK: mydrv-0x100010a85 waiting for server com.mycompany.mydrvApp.mydrv-100010a85 kernel Driver com.mycompany.mydrvApp.mydrv has crashed 0 time(s) kernelmanagerd Launching dext com.mycompany.mydrvApp.mydrv com.mycompany.mydrvApp.mydrv 0x100010a81 e675cb5ca6b6650163cc231c6af2f7e730b56b0bf394b857ce76f8e3105eb0f1 kernel DK: mydrv-0x100010a89 waiting for server com.mycompany.mydrvApp.mydrv-100010a89 kernelmanagerd Launching driver extension: Dext com.mycompany.mydrvApp.mydrv v1 in executable dext bundle com.mycompany.mydrvApp.mydrv at /Library/SystemExtensions/DC2F3964-043D-445E-A6CF-A9D7C529B39A/com.mycompany.mydrvApp.mydrv.dext default 16:52:31.551867-0500 kernel /Library/SystemExtensions/DC2F3964-043D-445E-A6CF-A9D7C529B39A/com.mycompany.mydrvApp.mydrv.dext/com.mycompany.mydrvApp.mydrv[15788] ==> com.apple.dext kernelmanagerd Found 1 dexts with bundle identifier com.mycompany.mydrvApp.mydrv kernelmanagerd Using unique id e675cb5ca6b6650163cc231c6af2f7e730b56b0bf394b857ce76f8e3105eb0f1 to pick dext matching bundle identifier com.mycompany.mydrvApp.mydrv kernelmanagerd Picked matching dext for bundle identifier com.mycompany.mydrvApp.mydrv: Dext com.mycompany.mydrvApp.mydrv v1 in executable dext bundle com.mycompany.mydrvApp.mydrv at /Library/SystemExtensions/DC2F3964-043D-445E-A6CF-A9D7C529B39A/com.mycompany.mydrvApp.mydrv.dext kernelmanagerd Launching dext com.mycompany.mydrvApp.mydrv com.mycompany.mydrvApp.mydrv 0x100010a85 e675cb5ca6b6650163cc231c6af2f7e730b56b0bf394b857ce76f8e3105eb0f1 kernel DK: com.mycompany.mydrvApp.mydrv[15788] has team identifier L86BQ63GK2 kernelmanagerd Launching driver extension: Dext com.mycompany.mydrvApp.mydrv v1 in executable dext bundle com.mycompany.mydrvApp.mydrv at /Library/SystemExtensions/DC2F3964-043D-445E-A6CF-A9D7C529B39A/com.mycompany.mydrvApp.mydrv.dext kernel kernel DK: mydrv-0x100010a81: provider entitlements check failed kernel DK: IOUserServer(com.mycompany.mydrvApp.mydrv-0x100010a81)-0x100010a8a::exit(Entitlements check failed) What am I missing for the check to pass? Here is my mydrv.entitlements file: I tried adding IOPCIPrimaryMatch with my vendor id in info.plist, but with same result. Developer mode is on and SIP is disabled. Thanks

Hello everyone, We are migrating a KEXT storage driver to DriverKit. In our KEXT, we use a "one LUN = one Target" model and successfully create multiple targets in a loop during initialization. We are now trying to replicate this architecture in our DEXT. The issue is that only Target 0 is fully probed and mounted. For Target 1, the lifecycle silently stops after the first TEST UNIT READY command is successfully acknowledged. The macOS SCSI layer never sends any subsequent probe commands (like INQUIRY) to this target. The failure sequence for Target 1, observed from our logs (regardless of whether Target 0 is created), is as follows: AsyncCreateTargetForID(1) -> UserInitializeTargetForID(1) (Succeeds) UserProcessParallelTask(Target: 1, Opcode: TUR) (Succeeds) The DEXT correctly acknowledges the TUR command for Target 1 by returning kSCSITaskStatus_CHECK_CONDITION with UNIT ATTENTION in the Sense Data (Succeeds) <-- Breakpoint --> UserProcessParallelTask(Target: 1, Opcode: INQUIRY) (Never happens) Through log comparison, we have confirmed that the DEXT's response to the TUR command for Target 1 is identical to the successful KEXT's response. We have tried creating only Target 1 (skipping Target 0 entirely), but the behavior is exactly the same -> the probe still stalls after the TUR. We initially suspected a race condition caused by consecutive calls to AsyncCreateTargetForID(). We attempted several methods to ensure that targets are created sequentially, such as trying to build a "creation chain" using OSAction completion handlers. However, these attempts were unsuccessful due to various compilation errors and API misunderstandings. In any case, this "race condition" theory was ultimately disproven by our experiment where creating only Target 1 still resulted in failure. We would like to ask two questions: Is our inability to have a Target ID greater than 0 fully probed by macOS a bug in our own code, or could there be another reason we are unaware of? If we do indeed need a "one-after-another" creation mechanism for AsyncCreateTargetForID, what is the correct way to implement a "chained creation" using OSAction completion handlers in DriverKit? Thank you for any help or guidance. Best Regards, Charles

Hi all, We are migrating a SCSI HBA driver from KEXT to DriverKit (DEXT), with our DEXT inheriting from IOUserSCSIParallelInterfaceController. We've encountered a data corruption issue that is reliably reproducible under specific conditions and are hoping for some assistance from the community. Hardware and Driver Configuration: Controller: LSI 3108 DEXT Configuration: We are reporting our hardware limitations to the framework via the UserReportHBAConstraints function, with the following key settings: // UserReportHBAConstraints... addConstraint(kIOMaximumSegmentAddressableBitCountKey, 0x20); // 32-bit addConstraint(kIOMaximumSegmentCountWriteKey, 129); addConstraint(kIOMaximumByteCountWriteKey, 0x80000); // 512KB Observed Behavior: Direct I/O vs. Buffered I/O We've observed that the I/O behavior differs drastically depending on whether it goes through the system file cache: 1. Direct I/O (Bypassing System Cache) -> 100% Successful When we use fio with the direct=1 flag, our read/write and data verification tests pass perfectly for all file sizes, including 20GB+. 2. Buffered I/O (Using System Cache) -> 100% Failure at >128MB Whether we use the standard cp command or fio with the direct=1 option removed to simulate buffered I/O, we observe the exact same, clear failure threshold: Test Results: File sizes ≤ 128MB: Success. Data checksums match perfectly. File sizes ≥ 256MB: Failure. Checksums do not match, and the destination file is corrupted. Evidence of failure reproduced with fio (buffered_integrity_test.fio, with direct=1 removed): fio --size=128M buffered_integrity_test.fio -> Test Succeeded (err=0). fio --size=256M buffered_integrity_test.fio -> Test Failed (err=92), reporting the following error, which proves a data mismatch during the verification phase: verify: bad header ... at file ... offset 1048576, length 1048576 fio: ... error=Illegal byte sequence Our Analysis and Hypothesis The phenomenon of "Direct I/O succeeding while Buffered I/O fails" suggests the problem may be related to the cache synchronization mechanism at the end of the I/O process: Our UserProcessParallelTask_Impl function correctly handles READ and WRITE commands. When cp or fio (buffered) runs, the WRITE commands are successfully written to the LSI 3108 controller's onboard DRAM cache, and success is reported up the stack. At the end of the operation, to ensure data is flushed to disk, the macOS file system issues an fsync, which is ultimately translated into a SYNCHRONIZE CACHE SCSI command (Opcode 0x35 or 0x91) and sent to our UserProcessParallelTask_Impl. We hypothesize that our code may not be correctly identifying or handling this SYNCHRONIZE CACHE opcode. It might be reporting "success" up the stack without actually commanding the hardware to flush its cache to the physical disk. The OS receives this "success" status and assumes the operation is safely complete. In reality, however, the last batch of data remains only in the controller's volatile DRAM cache and is eventually lost. This results in an incomplete or incorrect file tail, and while the file size may be correct, the data checksum will inevitably fail. Summary Our DEXT driver performs correctly when handling Direct I/O but consistently fails with data corruption when handling Buffered I/O for files larger than 128MB. We can reliably reproduce this issue using fio with the direct=1 option removed. The root cause is very likely the improper handling of the SYNCHRONIZE CACHE command within our UserProcessParallelTask. P.S. This issue did not exist in the original KEXT version of the driver. We would appreciate any advice or guidance on this issue. Thank you.

I created a custom class that inherits from IOUserSCSIPeripheralDeviceType00 in the DriverKit SCSIPeripheralsDriverKit framework. When I attempted to send a vendor-specific command to a USB storage device using the UserSendCDB function of this class instance, the function returned the error: kIOReturnNotPrivileged (iokit_common_err(0x2c1)) // privilege violation However, when using UserSendCDB in the same way to issue standard SCSI commands such as INQUIRY or Test Unit Ready, no error occurred and the returned sense data was valid. Why is UserSendCDB able to send standard SCSI commands successfully, but vendor-specific commands return kIOReturnNotPrivileged? Is there any required entitlement, DriverKit capability, or implementation detail needed to allow vendor-specific CDBs? Below are the entitlements of my DriverKit extension: <dict> <key>com.apple.developer.driverkit.transport.usb</key> <array> <dict> <key>idVendor</key> <integer>[number of vendorid]</integer> </dict> </array> <key>com.apple.developer.driverkit</key> <true/> <key>com.apple.developer.driverkit.allow-any-userclient-access</key> <true/> <key>com.apple.developer.driverkit.allow-third-party-userclients</key> <true/> <key>com.apple.developer.driverkit.communicates-with-drivers</key> <true/> <key>com.apple.developer.driverkit.family.scsicontroller</key> <true/> </dict> If there is any additional configuration or requirement to enable vendor-specific SCSI commands, I would appreciate your guidance. Environment: macOS15.6 M2 MacBook Pro

Hello I'm testing an 'age range sharing' feature using the AgeRangeService API in an app we service. I approved 'Age Sharing' during testing. (For your information, my account is an adult account.) For repeat testing, I would like to delete the our app from 'Apps that requested user age information' or cancel the sharing status. However, there doesn't seem to be such a feature. Is there a way I can't find, or is this a feature that Apple doesn't offer?

How does VMWare access USB devices without have any specifics of the USB device? Does it use the same profile/entitlement process or does it take a different approach?

Investigating a kernel panic, I discovered that Apple Silicon Panic traces are not working with how I know to symbolicate the panic information. I have not found proper documentation that corrects this situation. Attached file is an indentity-removed panic, received from causing an intentional panic (dereferencing nullptr), so that I know what functions to expect in the call stack. This is cut-and-pasted from the "Report To Apple" dialog that appears after the reboot: panic_1_4_21_b.txt To start, I download and install the matching KDK (in this case KDK_14.6.1_23G93.kdk), identified from this line: OS version: 23G93 Kernel version: Darwin Kernel Version 23.6.0: Mon Jul 29 21:14:04 PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T8122 Then start lldb from Terminal, using this command: bash_prompt % lldb -arch arm64e /Library/Developer/KDKs/KDK_14.6.1_23G93.kdk/System/Library/Kernels/kernel.release.t8122 Next I load the remaining scripts per the instructions from lldb: (lldb) settings set target.load-script-from-symbol-file true I need to know what address to load my kext symbols to, which I read from this line of the panic log, after the @ symbol: com.company.product(1.4.21d119)[92BABD94-80A4-3F6D-857A-3240E4DA8009]@0xfffffe001203bfd0->0xfffffe00120533ab I am using a debug build of my kext, so the DWARF symbols are part of the binary. I use this line to load the symbols into the lldb session: (lldb) addkext -F /Library/Extensions/KextName.kext/Contents/MacOS/KextName 0xfffffe001203bfd0 And now I should be able to use lldb image lookup to identify pointers on the stack that land within my kext. For example, the current PC at the moment of the crash lands within the kext (expected, because it was intentional): (lldb) image lookup -a 0xfffffe001203fe10 Which gives the following incorrect result: Address: KextName[0x0000000000003e40] (KextName.__TEXT.__cstring + 14456) Summary: "ffer has %d retains\n" That's not even a program instruction - that's within a cstring. No, that cstring isn't involved in anything pertaining to the intentional panic I am expecting to see. Can someone please explain what I'm doing wrong and provide instructions that will give symbol information from a panic trace on an Apple Silicon Mac? Disclaimers: Yes I know IOPCIFamily is deprecated, I am in process of transitioning to DriverKit Dext from IOKit kext. Until then I must maintain the kext. Terminal command "atos" provides similar incorrect results, and seems to not work with debug-built-binaries (only dSYM files) Yes this is an intentional panic so that I can verify the symbolicate process before I move on to investigating an unexpected panic I have set nvram boot-args to include keepsyms=1 I have tried (lldb) command script import lldb.macosx but get a result of error: no images in crash log (after the nvram settings)

I have two different USB devices with different vendor IDs I would like to connect to. I submitted two separate requests for the com.apple.developer.driverkit.transport.usb entitlement for each vendor ID. However I am noticing the provisioning profile only has one of the vendor IDs. How do I submit a request for the USB Transport entitlement to support more than one vendor ID? I'm new to writing a DriverKit driver, so is this even possible?

We are looking for a solution (API, Frameworks) that would allow us to block any type of external device, including storage devices, HIDs, network adapters, and Bluetooth devices according with dynamic rules that comes from management server . This feature is important for endpoint security solutions vendors, and it can be implemented on other platforms and older versions of macOS using the IOKit framework and kexts. I have found one solution that can control the usage only of "storage" devices with the EndpointSecurity framework in conjunction with the DiskArbitration framework. This involves monitoring the MOUNT and OPEN events for /dev/disk files, checking for devices as they appear, and ejecting them if they need to be blocked.. Also, I have found the ES_EVENT_TYPE_AUTH_IOKIT_OPEN event in EndpointSecurity.framework, but it doesn't seem to be useful, at least not for my purposes, because ES doesn't provide AUTH events for some system daemons, such as configd (it only provides NOTIFY events). Furthermore, there are other ways to communicate with devices and their drivers apart from IOKit. DriverKit.framework does not provide the necessary functionality either, as it requires specific entitlements that are only available to certain vendors and devices. Therefore, it cannot be used to create universal drivers for all devices, which should be blocked. Any advice would be greatly appreciated!

I am trying to open the CommunicationControl class IOUSBHostInterface in my USB driver, but it only seems to open on iPad Airs and not iPad Pros. I'm calling ivars->interruptInterface->Open(this, 0, NULL); After retrieving the interruptInterface from the device's InterfaceIterator. I try and open this, but on iPad Pros it returns kIOReturnNotOpen. I've tried closing and reopening the IOUSBHostDevice, closing and reopening the Interface, AbortDeviceRequests before opening, etc. but it just seems to work on iPad Air and not iPad Pro. I've tried on both iPadOS 17.6.1 and 18.2 Has anyone else seen this?

I've asked this question in Stackoverflow, but no response, so I ask for help in here. I follow this guide Debugging and testing system extensions, and try to debug my dext code. In the Attach the debugger to your system extension, it said After your system extension launches, run the ps command-line tool and note your extension’s process ID. This is the current output for my dext status % systemextensionsctl list 1 extension(s) --- com.apple.system_extension.driver_extension enabled active teamID bundleID (version) name [state] * * K3TDMD9Y6B com.accusys.scsidriver (1.0/1) com.accusys.scsidriver [activated enabled] and I used the ps command but nothing happen, I can not get my extension’s process ID. ps aux | grep com.accusys.scsidriver or ps -ef | grep com.accusys.scsidriver How to do that? Any suggestion is appreciated.

Firstly, I realise that Kexts are deprecated. And for my needs, user-space IOKit from an application might be more than I’ll ever need, but I can’t help ensuring I’ve got all my ducks in a row while I’m designing an app. I noticed in the above Kext deprecation notice that it’s more about specific APIs that are deprecated rather than the kext mechanism itself (no mention of IOKit kernel APIs there). Along with the fact that a reboot would be required and various other policy changes. While reading up on System Extensions and the various newer tools, DriverKit, Endpoint Security etc, I’ve noticed there’s no mention of this “IOKit Driver” target/deliverable in the Xcode template chooser. It looks like, from the requirements, that DriverKit is aimed at hardware manufacturers, with a need to request the DriverKit entitlement for development. With respect to Apple’s internal Kext deprecation roadmap, how safe is it to build a product that relies on using an IOKit Driver and are there any requirements similar to DriverKit? Would a developer need to request an entitlement? If I developed an app using user-space IOKit and, for illustration purposes let’s say I also included an IOKit Driver in the app bundle. If I used the IOKit API, including header file constants only (no digging around in the IORegistryExplorer for non-public keys), as Apple intends them to be used, would this fall foul of any App Store rules that anyone is aware of? Put another way, would making use of an IOKit Driver disqualify my app from being distributed via the App Store, similar to an Endpoint Security extension? As an aside, there are a lot of API in the ES Framework that could be used to build apps that have nothing to do with Endpoint Security. File system related apps for example. It’s a shame there isn’t an enhanced middle ground between FSEvents and Endpoint Security framework.

Hey, I'currently working on a Driver (and its App) for iPadOS (USB Device). I think have the right entitlements, as my driver gets installed with the app properly (after accepting it in the settings). It also gets loaded once the device is plugged in and so on. However the Kernel is not using the updated Version after I install a new Version of App and Driver to the iPad (at least most of the times). I'm verifying this by reading out the Logs via Console and the Driver prints its Build number on Start(). Sometimes it works like it should but I found no pattern. As far as I understand the iPad should automatically install the new Version of the Driver with the new App if its Build is different from the current one. I'm incrementing the Build of App and Driver automatically post-build so each build the iPad gets has its own Build number (This also works). Steps to reproduce: Cleaning Xcode Build Folder Unplugging the USB Device from the iPad. Building and Installing a new Version of the Driver and the App via Xcode (making sure the build number has changed) Plugging the USB back into the iPad Reading Console output of the iPad However it works (each time if I: Uninstall the app from the iPad manually or via Devices in Xcode Build and install the App via Xcode Open the Settings App and activate the Driver But uninstalling the App each time is taking a lot of time and manual Steps so I would like to fix this issue. Do you have any Ideas? Thanks, Bjarne

Two apps were built by different teams for the same account. One app disabled the network permission, and the other app could not access the network