This would mean 'shrinking' the surface of your entities on the server. Probably not terribly feasible for a lot of apps.  But we are also looking at mechanisms for controlling serialization and allowing the developer to expose only a subset of the server model to the client.  

Projections are queries using the "query.select" method.  For example

var query = EntityQuery("Orders")
    .where("Customer.CompanyName", "startsWith", "C")         
    .select("Customer.CompanyName, Customer.Region, OrderDate, OrderDetails");

The advantage of projections is that any projected property that is not an entity or an entity collection is not wrapped by breeze in an "observable" wrapper (knockout, backbone etc.).  These wrappers can take up memory especially if you have a lot of them; this combined with the idea that you are only bringing down a subset of each entity can make your app's memory footprint much smaller.  In the query above "Customer.CompanyName", "Customer.Region" and "OrderDate" will all be brought to the client as "simple" scalar values instead of entities, whereas "OrderDetails" will be brought in as an array of  breeze 'OrderDetail' entities each wrapped in its own "observable" wrapper.

- these are great for caching data, but do tend to have large payloads.

Ok, I'm just guessing here because I do not know where the IOS memory limits that you are hitting are but it is conceivable that the issue is not total memory use, but rather a memory spike that occurs when deserializing the entities after a large query.  In this case, creating several smaller queries and executing them in series might work.

Hope this helps!