swift-frontend memory usage

Ha, although I don't think a 64gb max will save you from this. I have exactly that machine sat in it's box because of this bug. I need Xcode 12 and can't use Monterey yet 😢

Seems like SwiftUI is tripping up Xcode 13 a lot. Commenting out a random ScrollView or other view sometimes works. swift-frontend process has gone so high to 145GB at one point and I only have 32GB RAM on this machine (Big Sur 11.6.1 / Xcode 13.1).

For what it's worth, running Xcode 13.2 beta in Rosetta mode made this stop happening for me (despite it happening when not running in Rosetta mode).

It was fun getting an "out of application memory" popup like ten minutes into using this 64GB machine, though.

Xcode 13.1 was unusable and crashed my machine repeatedly throughout the day yesterday. Downgrading to 12.5.1 as suggested by @motw enabled me to get back to work. Thank you for sharing this workaround!

Should you need Xcode 13, ymmv but I'm not seeing any memory consumption issues on Xcode 13.0 (13A233), from an M1 Max MBP running Monterey 12.0.1 (21A559).

I'm also getting this problem in Xcode 13 on both Big Sur on an Intel MBP, and on Monterey on an M1Pro MBP. Running Xcode in Rosetta mode also fixed it for me so far.

I have also been having this issue on a 2018 Intel MacBook Pro, on Xcode 13.1. Tried to downgrade to Xcode 12, but I am running Monterey :(( This is a really debilitating bug, that I hope gets more attention.

So aside from this forum post and having a month old feedback assistant request (with no response) does anyone have any experience how to get Apples attention on this?

I have a case going with Apple, reported through the Feedback app. I've sent them a project that confirms the bug, a video showing the memory growth when using Xcode 13.1, and a link to this forum thread.

In my case, the memory running wild happens if the Canvas fails to load/build a preview. If I rebuild the project (Commad+B) after the canvas fails to load, the swift-frontend processes are killed.

I have stopped using the Canvas for now, and instead use Command+R to preview changes in the simulator, until Apple fix the issue.

Spotlight indexing hasn't stopped on my M1 machine for almost a month and a half, it's using something like 70% of two or three cores, continuously. Originally I thought it was the 11.6 update that did it but now I'm pretty sure it's this bug. I reported it in FB9639588 and linked back here. Still no movement on the bug.

This issue appears to be fixed for me in 13.2 beta 2 (13C5066c). I did a full clean build (and nuked derived data) and the issue is gone!

What works for me as a workaround, just two things: (1) don't use automatic preview - if you can make due with the Simulator, and (2) keep the activity monitor up so when swift-frontend shows its ugly head you can quit it... don't force quit, and don't quit xcode. Good luck.

Just a workaround until something permanent. Two things: (1) don't use automatic preview - if you can make due with the Simulator, and (2) keep the activity monitor up so when swift-frontend shows its ugly head you can quit it... don't force quit, and don't quit xcode. Good luck. 

This thread is my new hang out spot when I can't get any work done

I'm having the same issue. To the point where I can't even continue working anymore. When I try to run, my memory start to build up until in need to shut these processes down.

Can someone respond to this draft if a fix is found?

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.