Slow performance of Justinmind Prototype App

Samia Zahid shared this question 3 years ago

my JIM prototype app is really slow for some reason, i have updated it to the latest version as well but it still is very slow. annoying and can work properly on the prototype.

Comments (3)


Hi Samia,

Thanks for reporting this. We're working on improving application performance. However, a few things can affect performance on your end - do you have many high resolution images, data masters, or comments? Try reducing these if possible and see if application performance improves.




Hi! I have been dealing with these kind of issues myself every time a prototype gets complex. I will tell you my experience with my last big prototype and let me know if it helps you figuring out what your cause might be:

- I was designing a big iOS prototype, with just a login screen a tutorial screen and then a complex screen containing everything else. Every time the user changes from one screen to another, every information on what panels were selected, what was the scroll position in some panels, etc, is lost. This is sometimes convenient, but some other many times not. In the old web users were use to navigate through independent web pages, nowadays one-page sites are very common so you want all panels state to remain as they are (and even more if it is a prototype of a mobile app).

Anyway, so for all these reasons I used to just have one complex screen and use dynamic panels for everything, dynamic panels are the most awesome feature of JIM in my opinion.

- With time it got really slow every time I (as a user) accessed to this complex screen. So slow that I had to present a popup for the user saying "loading items" which would last about 15 seconds on my iPhone 6.

- The big issue in my case were the datamasters and datagrids. I had 3 datamasters, with not many entries (just 15, 5 and 10 entries respectively). When I deleted 2 of those datamasters and datagrids it suddenly loaded in a very decent time. I tried then to leave the datamasters, created a new screen and use the datagrids related to those datamasters but in this new screen. Now the complex screen I talked about before loaded in the same decent time, so the issue was not having many datamasters, but using serveral datagrids, related to different datamasters in the same screen.

- With a bit of work I divided the whole project in different screens in a way that each screen would use just one datagrid/datamaster. In one screen it was impossible and I used two of them (so its the screen that takes more to load). I still left the "getting items" popup cause it helps the user understand that it didn't hang and its just loading stuff. Doing this the whole prototype became finally useful!

- Of course I had to use many more variables to pass some states of one screen to the next screen.

- If instead of having 3 datamasters, I had a large datamaster of 30 entries, the loading time would be more or less the same. Its just JIM having a hard time loading info from the datamasters into the datagrids. Its also true that my datamasters have 6-10 columns. It might also be related. But anyway, its still a tiny database. I guess they need to optimize this in the future.

This is just my last experience and how I fixed, in your case, it could be any other thing, any of the causes Danielle mentioned.




Thanks for all that info Diego, it's helpful to know how users interact with prototyper as well as how they find workarounds for any limitations in the application.