December 29, 2017 at 18:22Publish an application to the AppStore. A play without dialogue in several acts
Actors: Contractor (we), Customer, AppReview specialists.
Actors: Contractor (we), Customer.
Within the framework of the project, we have developed a mobile application that works with the server software of the Customer (based on Microsoft OS), which is sold to the customers of the Customer.
Unlike many mobile applications, this application should not work with a single server accessible to all users of the application. The server acting as the backend of the application is installed on the territory and in the local network of each customer of the Customer, the server address is specified in the application settings.
Customer software is developed based on the .Net framework. Given the wishes of the Customer about the possibility of studying the mobile application code by its developers, the Xamarin framework was chosen for application development, namely Xamarin.Android and Xamarin.iOS.
The mobile application communicates with the server through the WCF framework, the endpoint on the server side is a constantly available service hosted in IIS. Application Layer Protocol - HTTPS.
Features of the implementation of WCF in the Xamarin framework and the necessary improvements remain beyond the scope of the described events.
Actors: Customer, AppReview specialists.
The customer decided to independently register Google and Apple Developer accounts, the publication of applications was also carried out by the Customer’s specialists.
It is expected that there were no difficulties publishing on Google Play.
Expectedly, passing AppReview dragged on. This process and the subsequent acts narrate about this process.
The first complaint of AppReview specialists was the lack of a demo server, with which Apple could test the application.
Request a demo account, in our case it will be more accurate to say - a demo server.
The customer purchased VDS on the site of one of the well-known hosters. For some reason, a foreign hoster was chosen, which in the context of our history is remarkable only because for its servers it provided not only an external IPv4 address, but also an IPv6 subnet with the / 64 prefix. Note that, unlike IPv4, IPv6 for this host requires a separate, although not complicated, configuration using the server OS. In this regard, the IPv4 address of the server was transferred to AppReview (along with the username and password for accessing the data of the server part of the application).
Actors: the same.
The application was sent for re-verification, AppReview specialists were provided with information about access to the demo server.
And again, the application did not pass the test. AppReview experts said that the application issued a message that it could not receive data from the server. The test was conducted from a network that uses only IPv6.
The result of the first test of the application with the demo server and the error generated by the application.
This answer was also expected, since from June 1, 2016 all applications sent to the AppStore should support operation on networks that use only IPv6 (without IPv4).
The customer configured the IPv6 address provided by the hoster on the demo server, and passed it to AppReview specialists.
And again refused to pass the audit, for the same reason. We begin to understand.
Actors: the same, the Contractor (we).
The customer is not able to verify IPv6 operation from their network. We have such an opportunity, the provider provides an IPv6 subnet with the / 64 prefix, from which we allocate IPv6 addresses to servers, workstations and other devices.
Testing the application on different iOS devices with different versions of iOS. All are connected to the WiFi network, get IPv4 and IPv6 address. We get completely correct work with the Customer’s demo server, both IPv4 and IPv6.
We inform AppReview specialists about this, their answer does not change. The following are several attempts to pass the test again after providing the AppReview experts with a video demonstrating the correct operation, several requests to check the availability of the server from their network (ping, telnet, ...), change the firewall settings, twist the IIS logs to the maximum (in the hope that they will help to identify cause of the problem). A question was also asked about switching to communication in Russian to discuss technical details, completely ignored.
The responses of the experts each time were identical to the previous one, and did not contain any technical details.
This is the answer we received several times in a row.
An Internet server located in our local network, used to develop a mobile application, was also put on the Internet. His address was handed over to AppReview specialists, the verification result has not changed. The application could not receive data from the server, in the IIS logs we did not even see attempted requests.
It should be noted that, unlike the Customer’s server, we created DNS records for our server. With different domain names for IPv4 (A record) and IPv6 (AAAA record) addresses, to continue to verify operation separately for IPv4 and IPv6.
DNS record for IPv4 address
DNS record for IPv6 address
Actors: the same.
It was decided to provide AppReview specialists with a report showing that the application fully and successfully passes all the steps in the Apple Mobile Application Testing Instructions . We expected that after that we would be provided with at least some technical details about the passage of the audit.
The application has been successfully tested for all but one of the items.
Of course, we stalled on checking the operation of the application in a purely IPv6 network (the “Test in IPv6-only networks” section of the above instructions). Because Since our local network uses both IPv4 and IPv6, the result of the verification in it cannot be used as verification in a purely IPv6 network.
System administrators were puzzled by the organization of a WiFi subnet using only IPv6. At the same time, they started checking through the scheme proposed by the instruction on supporting DNS64 / NAT64 networks . The essence of the scheme is to create on a computer with MacOS (in our case, Mac Mini) a purely IPv6 WiFi network that provides Internet access via a different network interface.
The proposed scheme from Apple. Our demo server is located before the router, in IPv4 + IPv6 LAN.
The application really could not get data from the server. When specifying the IPv4 address (and the corresponding domain name), an error was received about the unavailability of the network (it is logical, since the network is purely IPv6), when specifying the IPv6 address (and the corresponding domain name), the requests were timed out.
The study of network traffic between the device and the Mac Mini, and between the Mac Mini and the local network, showed that application requests for IPv6 address reach the Mac Mini, but do not go to the local network.
To check the operability of this system as a whole, they launched a browser, and on traffic they saw that
It became clear that for the application to work in this scheme, it is required that:
DNS record with IPv4 and IPv6 addresses
By creating A and AAAA records with one domain name and specifying it in the application, we managed to obtain data from the server.
We transferred the single domain name to AppReview specialists (without providing a new application assembly), within an hour the application passed the test and was published in the AppStore.
Happy end!
Act 1
Actors: Contractor (we), Customer.
Within the framework of the project, we have developed a mobile application that works with the server software of the Customer (based on Microsoft OS), which is sold to the customers of the Customer.
Unlike many mobile applications, this application should not work with a single server accessible to all users of the application. The server acting as the backend of the application is installed on the territory and in the local network of each customer of the Customer, the server address is specified in the application settings.
Customer software is developed based on the .Net framework. Given the wishes of the Customer about the possibility of studying the mobile application code by its developers, the Xamarin framework was chosen for application development, namely Xamarin.Android and Xamarin.iOS.
The mobile application communicates with the server through the WCF framework, the endpoint on the server side is a constantly available service hosted in IIS. Application Layer Protocol - HTTPS.
Features of the implementation of WCF in the Xamarin framework and the necessary improvements remain beyond the scope of the described events.
Act 2
Actors: Customer, AppReview specialists.
The customer decided to independently register Google and Apple Developer accounts, the publication of applications was also carried out by the Customer’s specialists.
It is expected that there were no difficulties publishing on Google Play.
Expectedly, passing AppReview dragged on. This process and the subsequent acts narrate about this process.
The first complaint of AppReview specialists was the lack of a demo server, with which Apple could test the application.
Request a demo account, in our case it will be more accurate to say - a demo server.
The customer purchased VDS on the site of one of the well-known hosters. For some reason, a foreign hoster was chosen, which in the context of our history is remarkable only because for its servers it provided not only an external IPv4 address, but also an IPv6 subnet with the / 64 prefix. Note that, unlike IPv4, IPv6 for this host requires a separate, although not complicated, configuration using the server OS. In this regard, the IPv4 address of the server was transferred to AppReview (along with the username and password for accessing the data of the server part of the application).
Act 3
Actors: the same.
The application was sent for re-verification, AppReview specialists were provided with information about access to the demo server.
And again, the application did not pass the test. AppReview experts said that the application issued a message that it could not receive data from the server. The test was conducted from a network that uses only IPv6.
The result of the first test of the application with the demo server and the error generated by the application.
This answer was also expected, since from June 1, 2016 all applications sent to the AppStore should support operation on networks that use only IPv6 (without IPv4).
The customer configured the IPv6 address provided by the hoster on the demo server, and passed it to AppReview specialists.
And again refused to pass the audit, for the same reason. We begin to understand.
Act 4
Actors: the same, the Contractor (we).
The customer is not able to verify IPv6 operation from their network. We have such an opportunity, the provider provides an IPv6 subnet with the / 64 prefix, from which we allocate IPv6 addresses to servers, workstations and other devices.
Testing the application on different iOS devices with different versions of iOS. All are connected to the WiFi network, get IPv4 and IPv6 address. We get completely correct work with the Customer’s demo server, both IPv4 and IPv6.
We inform AppReview specialists about this, their answer does not change. The following are several attempts to pass the test again after providing the AppReview experts with a video demonstrating the correct operation, several requests to check the availability of the server from their network (ping, telnet, ...), change the firewall settings, twist the IIS logs to the maximum (in the hope that they will help to identify cause of the problem). A question was also asked about switching to communication in Russian to discuss technical details, completely ignored.
The responses of the experts each time were identical to the previous one, and did not contain any technical details.
This is the answer we received several times in a row.
An Internet server located in our local network, used to develop a mobile application, was also put on the Internet. His address was handed over to AppReview specialists, the verification result has not changed. The application could not receive data from the server, in the IIS logs we did not even see attempted requests.
It should be noted that, unlike the Customer’s server, we created DNS records for our server. With different domain names for IPv4 (A record) and IPv6 (AAAA record) addresses, to continue to verify operation separately for IPv4 and IPv6.
Warning spoiler!
It was this decision that led to additional time costs, and to a more complete understanding of the application verification process in the bowels of Apple.
DNS record for IPv4 address
DNS record for IPv6 address
Act 5, denouement
Actors: the same.
It was decided to provide AppReview specialists with a report showing that the application fully and successfully passes all the steps in the Apple Mobile Application Testing Instructions . We expected that after that we would be provided with at least some technical details about the passage of the audit.
The application has been successfully tested for all but one of the items.
Of course, we stalled on checking the operation of the application in a purely IPv6 network (the “Test in IPv6-only networks” section of the above instructions). Because Since our local network uses both IPv4 and IPv6, the result of the verification in it cannot be used as verification in a purely IPv6 network.
System administrators were puzzled by the organization of a WiFi subnet using only IPv6. At the same time, they started checking through the scheme proposed by the instruction on supporting DNS64 / NAT64 networks . The essence of the scheme is to create on a computer with MacOS (in our case, Mac Mini) a purely IPv6 WiFi network that provides Internet access via a different network interface.
The proposed scheme from Apple. Our demo server is located before the router, in IPv4 + IPv6 LAN.
The application really could not get data from the server. When specifying the IPv4 address (and the corresponding domain name), an error was received about the unavailability of the network (it is logical, since the network is purely IPv6), when specifying the IPv6 address (and the corresponding domain name), the requests were timed out.
The study of network traffic between the device and the Mac Mini, and between the Mac Mini and the local network, showed that application requests for IPv6 address reach the Mac Mini, but do not go to the local network.
To check the operability of this system as a whole, they launched a browser, and on traffic they saw that
- requests from the device to the Mac Mini go through IPv6, which is logical;
- requests from the Mac Mini go over IPv4 regardless of whether IPv6 is available on the Mac Mini itself.
It became clear that for the application to work in this scheme, it is required that:
- The server was set through the domain name;
- the device correctly determined the IPv6 address by this domain name;
- Mac Mini correctly detected IPv4 address by this domain name;
- the server was available simultaneously at these IPv4 and IPv6 addresses.
DNS record with IPv4 and IPv6 addresses
By creating A and AAAA records with one domain name and specifying it in the application, we managed to obtain data from the server.
We transferred the single domain name to AppReview specialists (without providing a new application assembly), within an hour the application passed the test and was published in the AppStore.
Happy end!