One of the most important skills to learn as a programmer is how to locate and fix performance problems. The good news is that this process is easier today than it has ever been in the past. As mentioned in the comments, a frame rate stutter of 0.5 seconds is completely unacceptable for any game which demands reflexes from the player, so this is a great excuse to learn this skill that you'll use for the rest of your programming career.
My advice is that you ignore all the assumptions and random guesses that people are putting forward. You don't have to guess at the problem, you can just measure your own performance and know the problem for certain. For an iPhone game, all you have to do is run your game through Instruments. Just choose the menu option: Profile from the Product menu in Xcode.
This will build your program, launch it on device, and then start Instruments. Instruments will pop up a window asking what sort of profiling you want to do. It'll look a little like this (note that I'm profiling a MacOS app for my example, as I don't have an iOS project on hand to use for screenshots. When you do this, you'll choose CPU Time Profiler under the iOS heading, instead of MacOS X)
Then run your game until the stutter happens. After it does, go back to Instruments and hit the pause button. Instruments will look something like this:
The horizontal graph along the middle is how much CPU time was being used over time. You can see that my game used extra CPU time while launching (which I've highlighted in a red box), and that there was a spike of processing time a little later on (highlighted in a green box).
Additionally, the display at the bottom shows where your game is spending most of its time. The most important numbers are the percentages, which I've highlighted in a blue box. In this case, you can see that 3.2% of my time is spent inside of a function called memmove. (If I opened that up, I could see where I was most often calling that function from)
Now, those numbers are from the full runtime of my program (about 30 seconds in my case. Yours might be five or ten minutes, or however long it takes for your stutter to happen). So if you have a half second pause in five minutes of game play, the culprit probably isn't going to show up with a high overall percentage in your profiles. But luckily, you can tell Instruments precisely which bit of the timeline you're interested in by using the Inspection Range tools:
As you can see, I've now drilled down to see precisely what's slow at this specific point in my game. Looking at the output, we can see which bits of code are taking the most execution time. While 'memmove' was showing up as 3% of my time in total, in this bad performance spot, it's taking up more than 11% of my CPU time. In this screenshot I've expanded 'memmove', to show how you can see what functions called into the problem function.
Now in my case, what I'm using as an example isn't a real spike like yours; it's just me doing something that's a little more computationally expensive than when the game is idle; my game is still running at 60fps through this period. Yours would have a vastly taller peak in the graph, and instead of having a top item that's using 10% CPU, you'll probably have one that's using 50% or more. I've often seen spikes where a single function used 70% to 80% of CPU time.
Following these steps will help you determine -- with extreme accuracy -- exactly what it is that's using up time, so you'll know what part of your program to think about trying to optimise.
But if you can't figure out how to speed up that problem area (whatever it turns out to be), then do open another question to ask about how to improve that specific thing.
Finally, it's important to note that this answer is only barely scratching the surface of what Instruments can do. It is absolutely worth your while to look through Apple's documentation to learn even more options to drill more deeply into the performance metrics it can gather on your game.
news ordeletes inside the game loop? And are you using something like std::vector that could spontaneously start a large copying process? \$\endgroup\$