iOS video search SDK: Swift integration and reported field latency
The iOS video search SDK gives an Apple application typed access to media search while leaving its interface and session ownership in Swift. This guide follows the v1.2.6 package and README. It covers SwiftPM setup, collection scope, search and image retrieval, then separates reported iPhone timings into the stages a user actually experiences.
Updated:
Add the iOS video search SDK through SwiftPM
The pinned Package.swift declares the VModalSDK library product and iOS 16 and macOS 13 platform floors. Add the repository through Xcode’s package dependency flow, select v1.2.6 and attach that product to the application target. Use the tagged manifest and the repository’s toolchain checks together: a package’s tools-version declaration and the maintainer’s recommended Xcode installation describe different constraints.
The setup line below identifies the repository rather than presenting an uncompiled application fragment. The README contains complete Swift examples for configuration, search and upload. Keep those examples aligned with the selected package version. If package resolution or the example build fails, diagnose that stage before adding network credentials or attempting to reproduce device latency observations.
https://github.com/v-modal/vmodal_sdk_swift_iphoneduoReference: v1.2.6 README.md, SwiftPM repository URL; select exact version 1.2.6 in Xcode
Configure the project and search the right collection
The Swift README constructs a project from a runtime API-key provider and retains a scope for a collection and stream. Credentials belong to the authenticated app, while the scope describes the content being addressed. The example discovers available collections before searching. That check is useful when a familiar logical name belongs to a different account or environment.
Search is asynchronous and returns structured data with raw JSON preserved for evolving fields. Keep the selected project, collection and stream alongside the request. When a view or session changes, avoid applying an old response to a new collection’s screen. Choose query options from the pinned Swift types instead of assuming that another SDK exposes identical source-selection values.
Retrieve frames and keep playback context
A result list needs more than a relevance-ranked row. Resolve frame images using the package’s documented image resources, preserving the originating scope. Present source identity and time context with each tile, then let the user inspect the matching moment in the recording. A returned frame can be irrelevant to the requested scene, so include human review in the interface.
Loading images is a separate stage after the search response. Keep metadata visible if an image request fails, and refresh expired image URLs through another lookup. Treat a timestamp used for playback as data, not just a formatted caption. Check that selecting a result seeks to the intended source position and that neighboring frames give enough context to judge the candidate.
iPhone Duo and native lifecycle ownership
The repository’s iPhone Duo notes focus on keeping SDK and upload ownership independent of changing window geometry, scenes and split layouts. Adapt your view state around those lifetimes rather than rebuilding a project whenever a view is redrawn. Update visible progress on the appropriate UI actor and let a retained operation report completion to the session that started it.
The app owns photo selection, credential persistence and background scheduling. The README describes cancellation, streamed upload progress and explicit project closing. During logout, cancel active operations and clear the relevant state before creating the next identity’s project. Key rotation alone does not switch collections or accounts. Test a scene change while an upload is active instead of relying only on a stationary demo screen.
Reported field latency: iPhone 13 mini over 5G
A community author reports 21 searches on a physical iPhone 13 mini over 5G, using the same index and a result limit of 30. The phone was in the Canary Islands, and the team identified the server as being in Japan. Across three queries, the reported medians ranged from 49–56 ms for server execution, 391–426 ms for the SDK search call and 1,053–1,151 ms for subsequent frame retrieval.
The SDK call already includes server execution. Frame retrieval follows that call, and final UI rendering was not measured. The screenshots were from Simulator; the timings were from the physical phone. These observations describe one test setup, not a guaranteed SLA. The author also describes an irrelevant-query result, a useful reminder to evaluate match quality as well as speed.
Build an evaluation that explains the whole experience
For your own device trial, keep upload, indexing readiness, search response, frame retrieval and final display as distinct milestones. Use a known recording and note the collection state, query, result limit, phone and network. Compare repeat runs under the same conditions before attributing a difference to the SDK. A quick backend response does not by itself describe the time until a useful image is visible.
Include cancellation, empty results, an expired frame URL and account switching in the acceptance flow. Confirm that a selected frame opens the correct recording and that the UI does not retain a previous user’s results. When seeking help, supply the package tag and the stage that failed. That gives the team a concrete reproduction path without turning one community measurement into a product promise.