Hello,  We release an App Clip back in December 2020, and everything was working just fine for the longest time. However, sometime relatively recently, not exactly sure when it started, the Domain URL Status started showing this “Cannot Reach AASA File” error; and consequently, the App Clip invocation fails now.   The API Validation Tool is saying “Error cannot parse app site association file” as the reason.   We have not made any changes in the App / App Clip, and the associated domain is still set as appclips:mobileapp.caesars.com     The Apple App Site Association file hasn’t been changed either, and the format still matches that specified on https://developer.apple.com/documentation/app_clips/associating_your_app_clip_with_your_website. The AASA file returns no problem in a browser and from curl command as you can see below: Last login: Tue Jul 12 09:11:11 on console curl -v https://mobileapp.caesars.com/.well-known/apple-app-site-association *  Trying 192.230.66.155:443... * Connected to mobileapp.caesars.com (192.230.66.155) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/cert.pem * CApath: none * (304) (OUT), TLS handshake, Client hello (1): * (304) (IN), TLS handshake, Server hello (2): * (304) (IN), TLS handshake, Unknown (8): * (304) (IN), TLS handshake, Certificate (11): * (304) (IN), TLS handshake, CERT verify (15): * (304) (IN), TLS handshake, Finished (20): * (304) (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / AEAD-AES128-GCM-SHA256 * ALPN, server accepted to use h2 * Server certificate: * subject: C=US; ST=Nevada; L=Las Vegas; O=Caesars License Company, LLC; CN=*.caesars.com * start date: Jul 28 00:00:00 2020 GMT * expire date: Oct 14 12:00:00 2022 GMT * subjectAltName: host "mobileapp.caesars.com" matched cert's "*.caesars.com" * issuer: C=US; O=DigiCert Inc; CN=DigiCert SHA2 Secure Server CA * SSL certificate verify ok. * Using HTTP2, server supports multiplexing * Connection state changed (HTTP/2 confirmed) * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 * Using Stream ID: 1 (easy handle 0x12b810400) > GET /.well-known/apple-app-site-association HTTP/2 > Host: mobileapp.caesars.com > user-agent: curl/7.79.1 > accept: */* >  * Connection state changed (MAX_CONCURRENT_STREAMS == 128)! < HTTP/2 200  < content-type: application/json < last-modified: Tue, 29 Mar 2022 17:01:12 GMT < accept-ranges: bytes < etag: "8fb84c988e43d81:0" < server: Microsoft-IIS/10.0 < x-powered-by: ASP.NET < p3p: CP="DEVa TAIa CURa STA NAV COM PUR ADMa IND OUR CONa" < date: Tue, 12 Jul 2022 14:13:38 GMT < content-length: 94 < set-cookie: TLTUID=14DC54AD87C0CE8FE7D996B6462E29DA; Domain=caesars.com; Expires=Sun, 03-Mar-2024 14:13:38 GMT; Path=/ < set-cookie: TLTSID=CE56628D3C96FCC7119B576D984C3119; Domain=caesars.com; Path=/ < set-cookie: visid_incap_2158031=HUn4aDqCSo+WP67o1FH52pGBzWIAAAAAQUIPAAAAAAB3XfZ+ShjpzS05c/MsxAjO; expires=Wed, 12 Jul 2023 06:18:20 GMT; HttpOnly; path=/; Domain=.caesars.com < set-cookie: nlbi_2158031=q84xFZbqUDGbu15TtwLJSwAAAABBaYw0KJNNHWaeJ2p5/DNV; path=/; Domain=.caesars.com < set-cookie: incap_ses_979_2158031=w4MXYaAK4R7YuhVx/BuWDZGBzWIAAAAA8Dt1Yyj9qc8nFNp3F96Kxg==; path=/; Domain=.caesars.com < x-cdn: Imperva < x-iinfo: 11-18630097-18630107 NNNY CT(35 74 0) RT(1657635217346 57) q(0 0 0 1) r(0 0) U12 <  {  "appclips": {   "apps": [    "YXFZ76LPGW.com.caesars.playbytr.Clip"   ]  } * Connection #0 to host mobileapp.caesars.com left intact Again, this was all working without any problems and just suddenly stopped for some reason without any apparent explanation. I’ve looked at similar issues reported in the forums with no luck helping solve this issue yet. Any guidance/help would be greatly appreciated!

