Deceptively, the here described image "disappearance" phenomenon may seemingly represent no more than an insignificant, minor issue, which *only* seems to occur when at least four "simultaneous" conditions are fulfilled : [1:] dealing with a newly attached picture ( meaning uploaded after 2024.04.02.Tu.), [2:] the upload was achieved from Airtable's mobile app for i[Pad]OS, and [3:] we are attempting to fully open the new picture in again Airtable's mobile app for i[Pad]OS, [4:] after having stepped out of the given record, been elsewhere, then returning to the new imagery.
OK, this is about the currently happening and most unfortunate resurging of an earlier problem, dating from nine months ago actually, then and now again regarding New Picture Attachments in Airtable on i[Pad]OS – so in fact this is about an utterly, truly undesirable and unexpected revival of what we already had to describe mid last year, when we elaborately reported on it in :::
Very Strange "Disappearing Picture Attachment" on iOS & iPadOS – BigBen case 2023.07
Also see a more concise description of what's happening in :: 3. On iOS, newly attached pictures fail since April 2, 2024 [AShoAP]
Further detail and Giraffe example are herebelow.
At the current bleeding edge of time, meaning as of early April 2024, we can – with the reappearance of the given formerly solved problem, and for further clarity – now add a very similar, but intentionally slightly different scenario to demonstrate the fundamentally same malfunction as last year, since apparently this darn annoyance seems to have resurfaced in an equally easily reproducible way as we stumbled on nine months ago.
So for instance we can start-out again from a base, created for testing purposes from the "Balloon Adventure" template, where at base creation time we decide to keep ( or "include") the example records exactly as originally provided. From there onward, we can proceed our test case as follows. :::
1️⃣ Let's look into the "Friends" table of our Balloon Adventure, where for a demo item we can take the Geoffrey giraffe record.
2️⃣ From the thumbnail in the Pics field of the Geoffrey record, we can open up "giraffe.png". → We are positively OK thus far, if we've got a clear and crisp popped-open giraffe image on our device screen at this point.
3️⃣ The opened image has a 19h Share button, from which we can, and in this scenario we do "Save Image", by which we copy what is represented on our device screen toward the local i(Pad)OS PhotoRoll. After this, we close the on-screen original picture, and we find ourselves back with the Geoffrey record where the thumbnail still resides that we started from in the previous step.
4️⃣ Next, or "immediately" in fact without even leaving the Geoffrey record, we "in-place" re‑add our just saved giraffe image into the very same record, by hitting the latter's "mountain view" icon, and by then proceeding for what supposedly will be just a duplicate of the image already attached originally. (_OK, you might say this makes no sense or it's a really silly thing to do, since we already have this very picture in the given record, but read on, because this positively will serve as a most appropriate action in our context of a clearly reproducible testing scenario. )
5️⃣ If all went as expected, we now see our newly added picture appearing as a new thumbnail, probably sitting upfront in the given field, and named (e.g.) "2023...39.jpg".
6️⃣ At this point, just for verification, let's take a good look into our freshly added duplicate image, so we open it up for fully revealing it so as to effectively check out our freshly added "2023...39.jpg" (e.g.), right away while we're at it in AirTable.
7️⃣ Well Lo And Behold – 🅰️ our newly uploaded copy looks fuzzy and blurred, it is not by far as crisp and sharp as the original image was ( and still is, when we go look into that one ) that we started from.
8️⃣ Not finished yet, because from here, upon now twice leaving the record and returning to it, 🅱️ the detail image will totally go black, it will totally vanish and be gone.
9️⃣ Nonetheless the Preview "Thumb" remains perfectly visible throughout.
🔟 Here's a final step. From the darn "empty" .jpg in AirTable, we can [1:] again "Save Image", subsequently [2:] go look at the result on the iOS PhotoRoll – from outside AirTable, that is – and [3:] surprisingly perhaps, at this point in this second saved image of ours, we can see a perfectly sharp and clear giraffe – this definitely being outside_of, but positively fresh- downloaded_from AirTable because we share-saved our there lately uploaded, next initially in Airtable blurred and then no longer visible image except as thumbnail.
1️⃣1️⃣ The very strange parts are in steps 7️⃣, 9️⃣ and 🔟, but then what or where is the actual culprit ?
I wonder whether other, more people who might be running or checking the Airtable app on iPhone or on iPad can confirm the recent resurge of this imagery problem ? This is not an "imaginary" problem, is it ? With the progress of time, the question will evolve to whether this almost blatant malfunction can ever get re-resolved, or is the Apple mobile ecosystem simply somehow not fit to this part of the task at hand ?
Finally, to end this lamentation : again, how many are we, in the known universe, to face this (at present) apparently incurable problem with Airtable's app on i[Pad]OS ? Already I'm not the only one to have detected this, but perhaps the majority of all others might have moved on to Android meanwhile, where no such issue regarding Airtable's picture handling would seem to ever have existed at all.
( I've also sent e.mail to AirTable-Support regarding the resurge of this problem. )
