Summary I'm using Background Assets to download Apple-hosted Asset Packs(downloadPolicy = onDemand). The first download cancellation succeeds, but on the second and subsequent downloads, progress.cancel() fails to work and the download completes to the end. Environment iOS 26.0 – 26.3 RC (all produce the same result) Xcode Version 26.2 (17C52) Using Apple-hosted Asset Packs Steps to Reproduce Start downloading an Asset Pack Call progress.cancel() during download → Succeeds Start downloading the same Asset Pack again Call progress.cancel() during download → Fails (download completes to the end) Observed Error Logs After 1st cancellation: A download with the ID "X-XXXXXXXX-XXX" failed: Error Domain=NSURLErrorDomain Code=-999 "cancelled" ↑ This is expected (cancellation succeeded) The fact that version 0 of the asset pack with the ID "X-XXXXXX-XXX" finished being downloaded couldn't be reported: Error Domain=NSCocoaErrorDomain Code=3851 "Property list invalid for format: 200 (property lists cannot contain objects of type 'CFError')" ↑ Problem: Unable to serialize CFError to plist 2nd cancellation attempt: The download with the ID "X-XXXXXX-XXX" couldn't be canceled: Error Domain=BAErrorDomain Code=113 "The requested download operation failed because the download object did not exist." ↑ The download object we're trying to cancel supposedly doesn't exist Implementation Code // Cancel implementation func cancel(tag: String) async { let statusUpdates = AssetPackManager.shared.statusUpdates(forAssetPackWithID: tag) for await statusUpdate in statusUpdates { if case .downloading(_, let progress) = statusUpdate, progress.isCancellable { progress.cancel() } } } Analysis It appears that when the first cancellation occurs, the system internally tries to save the cancellation state to a plist, but fails to serialize the CFError object. This seems to cause an inconsistent internal state, preventing the system from correctly recognizing the download object on subsequent downloads. Questions Is there a workaround? Is there a planned fix for a future iOS version?

It is no longer displayed as a target for shortcut app actions. It was displayed until iOS 17.7. Tried with iOS 18.0 and 18.0.1 but it does not appear. Shortcuts created when under iOS 18 work fine. Only INPlayMediaIntent is supported and is targeted at iOS 15 and above, so no Extension is used and is handled directly in the app. Is anyone else suffering from the same problem?

I am developing an iOS app that supports INPlayMediaIntent. We are trying to increase the recognition rate of content names, which are song titles, using AppIntentVocabulary. As a sample, some extracts are shown below. <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>IntentPhrases</key> <array> <dict> <key>IntentName</key> <string>INPlayMediaIntent</string> <key>IntentExamples</key> <array> <string>Mezamashi Appで湖畔の朝を再生</string> <string>湖畔の朝をMezamashi Appで再生して</string> </array> </dict> </array> <key>ParameterVocabularies</key> <array> <dict> <key>ParameterNames</key> <array> <string>INPlayMediaIntent.playlistTitle</string> </array> <key>ParameterVocabulary</key> <array> <dict> <key>VocabularyItemIdentifier</key> <string>ID1</string> <key>VocabularyItemSynonyms</key> <array> <dict> <key>VocabularyItemPronunciation</key> <string>aogamagaeru</string> <key>VocabularyItemPhrase</key> <string>青ガマガエル</string> </dict> </array> </dict> <dict> <key>VocabularyItemIdentifier</key> <string>ID2</string> <key>VocabularyItemSynonyms</key> <array> <dict> <key>VocabularyItemPronunciation</key> <string>kohon no asa</string> <key>VocabularyItemPhrase</key> <string>湖畔の朝</string> </dict> </array> </dict> <dict> <key>VocabularyItemIdentifier</key> <string>ID3</string> <key>VocabularyItemSynonyms</key> <array> <dict> <key>VocabularyItemPronunciation</key> <string>kumageratachi no uta</string> <key>VocabularyItemPhrase</key> <string>クマゲラたちの歌</string> </dict> </array> </dict> </array> </dict> </array> </dict> </plist> When running on the iOS 17.5 simulator in Xcode 15.4, the results are as follows. mediaName = VocabularyItemIdentifier mediaIdentifier = nil <INMediaSearch: 0x6000026212c0> { reference = 0; mediaType = 0; sortOrder = 0; albumName = <null>; mediaName = ID1; genreNames = ( ); artistName = <null>; moodNames = ( ); releaseDate = <null>; mediaIdentifier = <null>; } However, when running on an iOS 17.5 device, the following applies. mediaName = VocabularyItemPhrase mediaIdentifier = VocabularyItemIdentifier <INMediaSearch: 0x301efd9e0> { reference = 0; mediaType = 5; sortOrder = 0; albumName = <null>; mediaName = 青ガマガエル; genreNames = ( ); artistName = <null>; moodNames = ( ); releaseDate = <null>; mediaIdentifier = ID1; } The results are not stable, for example, sometimes everything else returns null. I have tried everything, but it is just taking a long time. Does anyone have any advice on this?

https://developer.apple.com/documentation/app_clips/configuring_the_launch_experience_of_your_app_clip This document contains the following information. Important When users install the corresponding app for an App Clip, the full app replaces >the App Clip. Every invocation from that moment on launches the full app instead >of the App Clip. As a result, you must associate the full app with your website. >Additionally, the full app must handle all invocations and offer the same >functionality that the App Clip provides. How exactly can we do? The same Associate Domain is described in the entitlement of App Clips and Full App. Q1. is it only the Bundle ID of the App Clips that should be listed in the AASA file? For example, XXXXXXXXXXXX.jp.awesomeapp.Clip Only, XXXXXXXXXXXXXX.jp.awesomeapp. is not necessary? Q2. Is it sufficient to use onContinueUserActivity for Full App to process URLs in the same way as App Clips? Is the following correct? App Clips: @main struct AwesomeAppClip: App { var body: some Scene { return WindowGroup { ContentView() .onContinueUserActivity(NSUserActivityTypeBrowsingWeb, perform: handleUserActivity) } } Full App: @main struct AwesomeApp: App { var body: some Scene { return WindowGroup { ContentView() .onContinueUserActivity(NSUserActivityTypeBrowsingWeb, perform: handleUserActivity) } } I also looked at the sample code, but it didn't look like Full App was responding to the URL. https://github.com/apple-sample-code/FrutaBuildingAFeatureRichAppWithSwiftUI

I'm developing a CarPlay Audio app that works with both 13.x and 14.x. iOS 13.x uses Media Player framework and iOS 14.x uses CarPlay framework. The code for iOS 14.x is designed to work on 14.0 and above as shown below. @available(iOS 14.0, *) class CarPlaySceneDelegate: UIResponder, CPTemplateApplicationSceneDelegate {   var interfaceController: CPInterfaceController? However, when I run it on 13.7, it crashes when the app starts. I've found that using one of the following methods causes the app to crash: CPNowPlayingAddToLibraryButton CPNowPlayingMoreButton CPNowPlayingRepeatButton CPNowPlayingShuffleButton CPNowPlayingPlaybackRateButton CPNowPlayingImageButton Only the CPNowPlayingButton is ok. Why does code that should only work on iOS 14 and above affect iOS 13? The following simple code crashes when running on iOS 13: import UIKit import CarPlay @main class AppDelegate: UIResponder, UIApplicationDelegate {   func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {           if #available(iOS 14, *) {       _ = CPNowPlayingShuffleButton { (button) in       }     }     return true   }