iOS iOS simulator and backend performance

[petermod]

Hello!
I have been creating a chat app and recently came across a few issues.
When I log in, the inicial VC is one made of the added users. I can tap on any of them to start a new conversation. My backend is Parse and i store my messages and info there.

The problem is that when i tap on the user the messages take too long to load. Is that related to the server or to the simulator itself? I went to the server and got no slow queries..

Also, the app itself responds kind of slowly. When i type on the "Type message" view the keyboard takes some time to appear, it is not immediate and this does not depend on the server.
I even tried running the app on my actual iPhone and it is still pretty laggy and crashes from time to time.

Is this normal on the development process or should I expect my app to perform better and in real time when i test it on my real iPhone?

Thank you in advance.

 

[xStep]

There too many parts and no details from you to get great responses. Some thoughts...

I don't see that the simulator would have performance problems in this case. In this kind of app it should be much faster than any iOS device. Yosemite networking is known to have issues, so possibly you could be tripping over that. Apparently iOS 8 is affected by the same bad piece of code.

The free Parse account has a limit on the number of transactions per some time frame (per second or minute). Check to see if you could be hitting that.

If you are only keeping your data on Parse and do not have a local copy, then every request will take more time than a local request. I don't know much about Parse. Does it setup a local cache for instance? If not, I'd store the users locally and at least some of the message history. I'd have a background process running to keep the user data (like nick name) up to date.

Running on the server would normally see big performance advantages, so that isn't a good test for that. At least you know it is responding.

The keyboard should appear within roughly .25 seconds. I'm guesstimating. It isn't instant but should not be lagging. I'd look at all processing occurring before it appears. For instance, do not do any time consuming processing in textViewShouldBeginEditing as that gets called multiple times based on the number of textViews on the screen and should only be used for answering the implied question. I'd implement all of the delegates regarding the key oaf appearance and NSLog those so you can see how quickly they may be getting called.

Testing on a real device should be responsive. Try running the app without being hooked up to the debugger to see if some of your lag disappears.

As for your crashes, you want to solve those immediately. The debugger is giving you information upon each crash so track those down and fix them.

 

[petermod]

There too many parts and no details from you to get great responses. Some thoughts...

I don't see that the simulator would have performance problems in this case. In this kind of app it should be much faster than any iOS device. Yosemite networking is known to have issues, so possibly you could be tripping over that. Apparently iOS 8 is affected by the same bad piece of code.

The free Parse account has a limit on the number of transactions per some time frame (per second or minute). Check to see if you could be hitting that.

If you are only keeping your data on Parse and do not have a local copy, then every request will take more time than a local request. I don't know much about Parse. Does it setup a local cache for instance? If not, I'd store the users locally and at least some of the message history. I'd have a background process running to keep the user data (like nick name) up to date.

Running on the server would normally see big performance advantages, so that isn't a good test for that. At least you know it is responding.

The keyboard should appear within roughly .25 seconds. I'm guesstimating. It isn't instant but should not be lagging. I'd look at all processing occurring before it appears. For instance, do not do any time consuming processing in textViewShouldBeginEditing as that gets called multiple times based on the number of textViews on the screen and should only be used for answering the implied question. I'd implement all of the delegates regarding the key oaf appearance and NSLog those so you can see how quickly they may be getting called.

Testing on a real device should be responsive. Try running the app without being hooked up to the debugger to see if some of your lag disappears.

As for your crashes, you want to solve those immediately. The debugger is giving you information upon each crash so track those down and fix them.

Thank you very much for your answer. I did not upload any lines of code or more details because i did not know where the problem was located.
I will look into your suggestions with detail and try to figure this out. Hopefully i can get this on the right track!

 

[1458279]

It might also help to know the language and any transitions and 3rd party tools that might be used. In addition, anything that might be loaded at the time and taking up memory.

Have you tried some of the tools that show memory usage.

Some of the code I see as samples are heavy on UI and OO stuff that might slow things down.

Is this in ObjC or Swift, is there a bunch of setup code before the calls are made?