Sorry your browser is not supported!

See attached image for error message from AppGameKit Player - same error happens when I compile and install the app properly on on an iOS device. On Android however, everything is working as intended.

What happens is this, upon first run, the app will download a big list of images from a server. Then using this list it downloads via the backend a host of images from an Azure Blob. This it is then supposed to display in a nice grid fashion. Like in the second screenshot attached to this post.

Now, I do have my suspicions as to the cause, but before I go about re-juggling file handling in the server backend it'd be nice if anyone here got comments, suggestions or actually know what the h*ll iOS do not like *this* time.

---

Now, my suspicions are:

1: There is a dash in the filename (like this: dateandrandomstring-randomstring.png)

Should not be a problem as iOS filesystem is unix-based and should handle most characters in a filename apart from a few reserved ones. Which I have looked up, and dash is not on that list.

2: Too long filename and/or foldername.

Both are randomly generated by backend (well, actually by database in backend), and they are not too short. But, they're not above the 255 character limit of even older unix file-systems (and it do work on Android, Windows and Ubuntu). That said, on old iOS versions/filesystem, the max was 32 characters, but I am running newest iOS fully up to date on an iPad that is only a few months old.

---

This was working a while ago with some test-data and images that had much shorter names, and no dashes in them. Though since then I've done a lot of changes and only tested towards Android as that is more convenient...

OK, made a a little progress:

On downloading all the images, they get stored with a size of 13 bytes. Which is mucho too little for a png image.

So, having the app report what is in the file (id = opentoread(file) -> content = readstring(id) -> print(content)) it displays that the files contain the simple text "Unauthorized" plus a CR which is by no coincidence 13 characters - or bytes if you wish.

Now, the odd thing here, is that I made a simple little test-app hitting the same server with downloading just a few images from a test directory I made there. And woe and behold, that worked.

Investigating further...

Source of error found. On my server I have implemented a simple auth system - so when requesting a file the client need send user-name and password - using SetHTTPHost(http, ip.api, ip.tls, ip.user, ip.pass) in AGK. Which is fine. However on iOS for some reason, there is a limit on how far down the file-tree you can go. Actually, only one deep. Any more, and iOS spits out the error-message seen above, as the downloaded files will only have the text "Unauthorized" in them, not the actual contents one was wanting.

On Android, Windows, Linux (Ubuntu) and even MacOS this limit do not exist, I can travel up and down the file-structure on the server as much as I please. So on iOS the culprit is one of two:

1: iOS itself have a limited file-transfer library that do not allow going more than one directory deep on a remote server without losing auth.
2: AGKs GetHTTPFile() is limited on iOS, and do not allow one to go more than one directory deep on a remote server without losing auth.

That is odd, I'm not aware of any reason why iOS would fail to authenticate with sub folders in URLs. The method of authentication for username and password fields is to set the "Authorization" header in the request, which as far as I'm aware is not affected by the URL. Can you confirm if the Authorization header is present on those requests by getting the server to print out the headers? Don't paste the header contents here as the username and password are sent in base64 plain text.

Hey, I know about it and actually, it also faced by me and I actually those time just reset the phone and after that, the phone was work properly and the problem will be solved. For more canon support will help you.