And a little more about testing service for iOS applications Test Flight
Thank you Shmatlay for today's review of the Test Flight service .
Since in our company we also use it quite actively, I cannot fail to insert my five kopecks about this service, based on the experience of its operation.
If someone missed the specified 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 your application’s signed testers . Well, plus, you can see how many times the application has been launched, how many times it has fallen, and also receive some debug information.
1. First of all, for most of the above described buns to work, you need to install the TestFlight SDK, which is a library for introducing advanced logging and other good into your application. The installation process is not complicated at all and is described in detail here .
2. To distribute your applications among users, you will need to get an ad-hoc distribution profile, or if you develop an application using a corporate account corresponding to its [enterprise] distribution profile (I don’t remember how it is called exactly). Consequently, the UDIDs of the devices will have to be taken from the letters of potential beta testers, sent to developer.apple.com, and registered for signing the ad-hoc application. Here, unfortunately, it was not possible to get away from this.
3. As practice has shown, applications in which the TestFlight SDK was not implemented, but which were signed by the UDID, the testers are perfectly sent through the service to testers with the mentioned UDIDs, so if for some reason you do not want your the application was someone else's code (hello, TestFlight SDK!), then you may not implement this very SDK - testers can still use your applications by downloading through the service.
')
4. I pay special attention to the fact that through ad-hoc application distribution 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 for [paid for $ 100] a year and widely test them among the masses. Epplovskoe limit of 100 devices when using the service does not go anywhere! (Although, I believe that this is already clear to everyone, but you never know)
5. To build signed builds, service developers have good (although not the most current) guides. For Xcode 3, the manual is here , for Xcode 4 - here . To successfully create an archive with build, it is enough to strictly follow these instructions. I draw the attention of users of Xcode 4, that for their version of the instructions item 2 in the latest builds of Xcode has lost relevance, no Code Signing subgroup is present when creating a new file. Instead, you need to create an ordinary .plist-file with a name, for example, Entitlements.plist and register it in the correct line according to the instructions of the guys from TestFlight. Not 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 an application signing error occurred and the application was not signed. In this case, I strongly recommend checking again whether you did everything according to the instructions above, and if everything was done correctly, but the warning still crawls out, try to remove the Entitlements.plist and redo it. I pay special attention to this because if you distribute a build of an application received with a warning about a wrong or missing signature, your testers simply will not be able to install this application. A sure sign of such a problem are complaints from testers like “I start downloading an 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 device), or the described error occurred with the application signature at the stage of creating its build from the archive.
6. The implementation of the SDK increases the size of the application build by approximately 300 Kb. If, for whatever inconceivable reason, the size of the application is so critical for you - keep this in mind (the author of these lines once made the application’s distribution kit double its size by just implementing TestFlight SDK).
7. In some cases (the author of these lines could not figure out exactly which) 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.
8. Some users have more than one iOS device, while registering only one of them after receiving a letter with an invite to testing, and then wondering why the application does not start on the other (other) iOS devices. In this case (again, an obvious position, 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 email with an invite) on each device he wants Mark as test.
9. In general, the service leaves a very pleasant impression after use, allowing you to quickly collect UDIDs and send application builds. These two main things are also attached to the management of project lists (aka teams of testers / anything else), the ability to see which testers received an email with an invite, who read it, who installed the application and stuff like that. By the way about who installed the application. Installing an application is considered to be the moment the application starts downloading from the TestFlight server. If after that the installation of the application hangs, crashes, or something out of the ordinary happens (such as the invasion of aliens from Proxima Centauri), you will have the full impression in the admin area that the user has installed the application properly. As recently as today there was a case when one didn’t want to be placed on one iPhone (it didn’t even load), and on the other it got up perfectly. However, I am also inclined to write off 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, we will try (we will try) to answer them.
Since in our company we also use it quite actively, I cannot fail to insert my five kopecks about this service, based on the experience of its operation.
If someone missed the specified 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 your application’s signed testers . Well, plus, you can see how many times the application has been launched, how many times it has fallen, and also receive some debug information.
1. First of all, for most of the above described buns to work, you need to install the TestFlight SDK, which is a library for introducing advanced logging and other good into your application. The installation process is not complicated at all and is described in detail here .
2. To distribute your applications among users, you will need to get an ad-hoc distribution profile, or if you develop an application using a corporate account corresponding to its [enterprise] distribution profile (I don’t remember how it is called exactly). Consequently, the UDIDs of the devices will have to be taken from the letters of potential beta testers, sent to developer.apple.com, and registered for signing the ad-hoc application. Here, unfortunately, it was not possible to get away from this.
3. As practice has shown, applications in which the TestFlight SDK was not implemented, but which were signed by the UDID, the testers are perfectly sent through the service to testers with the mentioned UDIDs, so if for some reason you do not want your the application was someone else's code (hello, TestFlight SDK!), then you may not implement this very SDK - testers can still use your applications by downloading through the service.
')
4. I pay special attention to the fact that through ad-hoc application distribution 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 for [paid for $ 100] a year and widely test them among the masses. Epplovskoe limit of 100 devices when using the service does not go anywhere! (Although, I believe that this is already clear to everyone, but you never know)
5. To build signed builds, service developers have good (although not the most current) guides. For Xcode 3, the manual is here , for Xcode 4 - here . To successfully create an archive with build, it is enough to strictly follow these instructions. I draw the attention of users of Xcode 4, that for their version of the instructions item 2 in the latest builds of Xcode has lost relevance, no Code Signing subgroup is present when creating a new file. Instead, you need to create an ordinary .plist-file with a name, for example, Entitlements.plist and register it in the correct line according to the instructions of the guys from TestFlight. Not 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 an application signing error occurred and the application was not signed. In this case, I strongly recommend checking again whether you did everything according to the instructions above, and if everything was done correctly, but the warning still crawls out, try to remove the Entitlements.plist and redo it. I pay special attention to this because if you distribute a build of an application received with a warning about a wrong or missing signature, your testers simply will not be able to install this application. A sure sign of such a problem are complaints from testers like “I start downloading an 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 device), or the described error occurred with the application signature at the stage of creating its build from the archive.
6. The implementation of the SDK increases the size of the application build by approximately 300 Kb. If, for whatever inconceivable reason, the size of the application is so critical for you - keep this in mind (the author of these lines once made the application’s distribution kit double its size by just implementing TestFlight SDK).
7. In some cases (the author of these lines could not figure out exactly which) 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.
8. Some users have more than one iOS device, while registering only one of them after receiving a letter with an invite to testing, and then wondering why the application does not start on the other (other) iOS devices. In this case (again, an obvious position, 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 email with an invite) on each device he wants Mark as test.
9. In general, the service leaves a very pleasant impression after use, allowing you to quickly collect UDIDs and send application builds. These two main things are also attached to the management of project lists (aka teams of testers / anything else), the ability to see which testers received an email with an invite, who read it, who installed the application and stuff like that. By the way about who installed the application. Installing an application is considered to be the moment the application starts downloading from the TestFlight server. If after that the installation of the application hangs, crashes, or something out of the ordinary happens (such as the invasion of aliens from Proxima Centauri), you will have the full impression in the admin area that the user has installed the application properly. As recently as today there was a case when one didn’t want to be placed on one iPhone (it didn’t even load), and on the other it got up perfectly. However, I am also inclined to write off 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, we will try (we will try) to answer them.
Source: https://habr.com/ru/post/133559/
All Articles