First, inventory every link and dependency
List public page.link and custom-domain URLs, the campaign or screen each represented, and every app or website that consumed Dynamic Links. Firebase's deprecation FAQ explains that links served by the service stopped working after the shutdown date.
Classify each use case
- Store routing: a visitor should reach the correct store based on device.
- In-app destination: an installed app should open a specific screen.
- Post-install context or measurement: the link needs deferred deep linking or attribution.
Do not assume one replacement covers every category. See the smart links vs deep links guide for the practical distinctions.
Choose the smallest solution that meets the requirement
For public App Store and Google Play routing, a browser-based smart link can be enough and avoids an SDK. For in-app routing or attribution, evaluate native implementation and specialised providers against the specific capability you need. Do not describe simple store routing as deferred deep linking.
Test and replace deliberately
- Create replacement destinations and test them on iOS, Android, and desktop.
- Replace links in controlled surfaces first: website, email templates, social profiles, and current campaigns.
- Keep an inventory of legacy locations that cannot be changed, such as printed material, and update them on the next production cycle.
- Monitor click volume and fallback traffic after each batch.
For simple app-store links
appqr.io creates one browser-based link for supported app stores plus a downloadable QR code. It does not provide deferred deep linking or install attribution. Read the scoped Firebase comparison or create a link.