AudioPlayer.seek() fails on iOS when passing float values to timeInSeconds parameter

[mikirby]

Description

The AudioPlayer.seek() method fails on iOS when passing floating-point values to the timeInSeconds parameter, even though the TypeScript interface accepts number type.

Steps to Reproduce

1. Import the plugin (e.g., import { AudioPlayer } from '@mediagrid/capacitor-native-audio';)
2. Create & initialize an audio instance, add listeners (optional), then play.
3. Call await AudioPlayer.seek({ audioId: 'my-audio', timeInSeconds: 187.909 })
4. On iOS, this fails with the error: "There was an issue seeking the audio."
5. Calling with an integer value like 188 works fine

Expected

Seeking to a fractional second should work (or be rounded consistently) since the TS type is number.

Actual

Float values fail on iOS; integers succeed.

Suspected Root Cause

In ios/Sources/AudioPlayerPlugin/AudioPlayerPlugin.swift, timeInSeconds is read with call.getInt("timeInSeconds"), which returns nil for non-integers — causing the generic error path instead of a specific invalid-time error.

Suggested Fix (Option A - accept fractional seconds)

Read as Double and convert:

guard let timeInSeconds = call.getDouble("timeInSeconds") else {
    throw AudioPlayerError.invalidSeekTime
}
let target = Int64(timeInSeconds) // or floor/round as desired

Alternative (Option B - integers only)

If only integers are intended, update the docs and the TS type/JS wrapper to enforce integers. I'm happy to submit a docs/types PR if this is the desired API.

Workaround

Round before calling:

await AudioPlayer.seek({
  audioId: 'my-audio',
  timeInSeconds: Math.round(seekToTime),
});

Environment

• Plugin version: @mediagrid/capacitor-native-audio 2.3.0
• iOS Deployment Target: 15.6
• Tested on: iPhone 7, iOS 15.8.5
• Capacitor version: 7.4.3
• Android: not tested

Logs

"There was an issue seeking the audio."

Willing to open a PR?

Yes. I can submit a PR for Option A (accept Double) and add a brief note to the README/API section clarifying rounding behaviour. Please advise whether you prefer rounding vs truncation for fractional seconds.

[wsamoht]

Thanks for bringing this up! In our app we round to an int on the JS side so I never ran into this. I am not opposed to supporting a decimal/double as long as both Android and iOS can support it.