Problems Encountered in Development (Part One)

Problem 1: Correspondence between Interface and Code#

Since I just joined, I don't know where the code corresponding to each interface is located. Additionally, the project is quite old and large, so how can I quickly find the correspondence between interfaces and code? This is the first challenge.

Solution:

Initially, I went through all the app interfaces to get a general idea of what they are. Then, I started looking at the code naming and guessed which interface it might be based on the name, and then verified if it was correct. However, I soon found this method to be very tiring, and because the code is quite old, some classes have been rewritten and the old ones have not been deleted. The naming is also very similar, so there are some cases where it is impossible to correspond. Moreover, this method is very inefficient. If the project is not large, it's fine, but if the project is large and time is tight, this method simply won't work.
Then, when I was walking on the street after work, I suddenly remembered an article I had read before, Method Swizzling and AOP Practice, which introduced using Method Swizzling to implement statistics for each interface. Then I thought, since I can add statistics to each interface, I can definitely print the information of each interface as well. So, I used Method Swizzling to replace the ViewWillAppear: method, and every time a interface appears, the current class name will be printed. This way, I only need to run the app, click on the interface, and the current class will be printed. It's very easy to find the corresponding code for the interface.

Problem 2: No issues running on the simulator or directly on the device, but the packaged version displays incorrectly#

Developing a new version and packaging it for testing, but the testers said that the display is incorrect. I carefully checked and indeed, all the places where numbers are displayed are wrong, but when I run it on the simulator, everything is normal.

Troubleshooting:

Initially, I thought it might be due to the certificate, but it's unlikely. If it were a certificate issue, it would prevent packaging, not cause incorrect data in the package. Then I thought, could it be because I missed some settings during packaging? But I couldn't find any issues, and no one told me that any special settings were required.
So, I needed to locate the error. I ran it directly on the device, but there were no issues. What's going on?
Then, I sought help from others and thought, could it be because of the scheme? Because if there are any differences between packaging and direct running, it would be the scheme. So, I changed the scheme to release and ran it directly, and it threw an error... Helpless, I changed the scheme back to debug, packaged it (packaging is a painful process, the computer lags, the project is large, and compilation takes several minutes. I clicked archive, went to the bathroom, and when I came back, it still hadn't finished compiling...), installed it, and the display was still incorrect. I wanted to cry but had no tears...
Then the testers urged me, so I asked someone nearby to help me package it, and it turned out that the package they created had no issues... So I thought, maybe I did miss something during packaging, but I couldn't figure out what it was.
The next day, the testers urged me to package it again. I had no choice but to continue investigating. I discovered the enemy - iOS Development Pitfall 3 - Using ASI Framework Runs Normally in Xcode, But Cannot Access the Network When Packaging and Pitfalls of Packaging IPA with ASI. Then, I followed the instructions and made some changes, compiled and packaged it, and the moment of witnessing the miracle arrived. It worked, damn it, it was indeed this issue. The project is quite old, so ASI was used and never replaced. I hadn't used it before, but what's magical is that the iOS developer next to me had the compilation condition -fno-objc-arc, but the package he created had no issues. This is quite strange!

Problem 3: No issues running on the simulator, but issues arise when running on a real device#

Just fixed the previous problem, and in the evening, the testers reported a bug. When clicking on a link to open a web page, it fails to load, but it works on Android.

Troubleshooting:

When the testers first reported it, I checked and found that there were no issues on the simulator. The testers told me that there were no issues on Android either. So I thought, damn it, could it be a packaging issue again? But when I replaced the link with Baidu, there were no issues.
Following the usual routine, I ran it on a real device and debugged it step by step. The link was correct, but it still couldn't load. Could it be that the webView's implementation was incorrect (since I'm new, I'm using the existing class for loading web pages)? So I debugged step by step and found that every time it loaded, it appended "?source=app" to the link. Haha, I'm indeed clever. I commented it out, ran it, and... why is it still not working? Then the backend told me that this actually doesn't affect the link, so I obediently uncommented it.
So, what could it be? The backend suggested, "Can you try opening the link on other phones? Copy the link to a browser and see if it can be opened directly." So I tried it, damn it, indeed, it couldn't be opened in the browser. Then I tried it on other test devices and found that it worked. It worked! It worked! It turns out that the testers didn't check on other phones... (Ps: My phone hasn't been added to the test account yet, so I couldn't use it). But my phone is clearly connected to the internet, why doesn't it work? Why? Later, I thought, firstly: our company's network has restrictions; secondly: this link is originally a test link, so it's possible that the frontend didn't configure it properly.
But, it's not my fault. Why did it take me so long to fix it? Why? Oh right, why?