We had a similar situation with the form hosted in domain A and sending data in the API to domain B. The POST request from domain A contained the header "x-api-key", which is not related to domain B
The response to the OPTIONS request before the API request contained headers
1. Access-Control-Allow-Origin: https: // domainA
2. Access-Control-Allow-Headers: *
3. Access-Control-Allow Method: * This worked great for all browsers except those on iOS. As we finally found out, specifying a wild card * for Access-Control-Allow-Headers does not work for iOS browsers. In response to the OPTIONS request, you need to specify all the headers present in the POST request, even if some headers do not belong to the server in domain B. Only then will iOS send the POST request.
Change the response header to
Access-Control-Allow-Headers: Accept, Content-Type, X-Requested-With, x-api key (even if the x-api-key header is not processed on server B)

We had a similar situation with a form hosted on domain A and posting the data to an API on domain B. The POST request from domain A contained the header "x-api-key" that is not relevant for domain B
The response to the preflight OPTIONS request to the API contained the headers
- Access-Control-Allow-Origin:https://domainA - Access-Control-Allow-Headers:* - Access-Control-Allow-Methods:*
That worked fine for all browsers except those on iOS. As we finally found out, specifying the wild card * for Access-Control-Allow-Headers does not work for iOS browsers. In the response to the OPTIONS request you need to specify all the headers that are present in the POST request, even if some headers are not relevant for the server on domain B. Only then will iOS send the POST request.
Changing the response header to - Access-Control-Allow-Headers:Accept,Content-Type,X-Requested-With,x-api-key
did it (even if the header x-api-key is not processed on server B)