{ "version": "https:\/\/jsonfeed.org\/version\/1", "title": "\/\/ by kei_sidorov", "_rss_description": "Technical noes by Kirill Sidorov", "_rss_language": "en", "_itunes_email": "", "_itunes_categories_xml": "", "_itunes_image": "", "_itunes_explicit": "", "home_page_url": "https:\/\/sidorov.tech\/en\/", "feed_url": "https:\/\/sidorov.tech\/en\/json\/", "icon": "https:\/\/sidorov.tech\/en\/user\/userpic@2x.jpg?1729685594", "author": { "name": "Kirill Sidorov", "url": "https:\/\/sidorov.tech\/en\/", "avatar": "https:\/\/sidorov.tech\/en\/user\/userpic@2x.jpg?1729685594" }, "items": [ { "id": "7", "url": "https:\/\/sidorov.tech\/en\/all\/why-task-under-mainactor-hurts-performance\/", "title": "Why Task under MainActor can hurts performance", "content_html": "

Transitioning to Swift 6 and the new concurrency model forces you to gradually adapt old code. Some functions become async, they start updating the UI, and legacy code starts to grow with Task insertions. In many of these cases you need to update the UI, and a simple solution appears: mark the whole task as @MainActor. The errors disappear, the UI updates, and the job feels done.<\/p>\n

However, this solution can reduce the app’s performance. Let’s look at an example and see why.<\/p>\n

Imagine you had a button that requested some data from a couple of sources and then displayed it in the UI.<\/p>\n

\r\nlet workers = dataProvider.getAllWorkers()\r\nvar result: [Schedule] = []\r\nfor worker in workers {\r\n    let schedule = dataProvider.getSchedule(for: worker)\r\n    result.append(schedule)\r\n}\r\ndisplay(schedule: result)\r\n<\/code>\n<\/pre>\n
At some point these were very simple operations from a small local file, but later they became network calls, so obviously they must be async. You will need to wrap them in a Task, and to make sure nothing crashes there, you mark the whole block with @MainActor<\/samp><\/p>\n
\r\nTask { @MainActor in\r\n    setActivityIndicator(visible: true)\r\n    let workers = await dataProvider.getAllWorkers()\r\n    var result: [Schedule] = []\r\n    for worker in workers {\r\n        let schedule = await  dataProvider.getSchedule(for: worker)\r\n        result.append(schedule)\r\n    }\r\n    setActivityIndicator(visible: false)\r\n    display(schedule: result)\r\n}\r\n<\/code>\n<\/pre>\n
This code really works and works correctly. The data provider calls run in the background and do not block the main thread. But inside this construct there is a mechanism that starts overloading the main thread.<\/p>\n
What happens under the hood<\/h3>\n
Each await creates a suspension point. After the async function finishes, Swift must return execution to the same context where it started, and in this case it means MainActor.<\/p>\n
In the example above, four await calls produce four returns to the main thread.<\/p>\n
In simple terms, every time MainActor gets such a return, it puts the continuation into its queue, schedules execution on the main thread, and when the main thread is free, it continues the next step.<\/p>\n
This results in 5–10–15 extra returns to MainActor just to load the schedule of the next worker. The Swift compiler cannot merge these hops into one because the actor model forbids such optimization.<\/p>\n
When many parts of the app work like this, and each of them has several await calls on MainActor, the total load on the main thread grows. On hot paths (like app startup), this can show up as UI stutters, delayed animations, and reduced responsiveness.<\/p>\n
🤔<\/p>\n<\/div>
Does the example look too artificial?<\/p>\n
Actually no. In hybrid code that is only starting to move toward the new concurrency model, this pattern is very common. Also there is a strong temptation to ask an LLM to fix such issues automatically, and without careful prompting it will often put @MainActor everywhere to avoid crashes. Be careful!<\/p>\n<\/div>
How to write it correctly<\/h3>\n
Async work must be done outside MainActor. UI updates should happen in one short block.<\/p>\n
A correct approach is to use a detached task and not be lazy about adding MainActor.run:<\/p>\n
\r\nTask.detached {\r\n    await MainActor.run { setActivityIndicator(visible: true) }\r\n    let workers = await dataProvider.getAllWorkers()\r\n    var result: [Schedule] = []\r\n    for worker in workers {\r\n        let schedule = await  dataProvider.getSchedule(for: worker)\r\n        result.append(schedule)\r\n    }\r\n    await MainActor.run {\r\n        setActivityIndicator(visible: false)\r\n        display(schedule: result)\r\n    }\r\n}\r\n<\/code>\n<\/pre>\n
If you use agents for refactoring, try adding this paragraph to your rules:<\/p>\n
Always analyze async\/await code from the perspective of MainActor load: do not mark the whole Task as @MainActor if there is heavy work inside. Remember that each await in a MainActor context creates a hop to the main thread. Do the heavy part in the background (Task or structured concurrency), and move UI updates into short blocks via MainActor.run. Use Task.detached only consciously — it breaks structured concurrency. The main goal is to minimize hops back to the main thread and maximize UI responsiveness.<\/code><\/pre><\/pre>\n
Summary<\/h3>\n
Marking the whole Task as MainActor is a simple but often incorrect solution when architecture is not well-defined. With several await calls inside, it triggers multiple returns to the main thread, reduces its throughput, and causes UI lag.<\/p>\n
The main thread should update only the UI.
\nAsync work should run outside MainActor.
\nOne short UI update at the end is the optimal strategy that scales and keeps the app responsive.<\/p>\n",
            "date_published": "2025-11-18T15:07:19+00:00",
            "date_modified": "2025-11-18T15:16:33+00:00",
            "_date_published_rfc2822": "Tue, 18 Nov 2025 15:07:19 +0000",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "7",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "system\/library\/highlight\/highlight.js",
                    "system\/library\/highlight\/highlight.css",
                    "system\/library\/highlight\/highlight.js",
                    "system\/library\/highlight\/highlight.css",
                    "system\/library\/highlight\/highlight.js",
                    "system\/library\/highlight\/highlight.css",
                    "system\/library\/highlight\/highlight.js",
                    "system\/library\/highlight\/highlight.css",
                    "system\/library\/highlight\/highlight.js",
                    "system\/library\/highlight\/highlight.css"
                ],
                "og_images": []
            }
        },
        {
            "id": "6",
            "url": "https:\/\/sidorov.tech\/en\/all\/storekit-trials-and-double-entitlements-a-real-world-edge-case-e\/",
            "title": "StoreKit trials and double entitlements — a real-world edge case explained",
            "content_html": "
Recently, we had an interesting case with in-app purchases in our app — so unexpected that we initially thought it was a bug in StoreKit. But then it turned out — everything works exactly as intended. There’s just nowhere this behavior is properly documented.<\/p>\n
We’re building an app that helps users in the US prepare for driver’s license exams — for cars, motorcycles, and commercial vehicles. During this process, users go through a series of quizzes and exam marathons, and after successful completion, they receive a certificate required for the DMV. Access to the app is subscription-based, and we recently started testing a 3-day free trial to improve conversion.<\/p>\n
During the trial, users get access to the entire app: all tests, marathons, and exams. But the certificate becomes available only after full payment. That’s intentional: it has legal value, and we can’t give it out for free.<\/p>\n
About a week after launching the trial, support messages started coming in: “I paid for a subscription, but the certificate is still locked.” We first investigated progress sync issues. Then we were just confused. The classic “my hand is the same but it doesn’t hurt.” We looked into the receipts — the Apple payment looked valid, but the app still showed the user as being on a trial. How was that possible? We started to suspect StoreKit caching issues or bugs. But then more users reported the same. All had real Apple receipts. Strange!<\/p>\n
We kept digging and finally figured it out:<\/p>\n