Cloud September 18, 2026

Organization admins can now configure host machine settings for every machine from one Settings dialog at the top of Device Management. The per-machine Settings button has been removed from host machine rows.

The Max Parallel Tests tab sets a capacity limit of Unlimited or a custom value between 1 and 999 for each host machine. An All Machines row applies one setting to every machine at once.

Organizations subscribed to virtualUSB also get a virtualUSB tab. Enable virtualUSB per host machine, choose whether routing is managed by Kobiton or self-managed, and set the connection address. Enabling virtualUSB no longer requires a request to Kobiton Support.

Host machines with virtualUSB enabled now show a virtualUSB badge on their row in Device Management.

The host machine settings dialog on Device Management now lists the same host machines as the page itself. Previously, the dialog could show several rows for one host machine (same name, same IP), so a search inside the dialog returned more results than the page. A search by host machine name or IP now returns the same result in the dialog and on the page.

Settings saved from the dialog now apply to the host machine shown on Device Management. Because each duplicated row carried its own values, a Max Parallel Tests limit or a virtualUSB setting could previously be saved against a row that matched no host machine on the page.

Applies to the host machine list under both the Max Parallel Tests and virtualUSB tabs.

A new Device Inventory report is available under Analytics Reports in the Portal. The report lists every device connected to the organization.

Filter by Status, OS, Version, Device Name, Manufacturer, or Device Model. Version narrows to the selected OS, and Device Model narrows to the selected Manufacturer.

Use the table’s search box to filter by any column value, including team. The search box matches literal text; wildcards like * are not supported.

A new Retained Devices report is available under Analytics Reports in the Portal. It lists retained devices, who retained them, how long each device has been retained, and the last time each device was used. Results sort by Last Used, with the longest-idle devices at the top.

Filter by Retained by email or UDID, and use the table’s search box to filter by team. Wildcards are not supported.

A manual or automation session on an iOS device that cannot source high-quality video now falls back to screenshot-based recording, so the session ends with a video attached to its detail page. Previously, sessions on an affected device ended with no recording, and the session detail page had no video.

Generated PIN passcodes no longer contain a run of three digits that each differ by 1, such as 123, 321, 232, or 565. Previously, only straight runs were blocked (123, 321), so a generated PIN could contain an up-and-down pattern (232) that a mobile device management (MDM) passcode policy rejected. When MDM refused the passcode, the device stayed on the update-passcode prompt and could go offline.

The same rule applies to a PIN submitted through the API: POST /devices/{deviceId}/passcode/verify now returns 400 for a PIN with such a run, where it previously accepted it.

Apps whose latest version is still processing, or whose most recent upload failed to parse, now return normally from the App Repository REST APIs and the MCP getApp tool. GET /v2/apps/{id}, GET /v1/apps/{id}, and the MCP getApp tool return the app with no latest version. Previously, these requests returned HTTP 500.

Uploading a valid build to such an app now parses successfully and becomes the app’s latest version. Previously, the valid upload was marked as a parse failure, and the app could not recover from a broken first upload.

Starting an automation session with app: kobiton-store:<id> on such an app returns "App <id> has no ready version to install," instead of the earlier "App ID <id> not found."

In manual sessions, biometric authentication requests could time out after roughly 60 seconds on every attempt, leaving the application under test stuck in its waiting state. Biometric requests now return without delay on iOS 15 through 27, so the application receives the Pass or Fail response and the session continues.

queryAppState on iOS 12, 13, and 14 now returns 4 for a foreground application. Previously, it returned 1 (installed, not running) while the application was visibly interactive, so scripts that gated on foreground state could stall.

Portal 2609.16

Gigacap 2609.14