I'm developing a React Native app and downloading library files into the app's file system. I have an apex class that converts the file to base64, and returns that as the result. I then call that in my app via REST API, and save the resulting file.

This was working fine when running the app against the org I developed on (Enterprise Edition), but when running it against a sandbox (Performance Edition) I deployed to, I get an error that I've exceeded the heap size limit if the file is larger than a few MB. This is with the exact same files that worked fine on my enterprise org. Why would this be the case? The docs say that there's a 6MB heap size limit, but that doesn't seem to apply to my enterprise org and it's not clear why.

I'm trying to get around this whole thing by just downloading the file directly using /sfc/servlet.shepherd/version/download/<ContentVersionID> but that only seems to work in a browser and not via a REST API call in my app. When testing it in my app and in rest explorer, it just returns some code within a script tag as the result (with a HTTP response code of 200 OK). It seems like it's trying to redirect me to the login page, so it's not authenticating properly. I've determined that this is because the web request needs a session ID, whereas the mobile SDK authentication uses oauth, and only has an access token.

Either route working would be a viable solution (although the latter method is preferred for larger files)

2 Answers 2


I have an apex class that converts the file to base64, and returns that as the result.

Salesforce does this for you already. If you query the ContentVersion SObject, the VersionData field will be returned to you as a Base64 Encoded Blob.

Try using the query() method from the Salesforce React Native SDK to access this field directly.

  • We tried that a while back actually. It doesn't work, which is why we made the apex class. When I do the query in the app, it just returns a URL like /services/data/v36.0/sobjects/ContentVersion/{ContentDocumentID}/VersionData as the value for VersionData. It doesn't return the base64 representation as expected (like it does with the exact same query in WorkBench)
    – Pedram
    Jan 23, 2017 at 21:34
  • I'll admit I only tried it in workbench. This time I gave a try with cURL on the command line, and ended up getting the body data from the URL you listed above. It was not base64 encoded, but dealing with that problem in Javascript shouldn't be bad. Are you able to try hitting /VersionData using sendRequest from react.force.net.js? Jan 24, 2017 at 5:20
  • Yes I tried that URl in both rest explorer and through sendRequest. In rest explorer I get a blank response, and through sendRequest I get {"errorCode" : "NOT_FOUND", "message" : "The requested resource does not exist"}
    – Pedram
    Jan 24, 2017 at 16:33
  • As an added note, I also tried the same url via curl, and it worked there. It just doesn't seem to want to work with sendRequest. And as a correction, I'm using the ContentVersion ID, not the ContentDocumentID
    – Pedram
    Jan 25, 2017 at 0:20

Ultimately, I opened tickets with Salesforce but didn't receive a solution as to why the Salesforce RN API calls weren't returning the appropriate file data, or why the same url was returning a blank response (well, technically just "1") in REST Explorer.

We ended up using RNFS.downloadFile against the url (/services/data/v36.0/sobjects/ContentVersion/{ContentDocumen‌​tID}/VersionData), and it was able to get the file data fine.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .