swift-frontend memory usage

I think I've found a memory leak with GeometryReader. The memory footprint of swift-frontend grows 50gb> with this single line

I have detailed the issue here: https://github.com/Func-Main/swiftui-memory-bug

Is anyone able to confirm? I don't think this is an issue related to the purely to the .aspectRatio modifier, but rather GeometryReader in general.

This image was after 30 seconds

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

swift-frontend memory usage
 
 
Q