Слабенько, еще может примеры есть

Работал с этим?

Столкнусь. Это типо как асинхронные/параллельные функции?

Это работа приложения пользователсь свернул или прибил аппку

ну там же для этого очереди используются и всякие протоколы типо grpc

Работаешь с потоками, правильно?

Background Tasks(Modes)

я не про многопоточность

Наследуешься от BGTask и прописываешь реализацию логики в наследнике?

А ты с Generic умеешь работать?

Вы понимаете вообще о чем пишете? Там не нужно наследоватся.

Давай на ты

Проблема синхронизировать данные в фоне.

Проблема, в background приложение имеет ограниченное время жизни. При чем нужно учитывать сколько у тебя есть времени. Так если не вписатся, то можно iOS прибавает приложение и оно больше не работает.

Напрямую network запросы там тоже слать не желеательно, так как можно схватить timeout и должно ждать респонса. Пока будешь ждать система прибьет аппку. Это отлавливать можно очень долго.

Нужно давать специальные hint's для iOS что бы она что-то начала выкачивать и выключать аппку.

Затем когда докачает файл и если докачает опять возвращатся что-то процессить, сохранять. Опять это все по-кругу.


По-отдельности ничего сложного, но если где-то что-то не так. То нужно настраивать грамотно логи. Смотреть при каких условиях что произошло.

Это где-то похоже на ваши задачи с бекенда когда запрос выполняется слишком долго.

Да, это похоже. а в чем проблема покрыть код логами?

И обернуть в try catch

ну к примеру с timeout это не поможет. система просто прибъет.

но логами, да нужно все покрывать, потом их доставать которые у кого можно достать.

Я всегда код логами покрываю

Проблема в том что фикс перепроверить долго

Но если проблема в конечного пользователя, то логи получить бывает проблемно.