Hi, we are aware of the issue and have fixed it; it should be resolved in the next version. The problem was caused by a bug in the iOS 18 beta. We advise using stable OS versions.

@MetalAnon
Hi, could you tell us what iOS version and what Apple device you are using? Does the error happen every time you open radar layer? Does it also happen on the satellite layer?

Thank you!

Hi @alanduckers,

the Radar+, Radar, and Satellite layers use the same data. The difference is that Radar+ also performs the mentioned extrapolation of past satellite data. However, this extrapolation does not apply to radar data in the Radar+ due to technical constraints. As a result, and because radar providers can experience delays, you may notice that radar and satellite data do not always sync correctly in the Radar+ layer. For example, in the UK, the radar data currently lacks the most recent timestamp. Regarding the strange patterns, these might be caused by satellite data outages that are compensated for through extrapolation.

@AlanTheBeast Hi, we already discussed with colleagues about this topic (whether to extrapolate when smooth animation is turned off). Both approaches make sense in their way, but in the end, we'll probably implement it in the future :)

@AlanTheBeast Hi, the reason why the futurecast is not working for you is because of Smooth radar and satellite animation setting is turned off (you can change this in settings). The current implementation does not support extrapolation when smooth animation is turned off.

@AlanTheBeast
Hi, thank you for the report. Could you answer us a few questions on that?

• Does it happen every time you open the radar overlay?
• Does it also happen in the satellite overlay (either with radar data (you need to enable it via overlay with radar) or even with satellite data)
• What MacOS and Safari versions are you using?
• Could you send us a short video, where you drag the timebox from past to future, so we can see, what actually happens?

Thank you very much!

@MetalAnon Hi, since the error appeared after updating the iOS version, and the version 18.7.2 (RC) is not a stable version, there is a high chance that something related to WebGL got messed up by Apple in that version. We cannot do much about it :/ We always recommend using stable OS versions to prevent these problems.

@MetalAnon
Hi, could you tell us what iOS version and what Apple device you are using? Does the error happen every time you open radar layer? Does it also happen on the satellite layer?

Thank you!

Hi @jmjm26, since Q3 2025, we have been using a new renderer for satellite overlay. We'll try our best to mitigate this issue. Thank you for your patience.

@jmjm26
Hi, thank you for the report. Could you tell us what device and system version you are using?

We are working on a solution that might resolve the problem. However, there are combinations of some types of devices (specifically low-end) and OS/SW that might struggle in computationally intensive tasks, in this case, during satellite animation.

As a workaround, I suggest stopping the animation before moving with the map.

Thank you!

@stkosel
Hi, this is a bug. Could you try some other browser, e.g. Google Chrome, since the issue could be caused by the new Firefox version. Thanks!

@smyru
Hi, since the update v47.0.0, all layers are webgl-only. Based on the information you provided, there must still be some flag that prevents usage of WebGL within your browser. All layers can run on both WebGL1 and WebGL2. Please, make sure that flags webgl.disabled and webgl.disable-wgl are set to false (in case of about:config in Firefox), and double check other flags that may block WebGL.

@rdo118
Hi, thank you for the provided information. I had an idea of what the problem could be, and the first screenshot probably confirmed it - the readPixels function used within our forecast WebGL rendering pipeline. It is mandatory within our current pipeline, which was implemented many years ago based on WebGL1, and this approach was necessary and totally valid at that time. This function (gl.readPixels) can indeed be problematic; however, it is used with care and as little as possible. However, in case of using high-res screen(s), the performance could eventually degrade. To assure you, there were no changes in the pipeline in the last 3-4 years.

We are not going to do any modifications to the old pipeline since we are already working on a new one, which does not use any of these problematic functions at all. This will take some more time, so as a temporary solution, I can advise lowering your resolution (in case you are using multiple displays or e.g., a 4 K display) or setting browser zoom to e.g. 150-200% (in Firefox it is in the hamburger menu top-right).

Thank you for your patience.