Problems Encountered During Development (Part One)

Problem 1: Correspondence between Interface and Code#

Since I just joined, I don't know which interface corresponds to which code. Moreover, 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 names and guessed which interface they might be related to, and then verified if it was correct. However, I soon realized that this method was 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 that cannot be matched at all. 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 when running on the simulator or directly on the device, but the packaged version displays incorrectly#

When developing a new version and packaging it for testing, the testers said that the display was incorrect. I carefully checked and indeed, all the places where numbers were displayed were wrong, but there were no issues when running on the simulator. All the data was normal.

Troubleshooting:

Initially, I thought it was because of the certificate, but it seemed unlikely. If it was a certificate issue, the consequence would be that I couldn't package it, not that the packaged data would be incorrect. Then I thought, could it be because I missed some settings when packaging? But I couldn't figure it out, and no one told me that there were any special settings 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 about it. Could it be because of the scheme? Because if there are any differences between packaging and running directly, it would be the scheme. So I changed the scheme to "release" and ran it directly, and it threw an error... Helplessly, I changed the scheme to "debug" and packaged it (packaging is a painful process, the computer lags, the project is large, and compilation takes a few minutes. I clicked "archive" and went to the bathroom, only to find that it still hadn't finished compiling when I came back...). I installed it, but 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 made had no issues... So I thought that I must have missed something when 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. The moment of witnessing the miracle arrived, it worked! Damn, it really was this problem. The project is quite old, so ASI was used and never replaced. I hadn't used it before, but what's strange is that the iOS developer next to me had the compilation condition "-fno-objc-arc", but the packaged version had no issues. This is really strange!

Problem 3: No issues when running on the simulator, but issues when running on the 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 failed to load, but it worked 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, 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 directly on the device and debugged step by step. The link was correct, but it still couldn't load. Could it be that the webView's interface was written incorrectly (I'm new, so I'm using the existing class for loading web pages)? I debugged step by step and found that every time it was loading, it appended "?source=app" to the link. Haha, I'm really smart. I commented it out, ran it, shit, why is it still not working? Then the backend told me that this wouldn't affect the link, so I obediently uncommented it.
So, what's the problem then? The backend said, "Try opening it on other phones. Copy this link to a browser and see if it can be opened directly." So I tried it, damn, it really 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 turned out that the testers didn't look at 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, first: our company's network has restrictions; second: this link was originally a test link, so it's possible that the frontend didn't configure it properly.
But, it's not my problem. Why did it take me so long to fix it? Why? Oh right, why?