The trick is to only use enough tiles to fill your viewport - that's also how classic consoles (like the NES) simulated huge/wide backgrounds and maps. This is also the reason why these consoles (especially the NES) had sometimes colors overlapping from one side of the screen to the other (as it's essentially continuous memory being wrapped).

For example, if your viewport is 320 pixels wide and one tile has a width of 32 pixels, then you use 11 columns to render the Background/tiles (10 tiles just for the width and another column to fill the gap on the left or right).

How so? Easy: No matter how you move the tiles, there'll always be a maximum of 11 tiles be visible next to each other. If your viewport is exactly at the borders of tiles, you see ten tiles. Move them a bit to the left or right and an eleventh tile appears on the other side.

So rather than creating, deleting and/or moving tiles around, just move them to have proper tile borders and update their content accordingly. This way 32px wide tiles will move by a Maximum of 32 pixels in one direction.

This sounds a bit complicated, but it's actually rather easy.

I've had to look around a bit to find some sources without having to draw something myself (rather late already):

http://content.gpwiki.org/index.php/Scrolling_Games

Look for the section Tiled Backgrounds and Levels, which will show you an image of a tiled background. They use a different width, so they always show 12 or 13 tiles horizontally. Just consider how the grid would move. Once a full row of tiles disappears on either side, all tiles are moved back by one row and their images are updated accordingly.

Also just to mention it: I'm not sure about the iPad's capabilities, but shouldn't you be able to use the canvas element? I'm sure it would be more performant.

The trick is to only use enough tiles to fill your viewport - that's also how classic consoles (like the NES) simulated huge/wide backgrounds and maps. This is also the reason why these consoles (especially the NES) had sometimes colors overlapping from one side of the screen to the other (as it's essentially continuous memory being wrapped).

For example, if your viewport is 320 pixels wide and one tile has a width of 32 pixels, then you use 11 columns to render the Background/tiles (10 tiles just for the width and another column to fill the gap on the left or right).

How so? Easy: No matter how you move the tiles, there'll always be a maximum of 11 tiles be visible next to each other. If your viewport is exactly at the borders of tiles, you see ten tiles. Move them a bit to the left or right and an eleventh tile appears on the other side.

So rather than creating, deleting and/or moving tiles around, just move them to have proper tile borders and update their content accordingly. This way 32px wide tiles will move by a Maximum of 32 pixels in one direction.

This sounds a bit complicated, but it's actually rather easy.

I've had to look around a bit to find some sources without having to draw something myself (rather late already).

Look for the section Tiled Backgrounds and Levels, which will show you an image of a tiled background. They use a different width, so they always show 12 or 13 tiles horizontally. Just consider how the grid would move. Once a full row of tiles disappears on either side, all tiles are moved back by one row and their images are updated accordingly.

Also just to mention it: I'm not sure about the iPad's capabilities, but shouldn't you be able to use the canvas element? I'm sure it would be more performant.