Signed up on day one but still haven't received an offer to buy the DTK. Sign up page still says "We’ll review your application and get back to you soon."
Reading about other devs on Twitter and co. who already bought the kit makes me wonder if my application went through properly.
Post
Replies
Boosts
Views
Activity
I'm trying to convert some of my internal CLI tools from Xcode projects to Swift packages.
When debugging, I need to be able to start the tool using a custom working directory relative to the project/package directory. I can set this in the scheme config under "Options - Working Directory - Use custom working directory".
It works fine for absolute paths but I can't figure out how to get a relative path (ie. 1 level down from the package directory).
Previously, I used $(PROJECT_DIR)/../ for this but for my Swift package based tools, this just ends up as / when starting the app. I also tried $(SRCROOT) but then Xcode even shows an alert The working directory "$(SRCROOT)" for scheme "PackageName" doesn't exist.
Does anyone know how to achieve this?
I'm struggling with getting a hierarchical SwiftUI List to perform well with large data sets.
Here's a demo repo: https://github.com/lemonmojo/swiftui-hierarchical-list-performance
There are three main problems:
Rendering of the list is slow if there are many items. (Just start the app and wait for the list to be rendered.)
Changing the selected item is very slow. (Tap/Click an item and wait for the selection to change.)
Updating the list is slow. (Press the "Shuffle" button.)
On an iPhone 13 Pro, it takes 6 seconds from tapping the app icon to the list being rendered. This was timed with a release build. Once the list has been rendered, it takes 8 seconds for the selection to change when tapping an item. Tapping the "Shuffle" button results in a 2 seconds delay before the updated list is rendered.
All three problems are much more pronounced on macOS (tested on a Mac Studio M2) where it even takes minutes(!) for the app to become responsive.
Instruments shows that 99% of the CPU time is spent somewhere deep inside SwiftUI. Various attempts have been made to fix the problems (as documented in the code) but none of them have been successful.
There are two different data sets included in the demo. One can switch between them by commenting out one of the let rootItem … declarations and commenting in the other in ContentView.swift. The default example has a flat list with 100.000 items. The "real-world" example has 4 folders, each containing 25.000 items which is faster to render initially, but as soon as you start expanding folders it's slow again.
Is there any way to make SwiftUI's list perform well on iOS and macOS with data sets greater than a couple thousand items? I'm especially worried about the selection performance. Why is selecting an item so slow once the list has been rendered?
I've created a repo that uses AppKit's NSOutlineView here and another one using UIKit's UICollectionView here. Obviously, both are blazing fast and have none of the issues I encounter with SwiftUI List.
Any ideas on how to improve the SwiftUI performance?
Many thx,
Felix