Unfortunately I had to upgrade to R2025a recently and have been hugely disppointed by what seems like a massive regression in the app compiling workflow using Matlab Compiler. In R2024a, which I was using before, I was confident I could have got my app packaged up in 15 minutes, with R2025a I’ve been battling with it for over a day and still finding it troublesome. Has anyone else had experience using this on a complex project?
This huge change is not adequately covered in Release Notes nor in product help, but now you have to have a Matlab project in order to compile using the app. I’ve never used projects before (they seemed to offer nothing for our work style) so already this was a big change. But they have serious restrictions compared to past versions too.
It seems to accept code not being under the project folder no problem, which is a relief as I have a large repository of code that is used and I can’t put it all under a project directory. However, I also use dlls, some icons, etc and in the past I could simply add these to the ‘Files required for your application to run’ section of the compiler. They would end up in the exact same relative location on the user’s machine so my functions that use relative paths to read them worked fine in deployed apps too.
But now, in R2025 the ‘Custom requirements’ section of ‘Files required for Standalone to run’ insists on any file that is added being under the project folder. This means I have to take a copy of dlls, icons, etc and put them there. But these files get unpacked to a completely different location on the target machine, so any code that expects these to exist in a certain relative folder location breaks.
I can use ctfroot to take me to the parent folder where the app is deployed, but not the specific app folder under that, so I have to search around under that folder to find my dlls in some subfolder.
This is a fundamental change from R2024a and I am very disappointed by such a massive regression in the workflow. Matlab has always been excellent at backwards compatibility in almost every area, but this has made what used to be a relatively efficient process into something that is a struggle to make work at all.Unfortunately I had to upgrade to R2025a recently and have been hugely disppointed by what seems like a massive regression in the app compiling workflow using Matlab Compiler. In R2024a, which I was using before, I was confident I could have got my app packaged up in 15 minutes, with R2025a I’ve been battling with it for over a day and still finding it troublesome. Has anyone else had experience using this on a complex project?
This huge change is not adequately covered in Release Notes nor in product help, but now you have to have a Matlab project in order to compile using the app. I’ve never used projects before (they seemed to offer nothing for our work style) so already this was a big change. But they have serious restrictions compared to past versions too.
It seems to accept code not being under the project folder no problem, which is a relief as I have a large repository of code that is used and I can’t put it all under a project directory. However, I also use dlls, some icons, etc and in the past I could simply add these to the ‘Files required for your application to run’ section of the compiler. They would end up in the exact same relative location on the user’s machine so my functions that use relative paths to read them worked fine in deployed apps too.
But now, in R2025 the ‘Custom requirements’ section of ‘Files required for Standalone to run’ insists on any file that is added being under the project folder. This means I have to take a copy of dlls, icons, etc and put them there. But these files get unpacked to a completely different location on the target machine, so any code that expects these to exist in a certain relative folder location breaks.
I can use ctfroot to take me to the parent folder where the app is deployed, but not the specific app folder under that, so I have to search around under that folder to find my dlls in some subfolder.
This is a fundamental change from R2024a and I am very disappointed by such a massive regression in the workflow. Matlab has always been excellent at backwards compatibility in almost every area, but this has made what used to be a relatively efficient process into something that is a struggle to make work at all. Unfortunately I had to upgrade to R2025a recently and have been hugely disppointed by what seems like a massive regression in the app compiling workflow using Matlab Compiler. In R2024a, which I was using before, I was confident I could have got my app packaged up in 15 minutes, with R2025a I’ve been battling with it for over a day and still finding it troublesome. Has anyone else had experience using this on a complex project?
This huge change is not adequately covered in Release Notes nor in product help, but now you have to have a Matlab project in order to compile using the app. I’ve never used projects before (they seemed to offer nothing for our work style) so already this was a big change. But they have serious restrictions compared to past versions too.
It seems to accept code not being under the project folder no problem, which is a relief as I have a large repository of code that is used and I can’t put it all under a project directory. However, I also use dlls, some icons, etc and in the past I could simply add these to the ‘Files required for your application to run’ section of the compiler. They would end up in the exact same relative location on the user’s machine so my functions that use relative paths to read them worked fine in deployed apps too.
But now, in R2025 the ‘Custom requirements’ section of ‘Files required for Standalone to run’ insists on any file that is added being under the project folder. This means I have to take a copy of dlls, icons, etc and put them there. But these files get unpacked to a completely different location on the target machine, so any code that expects these to exist in a certain relative folder location breaks.
I can use ctfroot to take me to the parent folder where the app is deployed, but not the specific app folder under that, so I have to search around under that folder to find my dlls in some subfolder.
This is a fundamental change from R2024a and I am very disappointed by such a massive regression in the workflow. Matlab has always been excellent at backwards compatibility in almost every area, but this has made what used to be a relatively efficient process into something that is a struggle to make work at all. compiler, projects MATLAB Answers — New Questions

​