Publish the application in the AppStore. A play without dialogue in several acts
Actors: Artist (we), Customer, AppReview specialists.
Actors: Contractor (we), Customer.
As part of the project, we developed a mobile application that works with the Customer’s server software (based on Microsoft’s OS) sold to the Customer’s customers.
')
Unlike many mobile applications, this application should not work with a single server accessible to all users of the application. The server acting as a backend of the application is installed on the territory and in the local network of each client of the Customer, the server address is specified in the application settings.
Customer software is developed on the basis of the .Net framework. Taking into account the wishes of the Customer about the possibility of studying the mobile application code by its developers, the Xamarin framework, namely Xamarin.Android and Xamarin.iOS, was chosen to develop the application.
The mobile application communicates with the server via the WCF framework, the end point on the server side is a permanently available service hosted in IIS. Application Layer Protocol - HTTPS.
The specifics of implementing WCF in the Xamarin framework and the improvements needed are beyond the scope of the events described.
Characters: Customer, AppReview Specialists.
The customer made a decision to self-register Google and Apple Developer accounts, the publication of applications was also carried out by the Customer’s specialists.
As expected, there were no difficulties with publishing on Google Play.
As expected, the passage of AppReview was delayed. This process and subsequent acts narrates about this process.
The first complaint of AppReview experts was the lack of a demo server, in 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 bought VDS at the site of one of the famous hosters. For some reason, a foreign hoster was chosen, which in the context of our history is remarkable only by the fact that for its servers it provided not only an external IPv4 address, but also an IPv6 subnet with the / 64 prefix. Note that, unlike IPv4, this IPv6 hoster requires a separate, albeit not complex, configuration by means of the server OS. In this regard, the server's IPv4 address was sent to AppReview (along with the login and password for accessing the server-side data of the application).
Characters: the same.
The application was sent for re-verification, the AppReview specialists were provided with information on access to the demo server.
Again, the application failed validation. AppReview experts reported 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 response was also expected, since from June 1, 2016, all applications sent to the AppStore should support work in networks that use only IPv6 (without IPv4).
The customer set up the IPv6 address provided by the hoster on the demo server, passed it to the AppReview specialists.
And again denied verification, for the same reason. We start to understand.
Actors: the same, the Contractor (we).
The customer is not able to test work with IPv6 from its network. We have this opportunity, the provider provides a subnet with the / 64 prefix on IPv6, from which we allocate IPv6 addresses to servers, workstations and other devices.
We test the application on different iOS devices with different versions of iOS. All are connected to a WiFi network, get an IPv4 and IPv6 address. We get fully correct work with the Customer’s demo server, which is IPv4, and IPv6.
We inform AppReview specialists about this, their answer does not change. Then there are several attempts to get tested again after providing AppReview specialists with a video demonstrating the correct operation, several requests to check the availability of the server from their network (ping, telnet, ...), changes to the firewall settings, unscrewing the IIS logs to the maximum (in the hope that they will help identify cause of the problem). Also asked about the transition to communication in Russian to discuss technical details, completely ignored.
The answers of the specialists 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.
There was also an Internet server located on our local network, used for developing a mobile application. Its address was given to AppReview specialists, the result of the check has not changed. The application could not retrieve data from the server, in the IIS logs we did not even see the request attempts.
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 check the work separately on IPv4 and IPv6.
DNS record for IPv4 address
DNS record for IPv6 address
Characters: the same.
It was decided to provide AppReview specialists with a report showing that the application completely and successfully passes all points of Apple’s mobile application testing instruction . We expected that after this we would be provided with at least some technical details about passing the test.
The application has been successfully tested on all items except one.
Needless to say, we stalled on checking the operation of the application in a pure IPv6 network (section “Test in IPv6-only networks” from the above instructions). Since Since our local network uses both IPv4 and IPv6, the test result in it cannot be used as a test in a pure IPv6 network.
System administrators were puzzled by the organization of a WiFi subnet using only IPv6. In parallel with this, we launched a check through the scheme offered by the instruction on supporting DNS64 / NAT64 networks . The essence of the scheme is to create a pure IPv6 WiFi network on a MacOS computer (in our case, the Mac Mini), which provides general access to the Internet through another network interface.
The proposed scheme from Apple. Our demo server is located before the router, in the IPv4 + IPv6 local network.
The application really could not get data from the server. When specifying an IPv4 address (and the corresponding domain name), an error was reported that the network was unavailable (logical, because the network is purely IPv6), and if the IPv6 address (and corresponding domain name) was specified, the requests were timed out.
A 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 an IPv6 address reach the Mac Mini, but do not go to the local network.
To check the performance of this system as a whole, they launched a browser, and by 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 obtained data from the server.
We transferred a single domain name to AppReview specialists (without providing a new application build), within an hour the application passed the test and was published in the AppStore.
Happy End!
Act 1
Actors: Contractor (we), Customer.
As part of the project, we developed a mobile application that works with the Customer’s server software (based on Microsoft’s OS) sold to the Customer’s customers.
')
Unlike many mobile applications, this application should not work with a single server accessible to all users of the application. The server acting as a backend of the application is installed on the territory and in the local network of each client of the Customer, the server address is specified in the application settings.
Customer software is developed on the basis of the .Net framework. Taking into account the wishes of the Customer about the possibility of studying the mobile application code by its developers, the Xamarin framework, namely Xamarin.Android and Xamarin.iOS, was chosen to develop the application.
The mobile application communicates with the server via the WCF framework, the end point on the server side is a permanently available service hosted in IIS. Application Layer Protocol - HTTPS.
The specifics of implementing WCF in the Xamarin framework and the improvements needed are beyond the scope of the events described.
Act 2
Characters: Customer, AppReview Specialists.
The customer made a decision to self-register Google and Apple Developer accounts, the publication of applications was also carried out by the Customer’s specialists.
As expected, there were no difficulties with publishing on Google Play.
As expected, the passage of AppReview was delayed. This process and subsequent acts narrates about this process.
The first complaint of AppReview experts was the lack of a demo server, in 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 bought VDS at the site of one of the famous hosters. For some reason, a foreign hoster was chosen, which in the context of our history is remarkable only by the fact that for its servers it provided not only an external IPv4 address, but also an IPv6 subnet with the / 64 prefix. Note that, unlike IPv4, this IPv6 hoster requires a separate, albeit not complex, configuration by means of the server OS. In this regard, the server's IPv4 address was sent to AppReview (along with the login and password for accessing the server-side data of the application).
Act 3
Characters: the same.
The application was sent for re-verification, the AppReview specialists were provided with information on access to the demo server.
Again, the application failed validation. AppReview experts reported 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 response was also expected, since from June 1, 2016, all applications sent to the AppStore should support work in networks that use only IPv6 (without IPv4).
The customer set up the IPv6 address provided by the hoster on the demo server, passed it to the AppReview specialists.
And again denied verification, for the same reason. We start to understand.
Act 4
Actors: the same, the Contractor (we).
The customer is not able to test work with IPv6 from its network. We have this opportunity, the provider provides a subnet with the / 64 prefix on IPv6, from which we allocate IPv6 addresses to servers, workstations and other devices.
We test the application on different iOS devices with different versions of iOS. All are connected to a WiFi network, get an IPv4 and IPv6 address. We get fully correct work with the Customer’s demo server, which is IPv4, and IPv6.
We inform AppReview specialists about this, their answer does not change. Then there are several attempts to get tested again after providing AppReview specialists with a video demonstrating the correct operation, several requests to check the availability of the server from their network (ping, telnet, ...), changes to the firewall settings, unscrewing the IIS logs to the maximum (in the hope that they will help identify cause of the problem). Also asked about the transition to communication in Russian to discuss technical details, completely ignored.
The answers of the specialists 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.
There was also an Internet server located on our local network, used for developing a mobile application. Its address was given to AppReview specialists, the result of the check has not changed. The application could not retrieve data from the server, in the IIS logs we did not even see the request attempts.
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 check the work separately on IPv4 and IPv6.
Attention, spoiler!
This decision led to additional time costs, and to a more complete understanding of the process of checking the application in the depths of Apple.
DNS record for IPv4 address
DNS record for IPv6 address
Act 5, interchange
Characters: the same.
It was decided to provide AppReview specialists with a report showing that the application completely and successfully passes all points of Apple’s mobile application testing instruction . We expected that after this we would be provided with at least some technical details about passing the test.
The application has been successfully tested on all items except one.
Needless to say, we stalled on checking the operation of the application in a pure IPv6 network (section “Test in IPv6-only networks” from the above instructions). Since Since our local network uses both IPv4 and IPv6, the test result in it cannot be used as a test in a pure IPv6 network.
System administrators were puzzled by the organization of a WiFi subnet using only IPv6. In parallel with this, we launched a check through the scheme offered by the instruction on supporting DNS64 / NAT64 networks . The essence of the scheme is to create a pure IPv6 WiFi network on a MacOS computer (in our case, the Mac Mini), which provides general access to the Internet through another network interface.
The proposed scheme from Apple. Our demo server is located before the router, in the IPv4 + IPv6 local network.
The application really could not get data from the server. When specifying an IPv4 address (and the corresponding domain name), an error was reported that the network was unavailable (logical, because the network is purely IPv6), and if the IPv6 address (and corresponding domain name) was specified, the requests were timed out.
A 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 an IPv6 address reach the Mac Mini, but do not go to the local network.
To check the performance of this system as a whole, they launched a browser, and by traffic they saw that
- requests from the device to the Mac Mini go over IPv6, which is logical;
- requests from the Mac Mini go over IPv4 regardless of whether there is IPv6 on the Mac Mini itself.
It became clear that for the application to work in this scheme it is required that:
- The server was specified through a domain name;
- the device correctly determined the IPv6 address for this domain name;
- The Mac Mini correctly identified the IPv4 address for this domain name;
- The server was accessible simultaneously to 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 obtained data from the server.
We transferred a single domain name to AppReview specialists (without providing a new application build), within an hour the application passed the test and was published in the AppStore.
Happy End!
Source: https://habr.com/ru/post/345874/
All Articles