I'm having the same issue. I tried increasing the build number and still the build appears shortly on the website in the "Processing" state, and then disappears. After the first upload I got an email with an error message, which I resolved and haven't got any email since, but still any uploaded build is not listed on the website. Then I tried increasing the version string from 1.0 to 1.0.1 and the build number as well, and after reloading the website it showed a disclosure indicator with the label 1.0.1, but completely empty. After reloading the website one more time, even this indicator was gone again, and the website is completely empty like at the start of this whole experiment.

[quote='818356022, DTS Engineer, /thread/770279?answerId=818356022#818356022'] App Shortcuts need to be in your main app target [/quote] I have a non-SwiftUI app, so I guess this doesn't apply? I don't see how I could have App Shortcuts without a separate App Intents Extension. Is this AppShortcuts.xcstrings officially documented? I couldn't find it anywhere.

[quote='818239022, DTS Engineer, /thread/764435?answerId=818239022#818239022'] The app is running for a significant period of time. [/quote] I had launched the app at most a couple hours earlier. I had the app running for weeks before and never had this issue.

I just had this issue again on my own Mac with macOS 15.2. My app had been active for a while and had been able to resolve bookmarks. Then suddenly when trying to create new bookmarks I got the usual error. Restarting the app solved the issue.

Do you mean to the main target or the app extension? And should I keep the existing Localizable.xcstrings or delete it?

Here's a link to a sample project: https://www.swisstransfer.com/d/e8ad8888-ae2e-4371-8e82-0d5915c967c7 I really just created an empty macOS App project, added a target App Intents Extension named CompareIntent, and pasted the code I provided above in the CompareIntent.swift file. Then I build the project and copied the app into my Applications folder, and I can still reproduce the issue when running the app intent in Shortcuts.

[quote='817975022, DTS Engineer, /thread/767019?answerId=817975022#817975022'] Dispatching to the main thread (with a Swift Task) is an anti-pattern in this case [/quote] Correct, and as I mentioned, this poses the question of how to avoid race conditions when accessing my custom data needed both in SceneKit and in SpriteKit (since the first uses its own thread, and the latter is annotated @MainActor).

In the meantime I already filed FB15737374 and opened Case-ID 10297510 to discuss a different issue I'm having, and the TSI engineer suggested as a workaround to update the SpriteKit scene in its SKScene.update(_:) method (although the delegate methods seem to work as well), which poses the question of how to avoid race conditions when accessing my custom data needed both in SceneKit and in SpriteKit (since the first uses its own thread, and the latter is annotated @MainActor). For now, it is proving to be a difficult conversation.

[quote='815279022, DTS Engineer, /thread/769257?answerId=815279022#815279022'] I don't know where the VFS driver got that st_size from, but returning a size >~18 Exabytes seems like an unusual choice. [/quote] Thanks for pointing out the size issue. Today Paragon got back to me and confirmed that the developers will fix the wrong size returned for symbolic links.

After replacing the .heic images with .png ones, it finally worked.

[quote='815147022, DTS Engineer, /thread/766035?answerId=815147022#815147022'] SO, making sure this is clear, the performance "trick" here is to use your final scan storage format as your "intermediate" format instead of doing the entire scan in memory. If done properly, this means: [/quote] I'm not sure I understand. Do you mean that you would write the scan results to disk while the scan is in progress? Otherwise I don't get the "entire scan in memory" part. You're probably right that resuming a scan is easier in the iterative case. I'm not supporting that case (yet), so for now I'll stick to recursion.

[quote='813377022, floorish, /thread/764435?answerId=813377022#813377022, /profile/floorish'] I've received multiple reports from users that macOS 14.7.1 cannot create new bookmarks or resolve existing bookmarks. [/quote] Today I too was contacted by a user who updated from macOS 13 to 14.7.1 and was quite desperate since my app couldn't resolve or create bookmarks anymore. Restarting the Mac didn't help. Thankfully you already reported the same issue so I suggested to update to 15.1.1, which finally solved the issue.

After some more playing around perhaps I was able to find the real issue by reducing the setPage method to this: func setPage(_ page: Int) { pageViews[self.page].run(.removeFromParent()) // pageViews[self.page].removeFromParent() self.page = page let pageView = pageViews[page] pageContainer.addChild(pageView) } When this code runs, only the second sprite becomes visible, and when the first one should appear, its space is left empty. Could SKAction.removeFromParent() be the problem? Replacing that instantaneous animation with a simple call to SKNode.removeFromParent() allows both sprites to alternate correctly.

I just installed Xcode 16.2 beta 3. I was going to test @Stephane204's issue, but even when using Xcode 16.1 I get a different compiler error for this code: class GameViewController: UIViewController, SCNSceneRendererDelegate { let node = SCNNode() nonisolated public func renderer(_ renderer: any SCNSceneRenderer, didApplyAnimationsAtTime time: TimeInterval) { node.position.x = 0 } } I don't get Main actor-isolated property 'position' can not be mutated from a nonisolated context but I get Main actor-isolated property 'node' can not be mutated from a nonisolated context which I think is a different issue, as node is in fact a property of a main actor-isolated class, so this doesn't seem like a bug to me, although I have to say that I sometimes struggle to understand Swift Concurrency.

In other words, you do a shallow enumeration of a given directory, then repeat the shallow enumeration on whatever directories you find. This is actually the same thing you'd do with getattrlistbulk. Right. For some reason I thought it would be less efficient. Have or haven't? How are you copying files? FYI, if server side copying is an issue, this post has a code snippet for that. Have. To copy files, I'm just calling copyfile. I didn't know about server-side copying, but that may explain why every now and then a user complains that my app is slow, though they never got back to me explaining their setup or comparing the speed of my app to the that of the Finder. What's the actual failure? The copy itself failing, display issue(s), etc? I'm not sure, they simply replied "I just tried [in the Finder] and it did indeed loop!" I assume the "Preparing X files" display when starting a copy operation just kept counting up On the technical, the resource usage difference can easily be quite large, since "wide" hierarchies are much more common than "deep" hierarchies That makes sense. My app does a deep scan to determine what files to copy, then copies them, and finally stores the directory hierarchy so it can be compared with the next scan. My users also assume that the app kind of runs in the background and doesn't use too much resources, so I think I'll stick to recursion for now.