Hoping someone can help here as I have been banging my head on this problem for awhile now. I’m trying to implement CloudKit Sharing in a SwiftUI app to send data objects between users using UICloudSharingController. I have closely followed Apple’s example from https://developer.apple.com/documentation/cloudkit/shared_records/sharing_cloudkit_data_with_other_icloud_users I can create the CKShare object and send it between users via Messages no problem. Now here comes the problem… If my app is already running in the background when you tap the share object in Messages, then the CKShare is fetched and extracted no problem at all. However, if the app is NOT running in the background already, then the app will launch (i.e. cold start) but userDidAcceptCloudKitShareWith never gets called, so the share object is never fetched and extracted. I know the problem is not with creating, fetching, and extracting the CKRecord and CKShare objects because it works just fine if the app is already running. Seems to be something wrong in the app launch setup. I validated userDidAcceptCloudKitShareWith is not called by manually attaching the debugger and setting a breakpoint on that function, which never gets called in the app launch process unlike when the app was already running. Interestingly, I installed Apple’s sample app from the link above on my two devices (different iCloud accounts) to validate its implementation actually worked, but I got the same result. I can share those contact objects no problem if the app is already running when I accept the share, but it fails if the app is not already running. I would like to believe Apple’s sample apps would work as the example implementation, which I mirrored. Maybe it’s something with my Xcode setup? I am running version 13.2.1. If anyone has any suggestions on how to resolve this issue, I would be most grateful. I scoured the forums and tried everything suggested I could find. My head hurts. Here is the AppDelegate and SceneDelegate code. @main class AppDelegate: UIResponder, UIApplicationDelegate {   func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {     print("AppDelegate.didFinishLaunchingWithOptions")     return true   }   // MARK: UISceneSession Lifecycle   func application(_ application: UIApplication, configurationForConnecting connectingSceneSession: UISceneSession, options: UIScene.ConnectionOptions) -> UISceneConfiguration {     // Called when a new scene session is being created.     // Use this method to select a configuration to create the new scene with.     print("AppDelegate.configurationForConnecting")     return UISceneConfiguration(name: "Default Configuration", sessionRole: connectingSceneSession.role)   }   func application(_ application: UIApplication, didDiscardSceneSessions sceneSessions: Set<UISceneSession>) {     // Called when the user discards a scene session.     // If any sessions were discarded while the application was not running, this will be called shortly after application:didFinishLaunchingWithOptions.     // Use this method to release any resources that were specific to the discarded scenes, as they will not return.   } } // SceneDelegate class SceneDelegate: UIResponder, UIWindowSceneDelegate {   var window: UIWindow?   @ObservedObject var cloudKitManager = CloudKitManager()   func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {           print("SceneDelegate.willConnectTo")                let contentView = ContentView()     if let windowScene = scene as? UIWindowScene {       let window = UIWindow(windowScene: windowScene)       window.rootViewController = UIHostingController(rootView: contentView)       self.window = window       window.makeKeyAndVisible()     }   }   func windowScene(_ windowScene: UIWindowScene, userDidAcceptCloudKitShareWith cloudKitShareMetadata: CKShare.Metadata) {     print("MySceneDelegate: userDidAcceptCloudKitShareWith")           guard cloudKitShareMetadata.containerIdentifier == cloudKitManager.containerIdentifier else {       print("Shared container identifier \(cloudKitShareMetadata.containerIdentifier) did not match known identifier.")       return     }               let acceptShareOperation: CKAcceptSharesOperation = CKAcceptSharesOperation(shareMetadatas: [cloudKitShareMetadata])           debugPrint("Accepting CloudKit Share with metadata: \(cloudKitShareMetadata)")           acceptShareOperation.qualityOfService = .userInteractive     acceptShareOperation.perShareCompletionBlock = {meta, share, error in       print("CloudKit share was accepted")       // Hold the accepted share's metadata so it can be fetched next       let rootRecordID = meta.rootRecordID       if let error = error {         debugPrint("Error accepting share with root record ID: \(rootRecordID), \(error)")       } else {         debugPrint("Accepted CloudKit share for root record ID: \(rootRecordID)")         self.cloudKitManager.sharesAccepted.append(cloudKitShareMetadata)       }     }     acceptShareOperation.acceptSharesCompletionBlock = { error in       if let error = error {         debugPrint("Error accepting CloudKit Share: \(error)")       } else {           self.cloudKitManager.fetchSharedRecords()         }     }     cloudKitManager.container.add(acceptShareOperation)   } }

Regarding, "all apps that allow for account creation must also allow users to initiate deletion of their account from within the app." If the app has a "Create Account" link that opens in Safari where the account is created (i.e. outside the app), is the app still considered to "allow for account creation" and therefore required to allow for account deletion per the new requirement being enforced?

I have registered the following URL as an advanced App Clip experience: https://mobileapp.caesars.com/appclips/findmyroom?destination=las_vegas&property=clv Taking advantage of URL Prefix Matching per the documentation on https://developer.apple.com/documentation/app_clips/configuring_your_app_clip_s_launch_experience, I should be able to use the following URL: https://mobileapp.caesars.com/appclips/findmyroom?destination=las_vegas&property=clv&wing=JT&room=865 The only difference is the addition of two more parameters that I handle for setting up the UI. However, when I create a QR code for this second URL and scan it, I am taken to the caesars.com website in Safari instead of the App Clip as if the invocation fails. I have done some testing with other URLs as well and found that regardless if I register the more-specific or less-specific URL, only the exact URL that is registered will launch the App Clip. In other words, the URL prefix matching is not working. I had no problems during pre-release testing with Test Flight builds; however, since going live, the more-specific URLs are not working via URL prefix matching as expected. Please look into this issue and advise on how to resolve.