November 28, 2011 at 22:25And a little more about Test Flight iOS application testing service
Thanks to Shmatlay for today's review of Test Flight .
Since we also use it in our company and are quite active, I can’t help but insert our own five kopecks about the specified service, based on the experience of its operation.
If someone missed this post, I’ll briefly explain that Test Flight is a service that simplifies testing applications for iOS devices by facilitating the process of collecting test device codes (UDIDs), as well as by easier distribution of builds signed for testers of your application . Well, plus, you can see how many times the application was launched, how many times it crashed, as well as receive some debugging information.
1. First of all, for most of the goodies described above to work, you need to install the TestFlight SDK, which is a library for introducing advanced logging and other good features into your application. The installation process is completely uncomplicated and is described in detail here .
2. To distribute your applications between users, you will need to get an ad-hoc distribution profile, or if the application is being developed using corporate accounts, the corresponding [enterprise] distribution profile (I don’t remember what it is called). Consequently, UDIDs of devices will have to be picked up from letters of potential beta testers, go to developer.apple.com, and register them to sign an ad-hoc application. Here, unfortunately, it was not possible to get anywhere from this.
3. As practice has shown, applications in which the TestFlight SDK has not been implemented, but which have been signed by the UDIDs of the testers are perfectly distributed through the service to the testers with the mentioned UDIDs, so if for any reason you do not want your the application was someone else’s code (hello, TestFlight SDK!), then you can’t completely implement this SDK - testers can still use your applications by downloading through the service.
4. I draw particular attention to the fact that through ad-hoc distribution of applications and testing ad-hoc assemblies, you can use no more than 100 UDIDs per year for applications signed by an individual developer account. This reminder will be useful for those who plan to release more than 3-4 applications per [paid for $ 100] year and widely test them among the masses. The Apple limit of 100 devices when using the service does not go anywhere! (Although, I believe that this is understandable to everyone, but you never know)
5. The developers of the service have good (though not the most relevant) guides to build signed builds. For Xcode 3 manual here , for Xcode 4 - here. To successfully create an archive with a build, it is enough to strictly follow these instructions. I draw the attention of Xcode 4 users that for their version of the instruction, item 2 in the latest Xcode assemblies has lost relevance, now there is no mention of the Code Signing subgroup when creating a new file. Instead, you need to create an ordinary .plist file with a name, for example, Entitlements.plist and write it in the correct line according to the instructions of the guys from TestFlight. More than once or twice I came across a situation where, as a result of some incorrect manipulations with the Entitlements.plist file, as a result of creating the application archive, a warning popped up that there was an error signing the application and the application was not signed. In this case, I highly recommend checking once again if you have done everything according to the instructions presented above, and if everything is done correctly, but still the warning comes out, try removing Entitlements.plist and redo it. I pay special attention to this because if you distribute a build of applications received with a warning about an incorrect or missing signature, then your testers simply will not be able to install this application. A sure sign of such a problem is the complaints of testers of the form "I start downloading the application, then it suddenly says that the installation cannot be completed and the installation stops." In this case, either the application was not signed for this tester (or rather, its UDID of the device), or the described error occurred with the application signing at the stage of creating its build from the archive. I pay special attention to this because if you distribute a build of applications received with a warning about an incorrect or missing signature, then your testers simply will not be able to install this application. A sure sign of such a problem is the complaints of testers of the form "I start downloading the application, then it suddenly says that the installation cannot be completed and the installation stops." In this case, either the application was not signed for this tester (or rather, its UDID of the device), or the described error occurred with the application signing at the stage of creating its build from the archive. I pay special attention to this because if you distribute a build of applications received with a warning about an incorrect or missing signature, then your testers simply will not be able to install this application. A sure sign of such a problem is the complaints of testers of the form "I start downloading the application, then it suddenly says that the installation cannot be completed and the installation stops." In this case, either the application was not signed for this tester (or rather, its UDID of the device), or the described error occurred with the application signing at the stage of creating its build from the archive. A sure sign of such a problem is the complaints of testers of the form "I start downloading the application, then it suddenly says that the installation cannot be completed and the installation stops." In this case, either the application was not signed for this tester (or rather, its UDID of the device), or the described error occurred with the application signing at the stage of creating its build from the archive. A sure sign of such a problem is the complaints of testers of the form "I start downloading the application, then it suddenly says that the installation cannot be completed and the installation stops." In this case, either the application was not signed for this tester (or rather, its UDID of the device), or the described error occurred with the application signing at the stage of creating its build from the archive.
6. The implementation of the SDK increases the size of the application build by about 300 Kb. If suddenly, for some inconceivable reason, the size of the application is so critical for you - keep this in mind (the author of these lines somehow managed to double the size of the distribution of the build of his application by just implementing the TestFlight SDK).
7. In some cases (the author of these lines could not understand which ones) the service replaces your application icon with its own icon. However, I am inclined to believe that, in my case, my crooked hands are most likely to blame for this.
8. Some users have more than one iOS device, and only one of them is registered in the service after receiving an invite letter for testing, and then they wonder why the application does not start on other (other) iOS devices. In this case (again, a completely obvious situation, but practice shows that there are people who do not fully understand this), the user needs to explain that he will have to go to the Test Flight website (or open an invite letter) on every device he wants mark as test.
9. In general, the service leaves a very good impression after use, allowing you to quickly collect UDIDs and send application builds. These two main things are also bolted on the management of project lists (aka tester teams / something else), the ability to see which of the testers received an email with an invite, who read it, who installed the application and stuff like that. Speaking of who installed the application. Installing an application is considered the moment the application starts downloading from the TestFlight server. If after this the installation of the application freezes, it crashes, or something else is going out of the ordinary (like an alien invasion from Proxima Centauri), you will have the complete impression in the admin panel that the user installed the application normally. Just as today was the case when the application didn’t want to be installed on one iPhone (it didn’t even load), and it got up perfectly on the other. However, I, too, am inclined to blame it on my own crooked hands.
10. In addition to iOS, other platforms are not yet supported.
11. The service is free and promises that the basic functionality available today will always be free.
Well, thank you for your attention, if you have any questions about working with Test Flight, you can safely ask them in the comments, I will try (try) to answer them.
Since we also use it in our company and are quite active, I can’t help but insert our own five kopecks about the specified service, based on the experience of its operation.
If someone missed this post, I’ll briefly explain that Test Flight is a service that simplifies testing applications for iOS devices by facilitating the process of collecting test device codes (UDIDs), as well as by easier distribution of builds signed for testers of your application . Well, plus, you can see how many times the application was launched, how many times it crashed, as well as receive some debugging information.
1. First of all, for most of the goodies described above to work, you need to install the TestFlight SDK, which is a library for introducing advanced logging and other good features into your application. The installation process is completely uncomplicated and is described in detail here .
2. To distribute your applications between users, you will need to get an ad-hoc distribution profile, or if the application is being developed using corporate accounts, the corresponding [enterprise] distribution profile (I don’t remember what it is called). Consequently, UDIDs of devices will have to be picked up from letters of potential beta testers, go to developer.apple.com, and register them to sign an ad-hoc application. Here, unfortunately, it was not possible to get anywhere from this.
3. As practice has shown, applications in which the TestFlight SDK has not been implemented, but which have been signed by the UDIDs of the testers are perfectly distributed through the service to the testers with the mentioned UDIDs, so if for any reason you do not want your the application was someone else’s code (hello, TestFlight SDK!), then you can’t completely implement this SDK - testers can still use your applications by downloading through the service.
4. I draw particular attention to the fact that through ad-hoc distribution of applications and testing ad-hoc assemblies, you can use no more than 100 UDIDs per year for applications signed by an individual developer account. This reminder will be useful for those who plan to release more than 3-4 applications per [paid for $ 100] year and widely test them among the masses. The Apple limit of 100 devices when using the service does not go anywhere! (Although, I believe that this is understandable to everyone, but you never know)
5. The developers of the service have good (though not the most relevant) guides to build signed builds. For Xcode 3 manual here , for Xcode 4 - here. To successfully create an archive with a build, it is enough to strictly follow these instructions. I draw the attention of Xcode 4 users that for their version of the instruction, item 2 in the latest Xcode assemblies has lost relevance, now there is no mention of the Code Signing subgroup when creating a new file. Instead, you need to create an ordinary .plist file with a name, for example, Entitlements.plist and write it in the correct line according to the instructions of the guys from TestFlight. More than once or twice I came across a situation where, as a result of some incorrect manipulations with the Entitlements.plist file, as a result of creating the application archive, a warning popped up that there was an error signing the application and the application was not signed. In this case, I highly recommend checking once again if you have done everything according to the instructions presented above, and if everything is done correctly, but still the warning comes out, try removing Entitlements.plist and redo it. I pay special attention to this because if you distribute a build of applications received with a warning about an incorrect or missing signature, then your testers simply will not be able to install this application. A sure sign of such a problem is the complaints of testers of the form "I start downloading the application, then it suddenly says that the installation cannot be completed and the installation stops." In this case, either the application was not signed for this tester (or rather, its UDID of the device), or the described error occurred with the application signing at the stage of creating its build from the archive. I pay special attention to this because if you distribute a build of applications received with a warning about an incorrect or missing signature, then your testers simply will not be able to install this application. A sure sign of such a problem is the complaints of testers of the form "I start downloading the application, then it suddenly says that the installation cannot be completed and the installation stops." In this case, either the application was not signed for this tester (or rather, its UDID of the device), or the described error occurred with the application signing at the stage of creating its build from the archive. I pay special attention to this because if you distribute a build of applications received with a warning about an incorrect or missing signature, then your testers simply will not be able to install this application. A sure sign of such a problem is the complaints of testers of the form "I start downloading the application, then it suddenly says that the installation cannot be completed and the installation stops." In this case, either the application was not signed for this tester (or rather, its UDID of the device), or the described error occurred with the application signing at the stage of creating its build from the archive. A sure sign of such a problem is the complaints of testers of the form "I start downloading the application, then it suddenly says that the installation cannot be completed and the installation stops." In this case, either the application was not signed for this tester (or rather, its UDID of the device), or the described error occurred with the application signing at the stage of creating its build from the archive. A sure sign of such a problem is the complaints of testers of the form "I start downloading the application, then it suddenly says that the installation cannot be completed and the installation stops." In this case, either the application was not signed for this tester (or rather, its UDID of the device), or the described error occurred with the application signing at the stage of creating its build from the archive.
6. The implementation of the SDK increases the size of the application build by about 300 Kb. If suddenly, for some inconceivable reason, the size of the application is so critical for you - keep this in mind (the author of these lines somehow managed to double the size of the distribution of the build of his application by just implementing the TestFlight SDK).
7. In some cases (the author of these lines could not understand which ones) the service replaces your application icon with its own icon. However, I am inclined to believe that, in my case, my crooked hands are most likely to blame for this.
8. Some users have more than one iOS device, and only one of them is registered in the service after receiving an invite letter for testing, and then they wonder why the application does not start on other (other) iOS devices. In this case (again, a completely obvious situation, but practice shows that there are people who do not fully understand this), the user needs to explain that he will have to go to the Test Flight website (or open an invite letter) on every device he wants mark as test.
9. In general, the service leaves a very good impression after use, allowing you to quickly collect UDIDs and send application builds. These two main things are also bolted on the management of project lists (aka tester teams / something else), the ability to see which of the testers received an email with an invite, who read it, who installed the application and stuff like that. Speaking of who installed the application. Installing an application is considered the moment the application starts downloading from the TestFlight server. If after this the installation of the application freezes, it crashes, or something else is going out of the ordinary (like an alien invasion from Proxima Centauri), you will have the complete impression in the admin panel that the user installed the application normally. Just as today was the case when the application didn’t want to be installed on one iPhone (it didn’t even load), and it got up perfectly on the other. However, I, too, am inclined to blame it on my own crooked hands.
10. In addition to iOS, other platforms are not yet supported.
11. The service is free and promises that the basic functionality available today will always be free.
Well, thank you for your attention, if you have any questions about working with Test Flight, you can safely ask them in the comments, I will try (try) to answer them.