Xcode 4 "Transferring package" pathologically slow after deleting app

I have noticed that when performing native debugging on Xcode 4 if I have my app installed, then delete the app, then attempt to debug again from Xcode 4, the time it takes to perform the step "Transferring package" is pathologically slow. Has anyone else ex开发者_Python百科perienced this? I dread deleting the app as it will take 20-30 minutes to load the app.

Our app has lots of user files that get deleted when app is deleted. Perhaps some sort of sync-like process is running at same time. Killing Xcode 4 does not fix the issue.

I think now you must use Xcode 6.3 and it will allow you to do everything in easiest way. Here this version of Xcode is most stable version I have worked with for last few years.

I would like to offer some general guidance on this as the symptom you see can have many causes. In fact most versions of Xcode have had these symptoms for differing reasons in my experience.

I've seen the slow transfer problem before (Xcode 4 I think), when I switched my app to be an app that could run in the background. To get around that, I would either force kill the app from the phone itself, or I would change the bundle id of the app when deploying it (as a hack).

68cherries commented on seeing the problem after profiling. Doing profiling of a device generates a lot of data on your Mac, and perhaps also on the device but I don't know. So its worth switching phones with another phone, ideally one that has a lot of free space; does the problem follow the phone?

Sometimes deploying has a problem when resources are missing; resources are rebuilt upon clean. Try pressing the option button and then doing a clean - it cleans intermediate files. (option-shift-command-k). This can happen in particular when you delete a resource but still reference it from a story board. Going through the story board looking for exclamation mark warnings is helpful (particularly with Apple Watch apps).

Periodically it is worth doing a resource file audit. Quite often we deploy files not actually needed by the target device. For example, bash script files, old icons, etc. The fewer resources, the fewer things that can be incorrect, and can often trigger an idea about what has changed with your resources that might explain the problem. It also makes the deployment smaller for your customers.

Note with this problem its worth debugging it from both sides. For example, look at your Mac console logs to see any errors, or your activity monitor for unexpected behaviours and tasks. On the device side, its worth installing iOS console from lemonjar.com to see if anything got to the device end and if there were errors there.