When you mix the fact that WebP is not supported on iOS (there is a note here that points to some good news on that front, but hey, that good news is from 2016 and it hasn’t materialized yet!) and the way Cloudflare handles caching at the edge, it can perhaps help you solve the puzzle.
Cloudflare will only cache an asset that’s been requested at one of its data centers, and only there for the duration of the Edge TTL (sometimes less). So you can easily imagine a situation where, if your origin has an optimization plugin that generates WebP based on the visitor’s user agent, different versions of the HTML will be cached by different CF data centers.
For instance, you visit your site with Chrome for desktop, it accepts WebP, an HTML page with links to images in that format, and the images themselves, are cached at the CF data center that proxied that visit. You go back there with iOS and bam! no images to display.
Another visitor from a different location (or simply using a different ISP) may visit your site though another CF data center, the HTML hasn’t been cached yet, and the device doesn’t support WebP, the origin generates a slightly different HTML, with JPEG instead of WebP images. This is probably why @Jake1st and I were able to see the images on iOS when you couldn’t. We got to your website through different Cloudflare data centers!
So it wouldn’t be enough to wipe your own cache, you’d need to purge the cache from Cloudflare each time, which is obviously not an ideal setup. The alternatives are either to stop WebP generation at the origin or to not proxy images through Clouflare. Since Cloudflare sits between your visitors and your origin, it can distinguish between visitors UAs and serve the appropriate image format, but for that you’d need to enable Polish, available on Pro Plan or higher. Then Cloudflare will generate and cache WebP images for the use of browsers that do support it.