To have a timing system that you can trust is of course essential. No one wants to tell competitors and others interested that the timing has failed and that there are no times to present. I have therefore always tested SprintTimer a lot, but now I have also done a more formal long-range test. SprintTimer has been running for several hours on different devices with different system versions (more details below). The result from more than 1000 Photo Finishes and more than 70 000 recorded Video Finish frames were that not a single failure occurred.
This shows that the basic implementation of SprintTimer is sound and stable. However, and this is important, this doesn’t mean that a perfect behavior can be guaranteed on any device under any circumstance. A smartphone is a very complex environment with a lot going on at the same time. I am tracking the problems that occur and can see that there are a small number of recordings that fail for different unknown reasons.
For several reasons (security, performance, battery, etc) does Apple only allow the developer very limited control over the whole system. It is therefore up to every serious timekeeper to check his device, especially after upgrading the system or installing new apps.
If there are problems there are a few things you can try:
- Restart the device. This easiest done by choosing General > Shut down in the Settings app.
- Remove SprintTimer and install it from the app store again.
- Restore your device.
Note that you can reinstall SprintTimer from the App Store without paying again. But also note that removing the app removes saved bases videos and results, so they should be exported first. Restoring the whole device might involve substantial work and should only be a last resort.
The tests
There were two series of tests, one running Photo finish, the other Video finish. The iPhones and iPads used were not prepared in any way and SprintTimer was the standard version with only a few lines of code added to run the test. As already mentioned did all test run as expected without any problems.
Photo Finish
The clock was started, and the timing was allowed to run its course until the
| Device/iOS | Length (s) | Repeats | Time (h:min) |
| iPhone 5s, 11.4 | 5 | 350 | 1:10 |
| iPhone 6, 11.4 | 10 | 100 | 1:00 |
| iPhone 6s, 12.3 | 10 | 200 | 1:20 |
| iPhone 7+, 12.2 | 300 | 10 | 1:10 | iPhone X, 12.3 | 30 | 100 | 1:20 |
| iPad Air, 10.3 | 100 | 50 | 1:40 |
| iPad Pro, 12.3 | 20 | 100 | 1:00 |
Video Finish
In this case, the timing wasn’t repeated, but instead, the recording was allowed to run for an extended period (up to more than 3 hours). The activity in front of the camera was of two types: In one case did an object appear every two seconds, which lead to many recorded frames. In the other case was the motion much more random with long periods of inactivity.
| Device/iOS | Length (h:min) | Frames |
| iPhone 5s, 11.4 | 1:00 | 14 300 |
| iPhone 6s, 12.3 | 3:00 | 1 400 |
| iPhone 7+, 12.2 | 2:00 | 1 700 |
| iPhone X, 12.3 | 2:00 | 19 600 |
| iPad Pro, 12.3 | 3:30 | 29 400 |