Yakov

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

Первый вариант сложнее в реализации, не вполне соответствует архитектурному подходу, который Apple рекомендует использовать (нагрузка ячеек кучей функционала мешает оптимизациям и может привести к UI-лагам), и уместен в очень редких ситуациях, поэтому я не буду вдаваться в детали.

Второй вариант решает ~90% задач и реализуется максимально просто. У вас есть массив с модельками, к которому таблица обращается в методе tableView(_:cellForRowAt:). Когда нужно изменить содержимое ячейки, вы меняете данные массиве, а потом вызываете метод reloadRows(at:with:) с индексом изменившегося элемента. Если приложение не поддерживает iOS 12 и более старые версии, перезагрузка ячеек может происходить автоматически — см. UITableViewDiffableDataSource.

Многое зависит от того, за что именно платят ваши пользователи, а вы это не уточнили в вопросе.

Оплата через iTunes обязательна для контента, который «потребляется» внутри приложения (примеры: виртуальная валюта в игре, отключение рекламы, подписка на аудиокниги*). Если у вас что-то другое — интернет-магазин, электронный кошелек и т.д., — эти ограничения не действуют: можете хоть веб-вью открывать, хоть нативную форму для реквизитов показывать.

При худшем раскладе вы можете сообщать в приложении, что регистрация доступна в другом месте (не уверен, что более детальное упоминание, тем более кнопки, проходят ревью), а уже там рассказывать про оплату. Впрочем, какое-то время назад я видел в приложении ЛитРес огромный банер с предложением оформить подписку, ведущий на сайт. Это 100% нарушало правила стора, но к пользователям все равно попало.

* Для так называемых reader apps с недавних пор действует исключение: в них теперь можно сообщать, что регистрация / подписка / оплата доступна в браузере, и показывать кнопку, отправляющую туда. Определение и примеры reader apps можно найти в правилах App Store, вот несколько: Netflix, Amazon Prime Video, Spotify, Kindle.

Поток — это цепочка задач (блоков кода), которые выполняются компьютером. Потоки нужны, чтобы более эффективно использовать многоядерные процессоры: каждое ядро может выполнять отдельный поток без перерывов (тайм-шейринга). Потоки на платформах Apple примерно соответствуют традиционному пониманию потоков.

У потоков есть недостаток: на их создание тратятся вычислительные ресурсы. Если для каждой мелкой операции (например, сделать запрос в сеть и получить ответ) создавать отдельный поток, это будет медленно и неэффективно.

Очередь (DispatchQueue) — это абстракция из фреймворка GCD (Grand Central Dispatch). Ее придумали для того, чтобы обходить проблему с частым созданием потоков. Внутри очереди есть точно такие же задачи (блоки кода), но при этом создание очереди — менее «дорогой» процесс, чем создание потока.

В конечном итоге задачи из очереди все равно выполняются в определенном потоке. Но несколько очередей могут делить между собой один и тот же поток — как раз чтобы не создавать лишние. Обычно ОС самостоятельно распределяет задачи из очередей по потокам.

На картинке показаны две очереди. Стрелки, идущие от верхней к нижней, демонстрируют добавление асинхронных блоков кода в нижнюю очередь (асинхронных — потому что верхняя очередь не ждет, пока нижняя выполнит задачу, а идет дальше).