The API 28 compiler is suffering from limitations (bugs) that need to be addressed, being unable to handle projects that compiled fine with the API 26.
However, there was limitations in the API 26 compiler as well, as I can assure you, from first hand experience, that if your application is too memory intensive (bearing in mind that a component takes perhaps as much memory as 10 logic block – this being highly variable as a label will have less attributes and methods than, say, a text box, with the latter thus taking more memory) it will not compile.
Mine has about 100 components and slightly over 6000 logic block in one screen, and is nearing the limit.
With 10000+ block, it seems you are beyond that limit.
And judging by the number of arrangements visible on the list on the right of your screenshot, plus the massive number of non visible components (at least 4 web views? Why? Why not use the same with different URL??? And at least 12 Firebase???) you are possibly exceeding that memory limit by a factor of at least 2.
I am surprised that you had something that did work before to establish the size of the “last exporting apk”. Did you substantially increase the size and functions?
By the way, and for the record, when nearing the limit, and while the code would still compile, it may start exhibiting instabilities; that is reporting operational errors almost randomly, in a manner that is non-trackable; add a notify to see what the result is that is causing the issue, and the error moves around and affect some other part of the program.
Your trimmed-to-939-blocks-aia file does compile with API 26, but fails with API 28; so at least there, you are in the same boat as many of us waiting patiently for Thunkable to fix the memory issue.
But even when (they stated a couple of weeks, we are at the end of the 3rd already…) the 28 compiler gets fixed, you’ll still have to deal with the issue that your code is way too big.
And there are several things that you can do about it.
1- spread your functionalities over several screens. The memory limitation (number of components + logic blocks) seem to apply on each screen separately. Of course, you may have to add a bit of code to harmonize and manage the screen opening and closing and information exchange between them, so splitting a program between two screens make the total size larger.
2- optimize mercilessly. For instance, one of your only surviving procedure “activeinactive” is doing the exact same processing to split, select first at index, split at split and split for a few different test string being requested. Why reinvent the wheel multiple times? Have the split-select-split handled by a SINGLE generic procedure, called multiple times with merely a different argument. You’ll save dozen of blocks like that. Also, if you have long extraction thing to make a test, and then if the test is positive, you perform the same extraction but this time to do something. Why not extract the value that is part of BOTH the test and the processing, save it in a local variable, and then do the test. Then the processing is done on the SAME local variable, without having to re-extract again.
To give you an idea, there were several instances in my program where a value needs to be incremented by 1. Instead of having “set’value’to get’value’ + 1” (4 block), I created procedure “plusone”, which takes “value” as argument, and returns it incremented by one.
The procedure add 4 blocks overall, but each call is now 3 blocks. If you think that this excessive, think again. It was necessary, along with several other tricks.