Upgrade now when the new version fixes a security problem you are exposed to or a store deadline needs it. Wait when the change is optional and the vendor has not stabilised it. Replace when support is ending and there is no credible upgrade path.
Start with three questions
- Is there a security fix in the new version that applies to how you use it? Reachability matters here. A vulnerable function you never call is a lower priority than one on your login path.
- Is there a hard deadline? Store requirements, a vendor end of support date or an operating system change can set one. Check the source, because dates move.
- What does the vendor say about the old version? A published support window changes everything. Silence is also an answer.
The decision table
| Situation | Usual decision | Reason |
|---|---|---|
| Security fix, reachable in your app | Upgrade now | Exposure is real |
| Security fix, not reachable | Upgrade in the normal cycle | Lower urgency, still record it |
| Store or platform deadline | Upgrade before the date | Missing it blocks releases |
| New major, no fix, no deadline | Wait, with a date to revisit | Early majors often get quick follow up patches |
| Vendor announces end of support | Plan upgrade or replacement now | The window is the deadline |
| Vendor silent, no releases for a long time | Treat as abandoned, plan replacement | Fixes will not arrive |
| Vendor changed owner or terms | Review before the next upgrade | See what to review when a vendor changes owner or terms |
When waiting is reasonable
A major release often has early patch releases. Waiting a few weeks can save you a round of rework. But set a review date. Waiting with no date is deferring forever, and the cost grows as your version falls further behind. Stepwise upgrades are also easier than one large jump, see how to upgrade one major version at a time.
When to replace
Signals that point to replacement:
- The vendor has stated an end of support date and offers no successor.
- Security reports go unanswered.
- The SDK needs a platform minimum you cannot meet.
- It pulls in dependencies that are themselves unmaintained.
Then follow a controlled exit, as described in how to remove a third party SDK from a mobile app. A wrapper makes this much easier, see wrapping a mobile SDK behind your own interface.
Record the decision
Write the choice, the reason, the owner and the next review date in your SDK register. If you wait, record the risk you accepted and who accepted it. Time limited exceptions work better than open ones, see granting time limited waivers for mobile SDKs.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how many findings drop in priority once you ask whether the vulnerable code is actually reachable.
Where Safeguard fits
Safeguard's reachability analysis helps separate advisories you are exposed to from those you are not, which feeds the first question above. Dependency scanning and SBOM output provide the inventory. A free scan is at gold.safeguard.sh/scan.
Quick check
Is it ever fine to stay on an old major version?
Yes, if it still receives security fixes, you have a dated review and the risk is recorded. Without fixes it becomes debt with interest.
Who should make the call?
The SDK owner decides with security input, and a named approver accepts any deferral. See a simple RACI for mobile SDK governance.
Last reviewed: 19 October 2026.
