I did iOS 3D game dev back in the 2G days where you only got 24MB of RAM to work in if you were lucky. Even in the later device with lots more memory, the amou

I did iOS 3D game dev back in the 2G days where you only got 24MB of RAM to work in if you were lucky. Even in the later device with lots more memory, the amount you could use before getting a memory warning was small and varied wildly depending on what the user had been doing recently before firing up your app. One technique to handle this is mentioned in the article: We used read-only memory mapped files containing position-independent data structures. We did this for audio and animation data without notable hitches. The big one though was making our meshes and textures hot-reloadable. Whenever we got a memory warning, we just deleted the OpenGL buffers for all of our meshes and textures and let them reload on-demand. From the POV of the OS we were being a very well-behaved citizen. The OS asked us to reduce memory and we did so instantly and dramatically. Meanwhile, the OS was also issuing memory warnings to all of the background apps that were hogging large, unpredictable chunks of RAM. Those apps would end up killed by the OS in short order, freeing up memory for us. Right each kill-wave, we would naturally get right back to filling RAM with even more meshes and textures, triggering another memory-warning with would free up even more mem for us! Pretty quickly we'd have all of the memories and the warnings would slow down. Using PVRTC texture compression and tightly pack vertex formats meant we could have a lot of detail loaded. And, simple binary file formats with just `fread(whole file in one go)` as our I/O practice meant we could reload everything in 1/10th of a second.