App links best practices are no longer optional for businesses running a mobile app. Whether you are launching a marketing campaign, sending transactional emails, or driving users from social media into your app, how you handle deep linking directly affects your conversion rates, user retention, and revenue. Yet most SMBs implement app links only partially – leaving significant performance gains on the table.
This guide covers everything decision-makers and development teams need to know: the technical foundations, the most common mistakes, actionable configuration steps, and a practical optimization checklist you can apply immediately.
What Are App Links and Why App Links Best Practices Matter
App links are a category of deep links that open a specific screen inside a mobile app instead of a generic homepage or a mobile browser. On Android, Google calls them Android App Links; on iOS, Apple refers to them as Universal Links. Both systems share the same core goal: route users from any digital touchpoint – email, SMS, social post, QR code, web page – directly to the exact content they expect.
The business case is straightforward. Studies consistently show that users who land inside a native app rather than a mobile browser complete purchases at significantly higher rates. Retention is stronger, session depth is greater, and ad spend goes further when every click lands users exactly where they are supposed to go.
For SMBs, the stakes are even higher. You typically have leaner marketing budgets and fewer chances to recover a lost user. A single misconfigured app link silently kills conversions without triggering a single error alert – and that is exactly what makes following established best practices so critical.
Android App Links: Technical Setup and Verification
The Digital Asset Links File
Android App Links rely on a Digital Asset Links JSON file hosted at a specific URL on your domain:
https://yourdomain.com/.well-known/assetlinks.json
This file must be accessible without redirects, served over HTTPS, and contain the correct SHA-256 certificate fingerprint of your app's signing key. A single mismatch here causes Android to silently fall back to the browser – no error is shown to the user.
Key requirements for a valid `assetlinks.json`:
- No HTTP redirects – the file must be served directly at the `.well-known` path
- Content-Type: application/json – the server must return the correct header
- Correct package name – must exactly match your app's `applicationId` in `build.gradle`
- SHA-256 fingerprint – must match the release signing certificate, not the debug keystore
- File must be reachable within 1 second – Google's verification crawler has strict timeout limits
Once the file is correctly hosted, declare the intent filter in your `AndroidManifest.xml` with `android:autoVerify="true"`. Android will verify the association at app install time. If verification succeeds, tapping a matching link opens your app directly – no disambiguation dialog, no browser detour.
Common Android Configuration Mistakes
Using the debug keystore fingerprint in production is the single most frequent error seen in enterprise mobile apps. Your release build uses a different signing key than your debug build. Always generate the SHA-256 fingerprint from your production keystore.
Other mistakes to avoid:
- Forgetting to include the `assetlinks.json` for subdomains (e.g., `shop.yourdomain.com` needs its own file if you link from that subdomain)
- Not updating the fingerprint after rotating your signing certificate
- Blocking the `.well-known` path in your CDN or load balancer configuration
- Using HTTP instead of HTTPS anywhere in the chain
iOS Universal Links: Configuration and Common Pitfalls
Apple App Site Association File
iOS Universal Links use the Apple App Site Association (AASA) file, hosted at:
https://yourdomain.com/.well-known/apple-app-site-association
This file must be served without a file extension, without redirects, and must contain the correct Team ID and Bundle Identifier. Apple's CDN caches this file aggressively – changes can take up to 24–48 hours to propagate across all devices.
A minimal AASA file for a shopping app looks like this:
json
{
"applinks": {
"apps": [],
"details": [
{
"appID": "TEAMID.com.yourcompany.yourapp",
"paths": ["/shop/*", "/product/*", "/account/*"]
}
]
}
}
Handling the iOS Fallback Correctly
When Universal Links fail – because the app is not installed, the AASA file has an error, or the user has explicitly disabled Universal Links for your domain – iOS falls back to Safari and opens the URL in the browser. This is expected behavior, but you must be prepared for it.
Best practices for iOS fallback handling:
- Host a smart banner on your web page using Apple's `<meta name="apple-itunes-app">` tag to prompt app installation
- Implement a deferred deep link mechanism so users who install the app after clicking a link still land on the correct screen
- Use a branch or redirect service to maintain link state across the install flow
Deferred Deep Links: The Missing Piece for Most SMBs
A standard app link only works if the app is already installed. The user clicks a link to a product page, the app is not installed, the browser opens instead – and the deep link destination is lost forever. The user installs the app, opens it, and sees the generic home screen. That friction kills conversion.
Deferred deep links solve this problem. They store the intended destination when the app is not present, and deliver it to the app on first launch after installation. Implementation options include:
1. Third-party SDKs – services like Branch, Adjust, or AppsFlyer provide deferred deep linking out of the box with minimal code integration
2. Custom server-side solution – generate a unique token per click, store the intended destination server-side, and retrieve it on first app launch via the token
3. Firebase Dynamic Links – Google's free solution, though Firebase Dynamic Links were deprecated in 2025, so migration away from this solution is now mandatory
For most SMBs, a third-party SDK is the fastest and most reliable path. The cost is justified by the measurable improvement in install-to-first-action conversion rates.
Testing App Links Before and After Release
Pre-Release Testing Checklist
Testing app links is a critical step that many teams skip or rush. A link that works in development may silently fail in production due to signing certificate differences or CDN configuration issues.
Use the following checklist before every release:
- Verify your assetlinks.json using the Google Digital Asset Links API
- Test Android App Links using `adb shell am start -a android.intent.action.VIEW -d "https://yourdomain.com/product/123" com.yourcompany.app`
- Test iOS Universal Links by sending a link via Notes or Messages, then tapping it – do NOT test by typing the URL into Safari directly
- Check HTTPS certificate validity – an expired certificate breaks both Android and iOS verification
- Test on real devices, not only simulators – Universal Link behavior differs between simulator and physical hardware
Post-Release Monitoring
App link failures are invisible to standard analytics unless you instrument them explicitly. Implement:
- Custom analytics events for each deep link entry point – track which links are opening the app vs. falling through to the browser
- Error logging when an incoming Intent or Universal Link cannot be matched to a known route inside the app
- Alerting when fallback rates spike – a sudden increase in browser fallbacks often indicates a certificate rotation that was not reflected in the AASA or assetlinks.json
App Links Best Practices: The Optimization Checklist
Bringing everything together, here is a prioritized checklist for SMBs implementing or auditing their app links strategy:
Infrastructure:
- Serve both `assetlinks.json` and `apple-app-site-association` from your primary domain and all relevant subdomains
- Ensure sub-100ms response times for both files
- Set `Cache-Control` headers appropriately – Apple recommends no aggressive caching
Development:
- Use production signing certificates during QA testing, not debug keystores
- Implement deferred deep linking from day one, not as an afterthought
- Design app routes to be URL-like and predictable (e.g., `/product/:id`, `/category/:slug`)
- Handle unknown routes gracefully – route to a relevant fallback screen, never crash
Marketing and Operations:
- Coordinate link structure with marketing teams before campaigns launch
- Document all active deep link routes and their expected destinations
- Include link testing in your release QA checklist as a mandatory step
- When rotating signing certificates, update `assetlinks.json` before the old certificate expires
Analytics:
- Track deep link open rates, fallback rates, and post-link conversion separately from organic app opens
- A/B test different landing screens for the same campaign link to optimize in-app conversion
Measuring the ROI of Proper App Link Implementation
For decision-makers, the business case for investing in proper app links best practices is clear. Consider a typical e-commerce SMB running monthly email campaigns:
- Email list: 50,000 users
- Click-through rate: 4% = 2,000 clicks
- Without proper app links: 60% land in browser, 40% open app → only 800 native app sessions
- With proper app links: 90% open app → 1,800 native app sessions
- Conversion rate difference: App sessions convert at 3.5% vs. browser sessions at 1.2%
- Result: 63 additional conversions per campaign from the same email list, zero additional ad spend
At even modest average order values, the cumulative effect across multiple campaigns and channels creates a meaningful revenue difference – fully attributable to engineering investment in app link infrastructure.
When to Bring in an Expert Development Partner
Configuring app links correctly requires coordination across multiple disciplines: backend infrastructure, mobile development, certificate management, and marketing operations. For SMBs without a dedicated mobile platform team, the risk of silent misconfiguration is high.
Working with an experienced development partner ensures:
- Correct initial setup for both Android and iOS from the start
- Integration of deferred deep linking into your existing backend infrastructure
- Ongoing monitoring and rapid response when certificate rotations or infrastructure changes break link verification
- Documentation of your link routing architecture for future developers
Our team at Pilecode has helped SMBs across industries implement robust, measurable app link strategies. You can explore more technical guides on our blog, or get directly in touch with our team to discuss your specific situation.
Conclusion
App links best practices encompass far more than a one-time configuration task. They require careful setup of hosted verification files, correct handling of deferred deep links, systematic pre-release testing, and ongoing monitoring in production. SMBs that invest in getting this right see measurable improvements in campaign conversion rates, user retention, and overall app engagement – without increasing marketing spend.
The technical details are well-documented, the tooling is mature, and the business impact is quantifiable. There is no strategic reason to leave this optimization undone.
Schedule a free initial consultation →
Have questions about this topic? Get in Touch.