file uri scheme

Hello. Before attempting to modify a playlist you must first check the canEdit attribute (see https://developer.apple.com/documentation/applemusicapi/libraryplaylists/attributes-data.dictionary) to discover if it is possible to modify the playlist. If canEdit is false then attempts to modify the playlist will return an error. In the current version of these APIs, collaborative playlists aways have canEdit set to false. If you would like Apple to consider adding the ability to modify collaborative playlists please file an enhancement request asking for this functionality. You can file an enhancement request using the Feedback Assistant. If you file a request, please post the Feedback number here. If you're not familiar with how to file enhancement requests, take a look at Bug Reporting: How and Why?

Thank you for your post. It seems like a bug to me right now as this should work symbolEffect(.drawOn.byLayer, options: .repeat(.continuous)) Kindly complete a bug report and include the specific project you are showing here. Once you open the bug report, please post the FB number here for my reference. If you have any questions about filing a bug report, take a look at Bug Reporting: How and Why? Albert Pascual
  Worldwide Developer Relations.

So I just spent quite a bit of time restructuring things in my app to use the new AppStore.requestReview(in:) My app is all Objective-C so I had to add a single Swift file just wrap the single class method in a @objc wrapped method. Why they can't just declare the AppStore.requestReview method @objc is beyond me. Then I had to sandwich an NSViewController in the mix. Before SKStoreReviewController +requestReview did not rely on the presence of a view controller (SKStoreReviewController always shows the request in a separate alert). But the new API has a NSViewController parameter that is not optional And guess what... after doing all that I discovered the new AppStore.requestReview(in:) does the exact same thing as the deprecated SKStoreReviewController +requestReview. The NSViewController parameter which is not optional is completely ignored and the review is presented in a separate alert just like SKStoreReviewController. It is not presented as a sheet. What a complete waste of time. Seriously who

Thank you for sharing your experience with the navigationTransition. I understand that you are experiencing frustration due to the lack of a work-around or fix. To assist the team in understanding your usage of the control, I kindly request that you include the video you are sharing in your bug report. Once you open the bug report, please post the FB number here for my reference. If you have any questions about filing a bug report, take a look at Bug Reporting: How and Why? Albert Pascual
  Worldwide Developer Relations.

I've been wondering if there is a way to modify or even disable tones for indicating channel states. The behaviour regarding tones seems like a black box with little documentation. No. One of the PTT framework's requirements is to make sure that apps couldn't record the user without their knowledge, which is why the tone exists. I'll also note that, in practice, many apps actually integrate the tone into their experience by using a two-tone pattern where the system’s tone basically means I know you want to record and am working on it and the app then places a second tone that means your connection is now active and people can hear you, so start talking. However, this: For example; moving from a channel to another produces a tone which would fail a test case. I understand the reasoning fully, as it marks that the channel is ready to transmit or receive, but this doesn't mirror the behaviour of TETRA which would be wanted in this case. ...is actually a bug in your app, partially caused by a design mistake in th

Hello! We would like to investigate this issue further. Please file a feedback report with a sysdiagnose (diagnostic logs) from your Apple Vision Pro soon after attempting to install your app from TestFlight and reply to this thread with the feedback ID. You can learn more about filing feedback with Feedback Assistant. We’ll follow up via the feedback report. Thanks!

Do you mean that uploading to TestFlight a macOS app with an NSFileProviderReplicatedExtension + a file provider UI extension triggers the same error? That will be an issue in the app submission process, because these extensions are supported on macOS, as discussed here. I haven't tested this with macOS (yet). What I meant is that the two documents I listed before have the same contradiction for macOS as for visionOS. I am not sure if the availability of the sample code makes it more official. I mean, that page lists Mac Catalyst as supported while FPUIActionExtensionViewController.h states FPUI_AVAILABLE(ios(11.0), macos(10.15)) API_UNAVAILABLE(macCatalyst) I'll probably try this for macOS at some point in the future as the app is also available on macOS (with NSFileProviderReplicatedExtension), but my current File Provider UI code is based on UIKit (coming from iOS) so that is why I started with visionOS. Which is not really encouraging yet :-) From a developer's viewpoint the issue is pre

Thanks for reporting the discrepancy. Would you mind to file a feedback report for us and share your report ID here? I can file one as well, but you represent the developer community and, as an originator, you can get notified of the status change and follow up with it if that matters to you. Regarding the following: The same discrepancy seems to hold for macOS, but I'm currently focusing on Vision OS. Do you mean that uploading to TestFlight a macOS app with an NSFileProviderReplicatedExtension + a file provider UI extension triggers the same error? That will be an issue in the app submission process, because these extensions are supported on macOS, as discussed here. I haven't had a chance to try on visionOS yet... Best, —— Ziqiao Chen  Worldwide Developer Relations.

We are missing something for getting the SDK for this framework integration with our software. So, one small detail that's easy to miss here is that, technically speaking, EndpointSecurity is actually a library*, NOT a framework. In the SDK, its tbd file is at /usr/lib/libEndpointSecurity.tbd and its include files are in /usr/include/EndpointSecurity/. Note that those header files are the canonical documentation for the framework and include far more detail than the class reference. Please give them a very thorough review. *For the technically curious, this is because the endpoint security operates at the very lowest layers of the system and cannot risk entangling itself with ANY higher level component of the system. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

First off, a comment here: Both types of accessories/devices can be commissioned in the HomeKit ecosystem seamlessly. Each framework has its documentation: HAP: https://developer.apple.com/documentation/homekit/hmhomemanager CHIP: https://developer.apple.com/documentation/matter While the frameworks are conceptually similar, I think it's a mistake to think of them as direct equivalents to each other. The Matter framework is the easier of the two to explain— it's a hardware control framework you use to send commands to Matter accessories. There's a little bit of nuance in that you need to do pairing through the MatterSupport framework, but once you're paired, the behavior of the framework is relatively straightforward. However, that's not really how HomeKit works. HomeKit works at a much higher level than that and is basically manipulating the Home Ecosystem that's built on top of HomeKit. So, for example, when you call a basic API like HMCharacteristic.writeValue(...), what that actually does could be one of

You are right that some system-provided apps capture the split data based on distance, but there is currently no API that allows the access to the data or an easier way to do the calculation, and that's why I suggested that folks do the calculation based on the .distanceWalkingRunning samples. I’d suggest that you file a feedback report for an API to access distance-based split data – If you do so, please share your report ID here for folks to track. Best, —— Ziqiao Chen  Worldwide Developer Relations.

So while the first one took 3.5days, the two additional jobs that I submitted during that time all finished at the same time. So it was clearly doing some sort of batch processing. I messed up internal signing so had to restart. New submission took roughly 6 hours. I also submitted a tiny test file which also took the same 6 hours. So again - supports the batch processing theory. Anyways, new build for Intel only took 15 minutes or less. I walked away so the times are definitely improving for me. Just posting the update for others looking into this.

Thanks, Quinn. I think I normally wouldn't have worried too much about this, but since I'm in the midst of the Swift 6 concurrency migration, I was worried it was related to something in my code. I think the message should state more clearly that it's an internal speech synthesizer issue, not really a structural Swift Concurrency issue. I filed FB20484368. Thanks again for your help!