Это если есть доступ к бэку

если у вас нет доступа к беку, то фильтровать одинаковые объекты вам придется на уровне приложения

опять таки по какому-нибудь уникальному ключу

секунду, сейчас покажу часть кода, отвечающего за пагинацию, с пояснениями
телеграм вылетел, сообщение пропало, почти дописал

идея такая, сервер вы запросили условно первые 10 элементов, затем запрашиваете еще 10, при этом смещение (offset) передаете 10, таким образом сервер вам должен прислать с 11 по 20ый элементы. но если на сервере сверху между вашими запросами добавится новый элемент, то все записи как бы "сдвинутся" по индексам на 1, получается что его 11-20 элементы в новой нумерации по факту будут 10-19 из старой нумерации. на вашей сторое приложения этот 10ый элемент уже был получен в первом запросе, поэтому у вас в приложении это выглядит как дубль

как я уже сказал - используйте уникальные индексы для задания смещения offset, потому что порядковый номер это свойство не уникальное

Код находится в методе cellForRowAt. receiptStruct.count ровняется количеству элементов в структуре, в которой хранятся ответы с бэка. self.page локальная переменная, счетчик страниц (изначально равна 1). paginationStruct.totalPages приходит с бэка и равна общему количеству страниц. paginationStruct.total общее количество чеков на бэке.

даже если ничего на сервере не меняется, все равно та же история

ну тут в код смотреть бессмысленно. нужно смотреть в логи запросов. какие параметры вы передаете на сервер и что он вам возвращает в ответ

если предположить что на сервере не изменяются данные между запросами, то он не не должен возвращать дубли

ну и инициация запроса новой порции данных по-хорошему должна происходить уж не в методе получения ячейки из очереди

а где правильно?

будет конечно работать и так, но я бы предпочел нативные средства по предзагрузке или на худой конец где-нибудь в willDisplayCell сравнивать индексы

потому то событие will display связано с отображением нужной ячейки пользователю, а не конфигурированием. это разные объекты получают. хотя в программе конечно это обычно одно и то же время

попробую willDisplayCell
довольно серьезная проблема, потому что сроки обозначены на 20 марта, а человек, отвечающий за бэк, ушел на 3 недели на сессию
единственный вариант, который мне пока пришел в голову, это увеличить число элементов на странице до максимально доступного для сервера, то есть с 25 до 250, в таком случае дублей меньше в 10 раз

willDisplayCell вам не поможет в проблеме, я просто предложил это потому что так на мой взгляд правильнее

что касается проблемы - вам проще всего сейчас руками фильтровать записи. в момент когда получаете их из бека нужно каждую запись перед вставкой в хранилище проверить на уникальность

может получиться неожиданное поведение типа на 1ой странице 10 элементов, а на второй 9, но кто это заметит да? это же куда лучше, чем дубли

выглядит логичным, но все равно не будет отображаться по одному унивкальному чеку с каждой страницы
увы, эту проблему пока никак не решить получается

почему не будет?