Player component for iOS - bugs

I just tested it with a perfectly looped sound. It works perfectly, even in the background. Tested with Companion 2.64.6 and the compiled app (IPA).
Thank you so much!

Another important note:
Seamless looping now also seems to work for compressed audio formats (accepted by Apple / iOS such as M4A, AAC, MP3, ...).

I have no idea since which iOS version this has been possible, as I have always had to use the IM4A (caf) format in Xcode/Swift. This is of course a big advantage because it makes app packages significantly smaller.

If I download a sound like this, I get this path with which the sound can be played without any problems. This path doesn't change with Companion when I repeat this process. However, with the compiled app (IPA) that doesn't seem to be the case. At least not when I reinstall the IPA (ad hoc).

How can I find out if the file already exists or gets a new path when the app is reinstalled. Unfortunately, the File component (File.Exists) doesn't work with iOS (as many other methods also don't work)?

/private/var/mobile/Containers/Data/Application/77E6D664-136A-4501-BDE4-97596C422A1E/tmp/Musik-1.m4a
(The path is almost the same with the IPA.)


The file/storage system is even more mysterious on iOS than Android. :wink: :upside_down_face:

I usually package all the required (audio/media) files into the assets (i.e. the app package), but in this case I want to avoid it, otherwise I would have to re-sign the app (aia limit: 30 MB) via "codesign" / Xcode. So some files have to be downloaded when you first start the app.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.

Since you store the pathname in TinyDB, it seems like you would just need to check if that key is present or not to determine whether the download succeeded on future runs. We will work on making the File component maximally compatible with the Android version, but it seems like this problem can be solved without adding an implementation of File.Exists on the critical path.

The path stored in TinyDB is present, but this path no longer seems to work with the IPA after a reinstallation (ad hoc). I conclude that this file (i.e. the downloaded m4a file) no longer exists. The download process would have to be repeated in this case. And to be able to check this, I only see 2 options:

  1. There is a way to check this via the File component (File.Exists) or
  2. If the sound is not playing (if Player.IsNotPlaying, download...).

Interesting. Naturally, I expect that a reinstallation would result in a different UUID for the sandbox, so the stored file name in TinyDB wouldn't be valid. But TinyDB itself is a file stored in the sandbox so in theory a reinstallation should result in it being cleared (which would trigger a re-download). I will review the File component and see what resources we have to bring it more current with the Android functionality.