Each time you apply transformations to your project counts as a request, independently of the number of files and protections. Every time this protected version is executed, it does not count as a new service request. The protected version of the code doesn't contact our service. So in summary, you only do Jscrambler service requests when you have a new version of the code to protect.
Your protected code will continue to work regardless of you staying subscribed or not. You need to keep subscribed only in case you need to protect newer versions of the code. The ones you have protected before will work forever.
You can use our Code Annotations to control our transformations through several code blocks
All of Jscrambler's Code transformations are developed to have the least impact possible. The performance hits are manageable and depend a lot on the application you are trying to protect.
However, Jscrambler has some features that can help you manage the performance impact of obfuscation like Application Profiling. This feature allows you to monitor the application at runtime and collect performance related metadata which will then be used to automatically produce recommended protection settings for your application. You can learn more about this in the Profiling documentation.
Additionaly, with Code Annotations you can manually annotate source code (e.g. functions, statements, variable declarations) to change Jscrambler behaviour during protection, which can be used to increase protection or to reduce the impact on performance.
You may use an API client if you would like to integrate Jscrambler into your development process and submit requests to our Web service programmatically. Check them out here.
Potency represents the power of a transformation to increase your code complexity. Resilience represents the difficulty to revert the transformed code into its original form. Cost represents the impact of a given transformation in execution time and space that it will have in a transformed application.
Not at this point, for now, any change in the source code of the application requires the instrumentation and profiling to be restarted.
Code Annotations take precedence over all profiling operations.
As long as it takes to execute all the representative use-cases of your application.
No. If you stop profiling, you will need to restart profiling from the beginning to collect any additional data. If the instrumented application is closed but the profiling wasn't stopped, then it can be reopened for additional profiling, but if it is closed for too long (so it does not send any further data), profiling will be automatically stopped after some time.
It is also not recommended to leave the application open and idle for long periods unless that is something your end-users are also likely to do, since doing so have the profiler believe that being idle is a typical use-case of the application.
Yes. To do that go to "Protection History", select the desired protection and click the link in the "Profiling Report" section. As a side note, in the "Protection History", there is a column named "Profiling" which marks if a protection was made with the "Use Profiling" option enabled, helping users to easily identify these kind of protections.
Not at this point, for now, you have to do it via the Jscrambler Web App.
Note: if you have profiled your application and you want to protect it via CLI using the profiling settings, it is possible to do so passing the use-profiling-data option when issuing the protection request. Do not specify any source files in this request, otherwise, the use-profiling option won't have any effect as the existing source files will be overwritten therefore resulting in the remotion of the existing application's profiling settings. Read more about the use-profiling-data option in the CLI documentation.
Not at this point, protecting a React Native application is currently a process only made available via CLI. Profiling an application is a feature only accessible via the Jscrambler Web App at the moment.
When the profiling service detects functions as being protection-sensitive (e.g. performance-critical) it automatically recommends specific protection settings to them.
You should be cautious in cases where a high percentage of the functions are recommended to be protected with a Light Obfuscation template, as this can reduce the level of protection on those functions. Please review each function individually to make sure that there isn't any case of a function that requires a high level of protection.
Not at this point, profiling service does not analyze code outside functions.