Dont take this the wrong way, but i thought the apks where a bit slow so i timed the time it took (in the system of course) for the app to run a long procedure. The exakt same app where also made in Thunkable with the exakt same blocks. The test was done 10 times one each app in a pattern thunkable app, makeroid app, thunkable app and so on… The test showed that the thunkable app had a high of 0,4s and a low of 0,2s. The makeroid had a high 1,3s and a low of 0,6s. There is some significant diffrent between the two apps. Is makeroid doing alot more of background jobs than thunkable?
1 Like
i hope it is fine. which device are you in?
Maybe it is because we have much more components and added much more properties for users.
Too we added a permission util which thunkable did not have current since they still use target sdk 22 and we use 27.
3 Likes
Could you share both APKs?
1 Like
You can easily make your own test
My procedure contains private information
1 Like
this new test then will not be comparable to your tests…
why don’t you prepare a small test project and add it into this thread, so someone form the Makeroid team can verify it?
Taifun
1 Like
Because our apps uses runtime permission it takes a bit longer to load. I think its a fair price to have apps that a marked with this, because then the user knows what kind of permission your app need to use.
2 Likes
Also, Runtime Permissions is the unique way to set in a real way Target SDK 27
3 Likes
May I ask how runtime permissions cause’ this issue?
1 Like
This is no issue..
We check on app start if the user have to grant the app permissions. Thats it.
I noticed that the same app compiled with the previous version of Makeroid is much faster than compiled with the new version. For me there is a problem that must be solved old projects are no longer usable