This question’s answers do a pretty good job at explaining TLS certificate pinning, and this (external) article is the only source (I could find) that even briefly explains the differences between static and dynamic cert pinning.
But I still don’t entirely understand the concept of each, and their differences in terms of security.
And,
The terms seem to be mostly used for mobile apps. In browsers, there was only one type of key pinning available to the general public (HPKP), and this is long obsolete due to major issues like the risk of locking out users if the server loses access to the pinned key pairs. Browser vendors like Google still pin keys for their own sites and a few others like Facebook.
In Android apps, static key pinning means an app comes with hard-coded pin entries in the network security configuration. This is optimal in terms of confidentiality and integrity, because there's no way to change the pins except by updating the entire app. However, availability can become a problem: Should you lose access to all of the pinned keys, then the app can no longer connect to the domain. The only way to fix this is to roll out an update.
Dynamic key pinning means the pins are loaded from a specific server at runtime. This can be implemented by, for example, using a custom TrustManager. The benefit is that you can easily update the pinned keys at any time. However, this means an attacker who manages to compromise the server can also change the pinned keys and at least temporarily disable the mechanism.
So there is no “right” answer. It's a tradeoff between different security goals.
I don't think "static pinning" and "dynamic pinning" are well-known or well-defined terms.
Certificate pinning restricts which certificates to trust by configuring several keys of trusted certificates in the client. The trusted certificates are typically compiled into the app and shipped with the app. This would be "static pinning". The advantage is that the delivery of the configured certificates is secure. The disadvantage is that when the certificate of the server changes, everybody has to install a new version of the app. If users don't update their app, it stops working as it no longer trusts the new certificate of the server.
To bypass this last problem, some apps can update their configuration dynamically. They retrieve the configuration with trusted certificates from the server. This would be called "dynamic pinning". The advantage is that the developers now have greater control over which certificates are trusted without requiring everyone to update their app. The disadvantage is that this introduces some chicken-and-egg problem. When someone has the old configuration (or no configuration at all yet), they cannot securely retrieve the new configuration from the server if the server already uses the new certificate.
With static pinning, reversing the app can expose the pinned certificates. Dynamic pinning makes it harder to extract expected certificates.
The pinned certificates are not secret. Their integrity needs to be protected, not their confidentiality. With dynamic pinning, the configuration is presumably transferred in a HTTPS request. If the response can be modified, an attacker can configure their own cerfificate as trusted.
Static pins remain constant allowing them to be bypassed once identified.
This is incorrect. Knowing a pinned key does not make it easier or harder to bypass it.
Dynamic pins change frequently to thwart this.
In my experience, "frequently" here means once every 30 days, at least.
Dynamic pinning can retrieve certs on-demand.
The article seems to assume that the certificates to trust are retrieved over a connection that does not use pinning. So the app retrieves the configuration without pinning, and then applies pinning to subsequent connections. Off course, this severely reduces the security of pinning, as the attacker can modify the response to the configuration request to trust their own certificate.
