When I try to install Jetpack on my site, I expect an informative error if it fails.
Instead all reasons for failure give:

Known reasons for failure include blocked XML-RPC (such as a 403 at /xmlrpc.php) and Jetpack already existing in the database (the user gets "the jetpack plugin is already installedā when trying to install from wp-admin).
It would be very helpful to return errors that describe the problem we had with installing Jetpack.
Raised in priority due to several user reports and a steady uptick in metrics for install_jetpack_remote_failed.
(internal reference: p4a5px-2pQ-p2)
Not sure how to implement this one. Hoping to involve design to give some direction.
Removing from the wordpress-mobile Groundskeeping project until after it has a design review. Once a designer has a chance to add an update here, would you please re-add this to the Groundskeeping To Do list at https://github.com/orgs/wordpress-mobile/projects/7 at that time? Thank you!
I opened a separate issue https://github.com/wordpress-mobile/WordPress-iOS/issues/12497 to track the case where Jetpack is already installed and connected, since it seems like that should be handled differently from installation errors.
To test:
/xmlrpc.php for the site and verify a 403 Forbidden error is returned.Result: Jetpack install flow fails with the generic error "Jetpack could not be installed at this time" and that error could be more helpful. (2min)
Tested with WPAndroid 13.5-rc-1 on Pixel 3 Android 10 on uptight-gorillas.jurassic.ninja with xmlrpc.php returning 403 Forbidden.
Would it be possible to detect the 403 and respond with something like the following in this case?
Jetpack could not be installed at this time. XML-RPC returned 403 Forbidden. Please check any security plugin settings to make sure XML-RPC is not blocked.
Also see https://github.com/wordpress-mobile/WordPress-iOS/issues/12793.
Here are a few more cases which would be nice to coverāand let me know if you would prefer these as separate GitHub issues (if we don't have a better error message to give for these cases, we could just at least mention what HTTP error does get returned and stop there).
xmlrpc.php returns 404 Not Found.xmlrpc.php returns 405 Disabled.If I'm not very technical, "Jetpack could not be installed at this time. XML-RPC returned 403 Forbidden. Please check any security plugin settings to make sure XML-RPC is not blocked." is a bit scary.
Is there a way to redesign the screen a bit so that the headline is "We couldn't finish installing Jetpack." instead of "There was a problem." and then smaller text contains the detail "Why? Jetpack couldn't access your XML-RPC file, possibly because a plugin's security settings are blocking it. Check your settings and try again, or contact support."
I've been checking this out, and I saw two problems:
1 - In the relevant area of the code, we get an error code 7.
This on WPApiError means just unknown. And this is the case since the backend returns a error key: "error": "SITE_IS_JETPACK", which is unknown by the general WPKit library.
But the key is known by the JetpackInstallError description.
2 - Looking at the raw HTTP Error code returned by the network request, it is a 400 (Bad Request), and not 403.
Thinking about the "error": "SITE_IS_JETPACK" error, and this being an install Jetpack request, I'd assume that the meaning of the 400 is:
"You can not install Jetpack on a site that already is jetpack."
The real problem (maybe):
So, my guess is that the real problem is on the previous step, on that silent error when logging in to Jetpack form the app (on the video at 1:20).
One last thing I noticed is, every time the user opens the Stats section, there's a call to XMLRPC getOptions, that returns things like jetpack_version and jetpack_client_id.
A wild guess is that, after the Jetpack Install and Login succeeded, the app search for these fields to see if Jetpack is indeed installed, and since this call DOES return a 403 error, the absence of this information is interpreted as Jetpack not installed.
If we can save the reason for the getOptions, when it's triggered, we could use it to know what indeed we don't have the information because of other reasons (like blocking access to XMLRPC in this case)
Is there a way to redesign the screen a bit so that the headline is "We couldn't finish installing Jetpack." instead of "There was a problem." and then smaller text contains the detail "Why? Jetpack couldn't access your XML-RPC file, possibly because a plugin's security settings are blocking it. Check your settings and try again, or contact support."
I like @michelleweber 's suggestions, though the copy might be a bit too long for the design pattern. Ideas for shortening
We couldn't install Jetpack
Check plugin settings to see if any are blocking XML-RPC file access
[Retry]
Most helpful comment
If I'm not very technical, "Jetpack could not be installed at this time. XML-RPC returned 403 Forbidden. Please check any security plugin settings to make sure XML-RPC is not blocked." is a bit scary.
Is there a way to redesign the screen a bit so that the headline is "We couldn't finish installing Jetpack." instead of "There was a problem." and then smaller text contains the detail "Why? Jetpack couldn't access your XML-RPC file, possibly because a plugin's security settings are blocking it. Check your settings and try again, or contact support."