swift-frontend memory usage

I hope someone will get fired after this good job. And they have the guts to reject app that steal too many resources from the iPhone. I am very disappointed

Happened to me as well. Exactly the same as described. For me it happened on two different projects as soon as I started adding scale effect animations. I'm using Xcode 13.1 on Monterey 12.0.1. (M1 mini 2020 8gb). Tried the rosetta workaround, didn't help.

I hope Apple fixes this soon or at least informs us about the exact cause so we can find a reliable workaround.

I deep dived into my project and was able to avoid issue for one of my Views. By converting .padding(.leading, 20) to .padding(20) for a few Views (strangely it only occurs for horizontal paddings) resolved the issue.

But it is not about paddings only, it is mixture of some cases which I could not figure out. Tried creating an empty view and added a few .padding(.leading, 20), problem wasn't there. My original View has pretty complex view structure, so it is almost impossible to create a workaround just by modifying my code.

This is really terrible as I was learning SwiftUI and this would be my first SwiftUI project that I'd be uploading to AppStore. Now, I am about to start forgetting what I have learned. I can't imagine what kind of trouble I'd be in if this was a commercial project.

Same issue here. In my case this bug appeared while using .padding(.horizontal) and .font(.system(size:)) modifiers inside GeometryReader with dynamic values that are calculated based on the height of the GeometryProxy and additional values.

I could resolve this problem for now as soon as I moved the concerning views (with their modifiers) out of the body property and instead used custom @ViewBuilder functions to create my views:

@ViewBuilder func getDateText(in page: GeometryProxy) -> some View {

    HStack {

      Text(date.formatted(date: .abbreviated, time: .shortened))

        .font(.system(size: (page.size.height * 1.11) * textFontSize))

      Spacer()

    }

    .padding(.horizontal, page.size.width * 0.05)
}

Then inside body I called the @ViewBuilder functions like this:

GeometryReader { page in
    getDateText(in: page)
 }

I have not tested this workaround in other situations, but hope that this is helpful for someone else as well.

I think too, problem somewhere around GeometryReader and .padding(). I solved this problem for my code (post on the first page). But it very strange and mistery... I hope Apple fix this in next updates.

In my case replacing .cornerRadius(<value>) with .clipShape(RoundedRectangle(cornerRadius: <value>) helped 🤷🏻‍♂️

Xcode 13.1 on BigSur

Same issue here on latest release: changing .padding from 10.0 to 10 solved it for me. Of course this isn't helpful if you need a fractional value. Perhaps it is a rounding error causing some memory leak in the code.

It's very bad. I found that if the data read by geometryreader is captured by a func but not used, this problem will occur. Memory occupies 30G quickly, and the hard disk reads and writes a lot. Even if Xcode is turned off, it still doesn't help. You must to click to turn off by yourself！

I encountered this problem of excessive memory usage of Swift-frontend when I declared a variable without an explicit type.

let  defaultMargin = 16.0

When I set it with CGFloat, I don't have the problem any more.

let  defaultMargin: CGFloat = 16.0

I hope this can help.

For anyone else experiencing this issue, i found a workaround. Use your source control to find the specific part of your code that causes the issue. Then try to look if there is a small mistake in your code. If not, try putting your code on another location (helped for me for some SwiftUI code).

i noticed that it looks like the compiler gets stuck on a code mistake, or something like that.

I had this issue with part of my code which had no errors at all. Just moving it did the job for me.

Keep in mind to keep your Activity Monitor open and keep an eye on the two processes that can build up the memory.

This bug seems to have been resolved in Xcode 13.2 beta version. When you exit Xcode 13.1 and run it on Xcode 13.2 beta, the swift-frontend thread temporarily increases and then the memory is released. However, when Xcode 13.1 version is running, the same problem occurs even if it runs at 13.2 beta. Please run only Xcode 13.2 beta and test it.

Can confirm that Xcode 13.2 RC appears to have fixed this bug.

Working on XCode 13.1, Monterey - confirming saw the issue where SourceKitService & swift-frontend memory usage would each explode to around 40GB. 

I saw this issue fairly quickly - within minutes - of using GeometryReader in a project. After going through above thread, I decide to remove the code using GeometryReader, force quit above services, closed and re-opened XCode. 

So far, I do not see any spike in memory in the above services. SourceKitService is at about 70MB, XCode at about 1.11 GB. Launched app on device and, so far, XCode & system are stable with above usage. 

Would love to know what the issue is here

Unfortunately, the issue is still present within XCode 13.2 RC in 1 of my complex iOS projects. I'll reopen the issue report to Apple.

The issue is still present in XCode 13.2 Final Release. This is a show stopper! Apple Devs, please soon fix the issue. Xcode is useless since 2 months.

My project does not build anymore, neither with simulator or real device. Analysing the project does not work neither. Automatically running background tasks e.g. for Canvas prevent from continued software development (without user triggered build functionality). RAM memory consumption grows up to 100 GB and more. Included Swift packages compile correctly, but compilation of own modules lasts for ever in dead loop without compilation warning. There's some long lasting background build activity, if patient, the build process may finish (before the MBP resets). This behaviour is non deterministic: I've experienced the same project may compile/run after a build folder clean without any code change. I was somehow lucky to first progress with XCode 13.2 RC (13C90), but the local workaround does not work anymore. Please help out.