NSFetchRequest fetchOffset pagination: latency growth as a failure condition for large datasets

Core Data’s NSFetchRequest supports bounding a query with an NSPredicate and limiting results with fetchLimit. Pagination is commonly implemented by advancing fetchOffset to skip previously fetched rows. With the SQLite store, the documented behavior is that the store still evaluates the full predicate and sort ordering before skipping rows, so execution time grows linearly with the offset.

This creates an unresolved design decision for large datasets: whether to accept the offset penalty for simpler code, or to switch to a batched object ID fetch pattern that avoids the offset cost but requires managing ID arrays. The failure condition is not an error code but a performance cliff—UI paging can become janky as the offset increases.

Questions: At what dataset size or offset depth does fetchOffset become unsuitable for interactive paging? Does the object ID batching pattern preserve the same predicate and sort semantics without additional store round trips? And what verification method reliably compares the two approaches on a given Core Data stack?