You have a couple of options on what to pin. Depending on which one you chose offers you different trade-offs. Here are some typical pins:
Pin the certificate itself
Yes, you will need to change it when the certificate expires. Most secure but quickly causes availability issues if users don’t update often enough.
Pin the public key of the certificate
This allows you to keep the pin unchanged as long as your public key stays the same. You use the same public-key with a new certificate. While it is theoretically a bit less secure, I would put it on the same security level as the previous. If you lose the private key, both setups need app updates.
Pin an intermediate certificate
Here you have two choices again, pin the cert itself or the public key. These certificates have more extended validity periods considerably. You expose yourself a bit more, as the CA can create new certificates that your app would trust.
Pin the root certificate
Again, two options: cert or public key pin. This binds you to a CA, which still increases security; an attacker can’t just use any trusted root to fool your app. While this is the least secure of the options, I think it is still a lot better than not pinning at all.
One thing to consider is always to have multiple pins! If you pin your certificate, make sure to have at least two and pin both, so you can immediately jump to the other if you lose one. If you pin something else on the trust chain, be sure to pin all of the CA’s possible certificates.
In general, I would go for pinning the CA’s root certificate’s public key. This balances security and maintenance. Consider your threat model and chose accordingly.
You can find a bit more information about this at OWASP’s Certificate and Public Key Pinning