One note of caution. I believe that unlike hard disks, there is a limit to the number of times you can write data to each location on the type of flash memory used in the iPhone before that location becomes unusable. The limit is large, of the order of many thousands of writes, so it’s not a problem for storage of say music and image files which tend to get saved to the iPhone then pretty much stay put. An area of flash memory used as a swap file is a different matter. By definition it will get pounded with new writes all the time so it is quite likely that, within the lifetime of the phone, parts of the swap file will start to get marked as unusuable by the system and the effective flash memory size will start to reduce.

Now I’m not sure how much of a showstopper this issue is likely to be in practice, and it may depend on user habits, but I thought it was worth the mention.

I rather imagine it was for this reason that Apple didn’t provide a swap file system on the iPhone in the first place and I would still prefer to see at least a doubling of the RAM.

http://danishkhan.com/blog/2009/09/how-about-some-virtual-ram-for-your-iphone/

PS: I am not lying about the blank safari page. Try and see what happens.

First off, a lot of people have mentioned a swapfile solution, but I’m not sure that’s a good idea. On a hard drive with virtually unlimited write capability it makes perfect sense. On a flash drive where the number of writes is limited, I can see how Apple might shy away from letting the OS write to flash an unbounded number of times any time the memory fills up and the user keeps asking for more.

That said, I used to have a lot of safari crashes on my 16GB iPhone. This seems to have cleared up in firmware 2.2, but I’m not sure what changed or whether it was related to this in the first place. It was certainly no fun, and I do think that more graceful error handling is necessary; simply crashing apps with no error or warning is really bad form. Apple could do a number of things to mitigate this without having to resort to swapfiles. In coverflow, for instance, they can arbitrarily change the number of images they keep in memory…when the available memory gets low, you drop the first half of the images and keep going. If the user scrolls back over there they need to be repaged, which might slow the application down, but what’s worse, slowing the flow or totally crashing? In my opinion it’s a no-brainer. Similar story with Safari; if it can’t load a page…uh…DON’T. Pop up a message saying “not enough free memory to load page.” Simple enough.

Which I guess leads me to weigh in on the first two comments here. Sure, a small amount of RAM is a device constraint, not a bug. But just crashing an app when the memory runs out without warning, error or exception is a BUG, plain and simple.