{"id":9841,"date":"2026-08-30T15:15:00","date_gmt":"2026-08-30T12:15:00","guid":{"rendered":"https:\/\/handoli.com\/index.php\/2026\/08\/30\/why-swift-is-introducing-a-warning-for-weak-captures-within-nested-closures\/"},"modified":"2026-09-02T00:02:01","modified_gmt":"2026-09-01T21:02:01","slug":"why-swift-is-introducing-a-warning-for-weak-captures-within-nested-closures","status":"publish","type":"post","link":"https:\/\/handoli.com\/index.php\/2026\/08\/30\/why-swift-is-introducing-a-warning-for-weak-captures-within-nested-closures\/","title":{"rendered":"Why Swift is introducing a warning for weak captures within nested closures"},"content":{"rendered":"

New in Swift 6.4 (which at the time of writing is in beta as part of Xcode 27) is a warning which is emitted when a nested closure performs a weak<\/code> capture while the parent closure implicitly captures that object as a strong reference<\/em>.<\/p>\n

At first glance, that new diagnostic could be a bit puzzling, since it might seem unnecessary to have to specify such a weak capture twice (or, alternatively, move it to the parent closure\u2019s capture list), but it turns out that it\u2019s an incredibly useful new warning that can help us avoid a quite common kind of memory management bug.<\/p>\n

Take the following code as an example. It performs a nested weak self<\/code> capture within the closure passed to the call to loadNearbyFriends<\/code>, while not (explicitly) capturing self<\/code> at all within the parent closure:<\/p>\n

@MainActor final class<\/span> NearbyFriendsViewModel {\n    private(set) var<\/span> friends = [Friend<\/span>]()\n\n    private var<\/span> timer: Timer<\/span>?\n    private let<\/span> service: FriendsService<\/span>\n    \n    ...\n\n    @MainActor deinit<\/span> {\n        timer?.invalidate<\/span>()\n    }\n\n    func<\/span> startScanning() {\n        timer = Timer<\/span>.scheduledTimer<\/span>(\n            withTimeInterval: 3<\/span>,\n            repeats: true<\/span>,\n            block: { [service] _ in<\/span>\n                service.loadNearbyFriends<\/span> { [weak self<\/span>] friends in\n                    self<\/span>?.friends<\/span> = friends\n                }\n            }\n        )\n    }\n}<\/code><\/pre>\n
When using Xcode 26 and Swift 6.3, the above code is successfully compiled without any warnings. However, it\u2019s actually causing our NearbyFriendsViewModel<\/code> to be trapped in a retain cycle, which might seem quite strange given that we haven\u2019t performed any strong captures of self<\/code> \u2014 at least not explicitly<\/em>.<\/p>\n
However, it turns out that when we perform a weak self<\/code> capture within a nested closure (like we do above), then the Swift compiler implicitly inserts a strong<\/em> self<\/code> capture within the parent closure unless it performs an explicit capture of its own. Within the above NearbyFriendsViewModel<\/code> example, that means that our Timer<\/code> actually captures self<\/code>, which in turn retains that object through its timer<\/code> property, and there we go \u2014 a classic retain cycle.<\/p>\n
If we instead switch to Xcode 27 and Swift 6.4, then we can see that we now actually get a warning when attempting to compile the above code:<\/p>\n
'weak' ownership of capture 'self' differs from implicitly-captured\nstrong reference in outer scope<\/code><\/pre>\n
That\u2019s great, because it clearly shows us where the problem is. So, let\u2019s go ahead and fix it. In this specific case, since we\u2019re not actually using self<\/code> within the outer closure, we can simply move our weak self<\/code> capture to that closure instead:<\/p>\n
@MainActor final class<\/span> NearbyFriendsViewModel {\n    ...\n\n    func<\/span> startScanning() {\n        timer = Timer<\/span>.scheduledTimer<\/span>(\n            withTimeInterval: 3<\/span>,\n            repeats: true<\/span>,\n            block: { [weak self<\/span>, service] _ in<\/span>\n                service.loadNearbyFriends<\/span> { friends in\n                    self<\/span>?.friends<\/span> = friends\n                }\n            }\n        )\n    }\n}<\/code><\/pre>\n
That successfully breaks our retain cycle, and resolves the warning that the Swift 6.4 compiler previously gave us.<\/p>\n
Another option would be to perform two separate weak self<\/code> captures, which would be a good solution if our outer closure actually needed to use self<\/code> in any way, such as in this case:<\/p>\n
@MainActor final class<\/span> NearbyFriendsViewModel {\n    ...\n\n    func<\/span> startScanning() {\n        timer = Timer<\/span>.scheduledTimer<\/span>(\n            withTimeInterval: 3<\/span>,\n            repeats: true<\/span>,\n            block: { [weak self<\/span>] _ in\n                guard let self else<\/span> { return<\/span> }\n\n                logScanningDidStart<\/span>()\n\n                service.loadNearbyFriends<\/span> { [weak self<\/span>] friends in\n                    self<\/span>?.friends<\/span> = friends\n                }\n            }\n        )\n    }\n    \n    private nonisolated func<\/span> logScanningDidStart() {\n        ...\n    }\n}<\/code><\/pre>\n
Finally, in situations where capturing self<\/code> strongly doesn\u2019t actually lead to a retain cycle, we can silence the new warning for nested weak<\/code> captures by explicitly adding self<\/code> to the outer closure\u2019s capture list, such as when creating a Task<\/code> within the following example:<\/p>\n
@MainActor final class<\/span> NearbyFriendsViewModel {\n    ...\n    private let<\/span> cache: FriendsCache<\/span>\n    ...\n\n    func<\/span> reloadIfNeeded() {\n        Task<\/span> { [self<\/span>] in<\/span>\n            guard await<\/span> !cache.isValid<\/span> else<\/span> { return<\/span> }\n\n            service.loadNearbyFriends<\/span> { [weak self<\/span>] friends in\n                self<\/span>?.friends<\/span> = friends\n            }\n        }\n    }\n}<\/code><\/pre>\n
Above it\u2019s perfectly fine to capture self<\/code> strongly within our task\u2019s closure, since once the cache check has been performed and our call to loadNearbyFriends<\/code> has been dispatched, then that closure will be deallocated.<\/p>\n
It\u2019s great to see new diagnostics added to Swift that causes warnings to be omitted for common mistakes, anti-patterns and potential memory issues. Although such diagnostics might require us to have to slightly over-specify<\/em> our code in certain places, requiring us to be explicit about potentially problematic self<\/code> captures is definitely a good thing, since it\u2019s such a common source of retain cycles and other memory management bugs.<\/p>\n
Thanks for reading!<\/p>","protected":false},"excerpt":{"rendered":"
New in Swift 6.4 (which at the time of writing is in beta as part of Xcode 27) is a warning which is emitted when a nested closure performs a weak capture while the parent closure implicitly captures that object as a strong reference. At first glance, that new diagnostic could be a bit puzzling, […]<\/p>\n","protected":false},"author":1,"featured_media":9891,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rop_custom_images_group":[],"rop_custom_messages_group":[],"rop_publish_now":"initial","rop_publish_now_accounts":[],"rop_publish_now_history":[],"rop_publish_now_status":"pending","footnotes":""},"categories":[1,15],"tags":[],"class_list":["post-9841","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-explore","category-world"],"_links":{"self":[{"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/posts\/9841","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/comments?post=9841"}],"version-history":[{"count":1,"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/posts\/9841\/revisions"}],"predecessor-version":[{"id":9892,"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/posts\/9841\/revisions\/9892"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/media\/9891"}],"wp:attachment":[{"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/media?parent=9841"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/categories?post=9841"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/tags?post=9841"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}