Start a new topic

Caching of remote JS Experience AR View files

Caching of JS AR View Experience files

I have some issues with external files being cached, basically our work flow is like this

1) Export complete working projects in Wikitude Studio

2) Copy the JS experience files to our cloud hosting service (AWS S3)

Inside the index.html file generated by Studio the are meta tags specifying cache control.

<!-- disable caching -->

<meta http-equiv="cache-control" content="max-age=0" />

<meta http-equiv="cache-control" content="no-cache" />

<meta http-equiv="pragma" content="no-cache" />

<meta http-equiv="Expires" content="-1">

We are using the Cordova Plugin and SDK V 8.9.1. We load the experience as such:

    arExperienceUrl: "",

    requiredFeatures: [ "image_tracking", "geo" ],

    isDeviceSupported: false,



        "camera_position": "back"




    onDeviceSupported: function() {









Whenever I modify the index.html or any JS files inside the experience bundle such as template.js, the changes are not being picked up between world loads, even restarting the app (Android 10 /iOS 13.1.1) does not work. I added a custom close button which calls app.wikitudePlugin.close(); which works great to close the AR view, but the world will still load cache data. 

The only solution I have found so far works 100% is to change the directory names when content is updated and I need to force the refresh, but I need to figure out a more efficient method that works.

Is there a known solution? There is some reference to cachePolicy that can be specified during LoadARchitectWorld that I read in another post, but it's several years old now and I could not locate much supporting documentation, is the following still relevant?

loadArchitectWorldFromURL:cachePolicy:`). The value `NSURLRequestReloadIgnoringCacheData` might be interesting for you.



Hi John,

Sorry if I missed it in your explanation, but have you already tried using the clearCache method in WTArchitectView?

- Damian

Hi John,

The Studio experience is not supposed to be adapted and changed. So if you export the files from the Studio Editor, you'd have to use it as it is. Changing the Studio Editor project can have unwanted sideeffects.

If you wish to have additional functionality to the Studio Editor that the SDK is supporting (e.g. animated 3D models are not supported in the Editor but by the SDK), then you'd need to have to implement the AR experience manually using js, html. For further details on how to work with the SDK and implement the AR experiences, best is to start with the SDK sample app together with the according documentation.

Thx and greetings


Thank you so much for the prompt reply, yes, I understand you have to make a disclaimer against modification of the studio generated JS experience, but respectfully I would like to reiterate the issues I am facing are related to the unwanted caching of remote files downloaded by the AR WebView, WKWebView as I understand it to be in 8.9.  

I also realize, and please correct me if I am wrong, the caching probably has more to do with the way the web works in general in terms of conventional internet headers and browser behavior than architecture of the SDK/related plugins, after all WKWebView could technically be considered an embedded browser of sorts, and I can see the output from Studio JS experience files by default includes metadata to discourage caching in the source of index.html, e.g., 

<meta http-equiv="cache-control" content="max-age=0" />

<meta http-equiv="cache-control" content="no-cache" />

<meta http-equiv="pragma" content="no-cache" />

<meta http-equiv="Expires" content="-1">

Seems like this is not being honored by WKWeBView. I'm experimenting with adding actual cache headers, e.g., Cache-Control: max-age=0 in the server response (this is achieved by adding metadata key value pairs in S3), and easily achieved with any popular web server seems to keep the content from caching in WKWeBView, still need to test more but iOS 13.1.2 and iPhone 11 which is my latest greatest test device this seems to work OK so this might be the answer for me.

In my case, I'll need to figure out how to handle all this at scale and the obvious issue with simply changing the directory names to create an intentional miss from cache is that you increase cache size until you could eventually reach app instability, or become an easy target for deletion as users will often choose apps to remove based on usage size. 

Hi John,

I assigned your post to our technical team and they will get back to you with further details once they're on their task to work on forum support.

Thx and greetings


Login or Signup to post a comment