As mentioned earlier, we can inject macros into Pods from the outside by modifying the Podfile. You can refer to this article Inject TEST macros into Pods.

Sometimes there are some macros that are expected to be used inside the Pods library we wrote ourselves.

A common practice, just like ordinary business code, define a macro definition header file, and then import.

But sometimes there are such scenarios, such as logging or providing some externally exposed APIs, you need to provide the version of the current library.

When we develop iOS applications, we often use CocoaPods for third-party library management.

In addition to external third-party libraries, it is common for CocoaPods to be used as a library management tool for individuals or companies.

We usually use macros such as DEBUG for environment-sensitive branch compilation.

CocoaPods provides DEBUG macro injection by default to facilitate our local debugging.

However, in actual development projects, in addition to using the DEBUG macro to identify local debugging, macros such as TEST or QA are also used to identify the test build package.

At this time, we expect that the library in Pods can also inject TEST macros on demand.

We all know that it is generally recommended to do simple cleanup in the dealloc method.

A very important reason is that in the process of destroying an object, if an operation such as weak is performed, it will cause a crash.

We often encounter scenarios where we need to inject cookies into WKWebView from the outside.

There are several specific schemes, generally speaking, the choice needs to be made in combination with the actual scene.

Here is a description of an actual scenario in a project I’ve encountered.

respondsToSelector is often used to determine whether an instance implements a method for safe calling.

But please don’t call the respondsToSelector method on super.

Sometimes we only want to call a method of the parent class, but we only know that although the parent class implements a certain protocol, it does not necessarily implement the method in the protocol.

When we debug Hexo, we always encounter scenarios where we need to block some production environment logic. Such as some of Google’s JS libraries and so on.

So we need some way to distinguish debug environment, production environment, etc. What we probably need are environment variables.

The return value of rangeOfComposedCharacterSequencesForRange: is not always as expected. This is most likely a bug in the Apple library.

We all know that in Swift, optional chaining is an important feature that can help us write concise and elegant code.

However, the optional assignment derived from the optional chain may have some strange phenomena when used.

I helped a colleague troubleshoot an issue last week. The culprit is a static variable in a header file.

A month ago, after I submitted the AppStore review as usual. Soon I received a review response with the subject line “We noticed an issue with your submission.”

I guess I may have screwed up again.

The reason for rejection is about UIRequiredDeviceCapabilities.