I have a UIKit Mac Catalyst app, optimized for Mac idiom, with an NSToolbar manually added to the windowScene. Is it possible to implement a full-height inspector sidebar with this setup? It seems to always appear underneath the toolbar in my testing. Even if I remove my NSToolbar and let the system create a toolbar from a NavigationStack. It works on iOS - stretches all the way up the window splitting the app into two columns. var body: some View { NavigationStack { AnimalTable(state: $state) .inspector(isPresented: $state.inspectorPresented) { AnimalInspectorForm(animal: $state.binding()) } .toolbar { Button { state.inspectorPresented.toggle() } label: { Label("Toggle Inspector", systemImage: "info.circle") } } } }

I believe when trait collections were first introduced, the values were unknown initially, so you could put code that accessed those values in traitCollectionDidChange because it always changed from unknown to known values. An iOS update changed this behavior to provide an estimated initial value, so traitCollectionDidChange would only get called if its value changed from its initial value. This required us to optimize for the trait collection in viewDidLoad for example to handle its initial value and handle changes in traitCollectionDidChange. In iOS 17, it’s stated if you access traits before the view is added to the hierarchy, the values won’t be up-to-date. It’s recommended to use viewIsAppearing instead of viewDidLoad and viewWillAppear. traitCollectionDidChange is still invoked but deprecated replaced with a new registration API to be informed when a value changes. My question is, will the code written using the previous approach still work when compiled with the iOS 17 SDK? Meaning, does the system still provide an estimated initial value and inform you if it changed upon getting added to the view hierarchy? Or is this a breaking change in behavior that will require us to rewrite our logic moving code that accesses the traitCollection from viewDidLoad to viewIsAppearing (and be really careful in doing so because this function is called every time the view appears not just once)? Are there any scenarios where the code written for iOS 16 would stop working once compiled for iOS 17 if you access trait values in viewDidLoad and handle changes in traitCollectionDidChange? I’m trying to understand if I can keep my existing code and use the new approach going forward or if I need to revisit existing code that utilizes trait collections. Thanks!

Is it ok to call requestContentEditingInput for a lot of PHAssets to get URLs for their full size image? It seems odd because I would not be using the content editing input to actually modify these images. Is that ok are or are there implications to be aware of? Use case: I want to allow the user to share multiple PHAssets via UIActivityViewController. I can download and share an array of UIImage, which works, but I found if you tap Copy the app freezes for like 1 second for each photo (10 seconds if you shared 10 photos). Profiling the app it looks like iOS is spending the time creating a PNG for each image. Also it's probably not a good idea to store huge images in memory like that. I figured I'd try sharing an array of URLs to the images. Seemingly the only way you can get a URL for a photo is by requesting a content editing input for the asset and accessing its fullSizeImageURL property. Is this a good idea, and is this the right approach to share PHAssets?

I am trying to figure out how to programatically install a per-user launchd agent - I have an executable Swift script I wrote and I need macOS to enforce it always be running. I found the SMJobBless sample code which I could play with to see how this works, but it hasn't been updated since it was last built with Xcode 4.6. As you can imagine it doesn't compile in Xcode 10. I was able to get it to build by upgrading to the recommended project settings, increasing the deployment target, and selecting my team for the two targets. Following the ReadMe I need to run ./SMJobBlessUtil.py setreq to configure the Info.plists appropriately. These instructions are out of date but eskimo was kind enough to provide updated instructions here to find the .app url. But when I do this and run the command I receive the following output:MacBook:SMJobBless Jordan$ ./SMJobBlessUtil.py setreq /Users/Jordan/Library/Developer/Xcode/DerivedData/SMJobBless-dffakkidazmiowcishyrborysygm/Build/Products/Debug/SMJobBlessApp.app SMJobBlessApp/SMJobBlessApp-Info.plist SMJobBlessHelper/SMJobBlessHelper-Info.plist Traceback (most recent call last): File "./SMJobBlessUtil.py", line 424, in main() File "./SMJobBlessUtil.py", line 418, in main setreq(appArgs[1], appArgs[2], appArgs[3:]) File "./SMJobBlessUtil.py", line 360, in setreq appToolDict[bundleID] = toolNameToReqMap[bundleID] KeyError: '$(PRODUCT_BUNDLE_IDENTIFIER)'It would seem this python script isn't able to work with the newer project structures, not surprisingly. I wasn't able to find any other information on how to accomplish this task in the modern days. So could you please explain how to go about this? 🙂I have an executable .swift file and a .plist that works when loaded from ~/Library/LaunchAgents/ ready to be added to an existing Xcode project. Thanks!

It was discussed in What's New in Photos APIs at WWDC that we should avoid using NSPredicate for custom fetch options if at all possible for performance purposes. In my app, I'm using NSPredicate to get only images from the user's library. I'm not seeing an API that would allow me to get assets from a specific collection filtered to just images without the use of NSPredicate though. Is there a more efficient way to perform this query that I'm not seeing?let photoLibraryFetchResult = PHAssetCollection.fetchAssetCollections(with: .smartAlbum, subtype: .smartAlbumUserLibrary, options: nil) let assetCollection = photoLibraryFetchResult.firstObject! let fetchOptions = PHFetchOptions() fetchOptions.predicate = NSPredicate(format: "mediaType = %d", PHAssetMediaType.image.rawValue) let fetchResults = PHAsset.fetchAssets(in: assetCollection, options: fetchOptions)

Is it possible for an app using NSPersistentCloudKitContainer to enable sync in the background, if so, how? Install app on your iPhone and iPad, create some data, it automatically syncs to both and life is good Close the iPad app Modify the data on iPhone Desired behavior: The backgrounded iPad app should sync (even if it takes a while) and be informed that its local database has finished syncing or similarly that changes were made. The use case is I want to reload my widget when data changes so it's up-to-date, so I need my app to sync it in the background, then notify when it's complete to be able to trigger the widget reload. I am concerned it will be a poor widget experience if it's always showing stale data until they manually open the app to initiate sync - kind of defeats the purpose of widgets. ha According to this post, they found sync is never run in the background. Is this not the case, or has it changed in iOS 15? Thanks!

I have a UIViewController that initially does not display any scrollable content, but later on I add a child view controller that does scroll - a UIHostingController whose rootView is a GeometryReader containing a ScrollView. The problem is when you scroll the UINavigationBar remains transparent I’m sure because it couldn’t find a scroll view in the view hierarchy. There is an API to specify which scroll view to use but that’s a UIScrollView. How can I tell it about my SwiftUI scroll view? viewController.setContentScrollView(scrollView, for: .bottom)