Thanks for being a part of WWDC25!

How did we do? We’d love to know your thoughts on this year’s conference. Take the survey here

Failed to open URL asynchronously

I have a problem with the URL schemes under iOS 18. Data is being sent from one app to another app. The amount of data varies. It can sometimes be more than 5 MB.

With iOS 18, errors often occur when sending large amounts of data. The error message is: "Failed to open URL asynchronously". If I send the data once again in this case, it works.

To reproduce the error quickly, I wrote two small apps. AppA sends data to AppB. AppB calls AppA and AppA sends data to AppB again. The whole thing runs in an endless loop.

Code snippet:

// AppA
// The file to which fileUrl points contains a 4 MB string. 
// The string consists of only one letter “AAAAAA....”
let dataStr = try String(contentsOf: fileUrl, encoding: .utf8)
if let url = URL(string: "appb://receive?data=\(dataStr)") {
    UIApplication.shared.open(url, options: [:]) { (result) in
        if !result {
            os_log("can't open url", type: .error)
        }
    }
}
// AppB
DispatchQueue.main.asyncAfter(deadline: .now() + 2.0) {
    if let returnUrl = URL(string: "appa://return") {
        UIApplication.shared.open(returnUrl)
    }
}

If the test is started, the error occurs approximately 15-20 times per hour. The first error occurs very quickly if the device is restarted prior to this. As soon as the error occurs, we end up in os_log(“can't open url”, type: .error)

I know the possibility of exchanging the data via AppGroups, but cannot use it in our case.

Tested with following devices:

// The error occurs:
iPhone 11 with iOS 18.4.1
iPhone SE with iOS 18.5

// The error does not occur
iPhone 8 with iOS 16.7.10
iPhone 16 simulator on a M1 MacBook (macOS 15.4.1)

Unfortunately, there is no other error message in the "Console" app. Except "Failed to open URL asynchronously".

There were no problems at this point between iOS 12 and iOS 17.

My question is now, are there new limitations to the URL schemes under iOS 18 or is it a bug?

Since it sounds like the behavior changed across iOS versions, you can file a bug report to report a regression. If you do, post the FB number here for the record.

That said, multi-megabyte URLs are unusual, and this means your use here likely falls outside the original intention of the openURL functionality — it isn't a general purpose data exchange API. If you zoom out from your current implementation details, what is the underlying problem that you are solving for?

— Ed Ford,  DTS Engineer

I have created a bug report (FB18172172)

We want to exchange data between apps without storing data anywhere. This rules out the possibility of AppGroups. If there is any problem when exchanging data and starting the recipient app, the data should simply be gone and not be stored anywhere. The Share extensions are also ruled out because the user should not see a dialog when the other app is started. In addition, the data should only be exchanged with our apps. The whole thing should also work without the Internet. A server is therefore also out of the question.

Data exchange using URL schemes has worked wonderfully in recent years. Only with the new versions has something changed without it being documented or it is a bug.

If there is an even better way, please let me know.

Thanks for the report, and those details. I'd still like more details — what's the motivator behind the data can't be stored to disk? Further, what does your second app do with this data blob upon receiving it? Display it to the user? Process it in some way? I want to keep walking this back to understand your needs that lead to this solution.

— Ed Ford,  DTS Engineer

Failed to open URL asynchronously
 
 
Q