iOS Memory Performance Regarding Multiple Concurrent Views
<p>This is a theoretical question regarding the memory management of having multiple stacked views open simultaneously. </p>

<p>Imagine a stack of tinder cards (which can have an indefinite length) coupled with a user's ability to swipe left, right, back and forth. By back and forth, I mean that instead of the view exiting the screen and getting (eventually) recycled or released, it needs to keep at least its shape (if not its content) in order to be accurately placed back on the screen if a user swipes back to it. </p>

<p>I'm curious as to what the memory implications of this would be. My guess would be that after a certain arbitrary point, you clear the card but keep its place in the stack. If the card gets close enough to have the potential of returning on screen, you would simply pull the content from the api. However, as the view count gets large (>100) wouldn't that cause performance issues? </p>

<p>Clearly, there must be a way to handle it since you can create arbitrarily long lists on iOS with scroll views/table views. But I suppose I have the need for table view like performance without the actual need of a table view. </p>

<p>Is there a standard way of handling this problem?</p>