Background#
This morning, a user suddenly reported that the recording feature crashed. Initially, I thought there might be an issue with the recently updated app version, so I quickly began investigating.
Investigation#
First, I tested on a mobile phone in the testing environment and found no crashes. I breathed a sigh of relief, indicating that not all users were affected and it wasn't an issue introduced by the new version.
Then I checked the logs in the backend and found that the crash occurred during the initialization of AVAudioRecorder—[[AVAudioRecorder alloc] initWithURL:url settings:recordSettings error:&error];. It was puzzling; it was just a simple initialization method, so why would it cause a crash?
Initially, I speculated that it might be due to the user not having recording permissions enabled, which could lead to a crash when starting the recording. After testing, I found that if permissions were disabled, a prompt would appear before entering the recording page, indicating that permissions were not enabled, and the user could not proceed to the recording step.
Then I wondered if the initialized URL was nil, or if the device model did not support certain parameters in recordSettings? After searching, I found entries indicating crashes due to a nil URL, so it was likely that the initialized URL was indeed nil.
Continuing the investigation, I discovered that the initialized URL was in the local cache folder's Audio directory, and the file name was generated using the date and time to avoid duplication, formatted as yyyyMMdd_HHmmss. Logically, this should not result in a nil issue, so where exactly was the problem? I communicated with the user, who reported that the issue occurred today, and everything was fine before; they had recently upgraded to iOS 15.6.1. However, the testing device was also running iOS 15.6.1 and did not experience any crashes, indicating that it was not related to the system version.
Further investigation revealed that the crash log in the backend showed a timestamp that did not match the time the user reported during the screen recording? Could the system time have been modified? But would changing the system time cause the initialization of AVAudioRecorder to crash? I didn't hold out much hope, but after testing, I found that, surprisingly, changing the time did indeed cause the recording initialization to crash... Amazing, haha, this isn't my fault; I quickly went back to find the user.
When I communicated with the user again, they reported that they hadn't changed the time, only the date display from 24-hour format to 12-hour format. What... Could it be... I quickly went to verify, and indeed, setting the 12-hour format caused the crash... Why? The date format yyyyMMdd_HHmmss can accommodate 12-hour time, but the returned string was 20220829_上午104030, which included Chinese characters. Using this string to generate NSURL resulted in nil, and then initializing AVAudioRecorder with nil led to the crash... 😭 It's still my fault; no more talking, I need to fix this quickly.