Universal Links Setup for iOS: From AASA to Navigation

App doesn't open from a link in an email? Users complain that the site opens in the browser instead of the app? Universal Links solve this directly: a link like https://yourapp.com/product/123 opens the app on the correct screen, bypassing the browser. No custom schemes (myapp://product/123) that don't work in Safari and are blocked by corporate MDM. We are a mobile development team with over 5 years of experience; we have configured deep linking via universal links for 15+ iOS projects with a total audience of over 2 million users. On one project with 500 thousand users, we discovered that users could not navigate from an email campaign to a specific product—conversion dropped by 20%. After implementing universal linking, it recovered and grew by 15%. This article covers a proven methodology and common pitfalls. For deep linking iOS setup, follow the steps below.

Why Universal Links Are Better Than Custom Schemes

Custom URL schemes (myapp://) have fundamental drawbacks:

• They don't work in Safari by default—the user sees an error "Cannot Open App".
• They are not supported in corporate MDM environments.
• They have no fallback to the web version.

Universal Links are free of these problems: they use standard HTTPS, support fallback to the site, and require no additional user action. Security is higher—the scheme cannot be intercepted by another app.

How Universal Links Work and Where They Break

AASA file. The file at https://yourapp.com/.well-known/apple-app-site-association on the server must be JSON without file extension, served with Content-Type: application/json, accessible via HTTPS without redirects. Apple parses this file when the app is installed and caches it on a CDN—updating can take up to 24 hours. The AASA file should be kept under 50KB for optimal performance.

Most common mistake: the server serves the file with a redirect from http to https, or a 301 to a www version of the domain. Apple does not follow redirects when downloading AASA. Check with curl -v https://yourapp.com/.well-known/apple-app-site-association—it should return 200 with correct Content-Type. Use the swcutil command on macOS to validate entitlements.

Format for iOS 13+ (applinks with details):

{
  "applinks": {
    "details": [{
      "appIDs": ["TEAMID.com.yourapp.bundle"],
      "components": [
        { "/": "/product/*", "comment": "Product pages" },
        { "/": "/order/*" }
      ]
    }]
  }
}

App Entitlements. In Entitlements.plist you need com.apple.developer.associated-domains with an entry applinks:yourapp.com. A forgotten entitlement means the app simply doesn't receive the universal link callback. Enable associated domains iOS through Xcode capabilities.

Handling in Code. In AppDelegate or SceneDelegate, implement application(_:continue:restorationHandler:) (UIKit) or onOpenURL (SwiftUI). You get NSUserActivity with type NSUserActivityTypeBrowsingWeb and webpageURL. Parse the path using URLComponents to determine the target screen and build the navigation stack. AppDelegate universal link handling involves implementing that method. For SwiftUI deep link handling, use the onOpenURL modifier.

URL parsing must be robust: webpageURL may come with query parameters, fragments, or uppercase letters. Use URLComponents instead of manual string parsing to avoid encoding issues. Implement URL routing iOS logic using URLComponents.

Testing. In the simulator, universal links work via xcrun simctl openurl booted 'https://yourapp.com/product/123'. On a real device, use Safari (long press on the link → "Open in App"). Xcode → Diagnostics won't show AASA issues—you need swcutil on Mac and Console.app for swcd logs (Apple's universal links daemon).

How to Verify the AASA File Is Correct

1. Run curl -v https://yourapp.com/.well-known/apple-app-site-association. Expect HTTP/1.1 200 OK and Content-Type: application/json.
2. Use Apple's AASA Validator (built into Apple Developer).
3. On Mac, open Console.app, filter by swcd—you'll see AASA download logs.
4. On iOS: enter the link in Safari, after opening the app check logs via the device.

Apple uses a CDN to cache the AASA file and verifies the domain via SSL certificate. This prevents unauthorized apps from claiming your domain.

Typical Issues During Setup

Often developers face that the link opens the website instead of the app. The reason is an inaccessible or incorrect AASA file: the server serves a redirect or wrong format. Solution: remove redirects and ensure format matches iOS 13+. Another issue: universal link not handled because the entitlement com.apple.developer.associated-domains is missing from the target. Third: the AASA file not updating due to Apple caching (up to 24 hours). Use developer mode to speed up.

Scenarios and Edge Cases

Multiple domains. An app can handle up to 5 domains—just add multiple entries in entitlements. An AASA file is needed on each domain separately.

Links from email clients. Gmail and Outlook in iOS apps wrap links through their redirect services. Universal links won't fire in this case—Apple sees the redirect URL, not the target. This is a platform limitation, not a bug.

Service Deliverables

• AASA file setup on the server with required path patterns
• Entitlements and Xcode configuration for all targets and schemes (Debug, Release, Staging)
• Handler implementation in SceneDelegate / AppDelegate with routing to target screens using URLComponents
• Testing on real devices and via simulator
• Verification through Apple's validator and swcd logs
• Project documentation including server access instructions and entitlement configuration
• 30-day post-deployment support for any issues
• Optional training session for your team (1 hour) to maintain the setup

Pricing starts at $499 for a single domain with up to 5 path patterns. For multiple domains or custom logic, cost is calculated individually. Based on our experience, average savings are 40% compared to in-house setup due to reduced trial and error. We offer iOS deep linking turnkey solutions starting at $499. The iOS deep linking cost depends on complexity; typical multi-domain setups range from $799 to $1,299.

Timelines

Basic implementation with several path patterns and integration into existing navigation: 1 to 2 days. With support for multiple domains and custom routing logic: 2 to 3 days. Timelines are estimated conservatively; over 95% of projects meet the deadline.

Get an engineer consultation—we'll help with your project.

Why is Native iOS Development the Best Choice for Complex Apps

The app crashes on cold start — EXC_BAD_ACCESS at the moment of initializing a singleton that accesses another singleton that hasn't been initialized yet. Or: a ViewController leaks memory because a closure captures self without [weak self], and that ViewController hangs in memory two transitions after the user left it. These are not hypothetical scenarios — they are the two most common classes of problems on iOS projects that come to us after another team.

We have been doing iOS development for over 5 years, delivered 40+ projects of varying complexity — from startups to enterprise solutions with millions of users. Each project undergoes 3 stages of Code Review, a custom set of UI tests (150+ test cases on average), and a mandatory run through Xcode Instruments before release.

Native iOS development with Swift means direct access to the platform. No middleware, no performance compromises, full control over what happens on every frame.

What Makes Native iOS Development on Swift the Choice for Enterprise Apps?

Native code guarantees compatibility with new Apple APIs on the day they are released, not after months of adaptation in cross-platform frameworks. For apps with latency-sensitive logic (financial terminals, medical monitors, AR navigation), this is critical. Swift with ARC and strict typing allows maintaining a crash-free rate of 99.9% with proper architecture.

SwiftUI or UIKit: What to Choose for Native iOS Development

By now, SwiftUI covers the vast majority of production tasks. But UIKit is not deprecated and will not disappear — Apple does not deprecate it but continues to add APIs. The real picture on large projects: a hybrid approach. SwiftUI for most screens, UIKit where SwiftUI hits limitations.

Which Scenarios Does SwiftUI Win Unconditionally

SwiftUI's declarative syntax reduces UI code by 3-5 times compared to UIKit. A settings screen with List, Toggle, Picker — that's 40 lines of SwiftUI versus 200 lines of UIKit with UITableViewDataSource delegates. Time savings on UI development reach 60%. Apple recommends starting new projects on SwiftUI (Human Interface Guidelines).

@State, @Binding, @ObservableObject (and with iOS 17, the @Observable macro) create a reactive link between data and UI without manual reloadData(). Changing a @State variable automatically redraws the affected part of the hierarchy. This works correctly if you understand how SwiftUI computes the diff — via Equatable and id in ForEach.

AsyncImage, NavigationStack with type-safe routing via NavigationPath, searchable, refreshable — these are ready-made patterns that UIKit requires implementing manually.

When UIKit Remains Necessary

UICollectionView with compositional layout and diffable data source — complex grids with different cell types, horizontal sections inside vertical scroll, dynamic cell sizes. SwiftUI LazyVGrid / LazyHGrid do not provide such control.

Custom transitions between screens. UIViewControllerAnimatedTransitioning and UIViewControllerInteractiveTransitioning — interactive pop gesture with partial progress, custom hero transition with precise frame control. SwiftUI matchedGeometryEffect covers some cases, but not all.

UITextView with TextKit 2. Rich text editor, custom attributes, custom rendering — TextKit 2 (available since iOS 16) switched to async layout, solving performance issues on long documents. SwiftUI TextEditor is a wrapper around UITextView without direct access to TextKit.

UIScrollView with custom behavior. scrollViewDidScroll, parallax effects, sticky headers with custom logic, pull-to-refresh with custom indicator. SwiftUI ScrollView with scrollPosition and onScrollGeometryChange (iOS 17) covers some cases, but not all.

How Do We Integrate SwiftUI and UIKit Step by Step

1. Identify screens where SwiftUI gives maximum gain (lists, forms, settings) — usually 70-80% of screens.
2. For performance-critical areas (complex collections, custom animations) leave UIKit.
3. Use UIHostingController to embed SwiftUI views into UIKit navigation stack.
4. For backward compatibility, wrap UIKit components via UIViewRepresentable.
5. Coordinator pattern (UIKit) manages navigation at the flow level, screens are implemented in SwiftUI.

One pattern we use on projects: UIKit coordinator manages navigation, while the screens themselves are in SwiftUI. The coordinator creates a UIHostingController, passes ViewModel via initializer or @EnvironmentObject, and manages transitions. This gives clean separation: SwiftUI handles UI, Coordinator handles navigation.

How async/await and Combine Work Together

Before Swift 5.5, asynchronous code on iOS was built on Combine or callback chains. With the advent of async/await and Actor, concurrency has become part of the language. On new projects we use async/await as the primary tool for network calls and business logic, and Combine for reactive UI state binding.

// Correct — @MainActor guarantees UI updates on main thread
@MainActor
class UserViewModel: ObservableObject {
    @Published var user: User?
    @Published var isLoading = false

    func loadUser(id: String) async {
        isLoading = true
        defer { isLoading = false }
        do {
            user = try await userService.fetch(id: id)
        } catch {
            // handle error
        }
    }
}

Combine remains indispensable for debouncing input, merging multiple Publishers (CombineLatest, Zip), and functional processing of value streams (map, flatMap, filter). In practice, 80% of projects use both approaches, choosing the tool for the task.

iOS App Architecture

MVVM — the basic pattern. ViewModel contains logic and @Published state, SwiftUI View subscribes via @ObservedObject or @StateObject. One rule: View knows nothing about URLSession, CoreData, UserDefaults.

Clean Architecture adds Repository and UseCase layers. UserRepository abstracts the data source (network vs cache). FetchUserUseCase contains business logic. UserViewModel calls UseCase and manages UI state.

TCA (The Composable Architecture) — a stricter pattern from Point-Free. State, Action, Reducer, Effect — everything explicit, testable, composable via Scope. Works well in large teams (5+ iOS developers) where predictability is important.

What's Included in iOS App Development

Tools Without Which No Release Is Complete

Xcode Instruments. Time Profiler shows where CPU spends time. Allocations — memory leaks and excessive allocations. Leaks — objects that are not freed. Before every release — a mandatory run.

Firebase Crashlytics. Crash-free rate, grouping by stack trace, breadcrumbs of events leading to crash. Set up in 30 minutes, provides visibility across the entire device fleet. On our projects, average crash-free rate is 99.8%.

Fastlane match. Manage certificates and provisioning profiles via an encrypted git repository. Eliminates the 'it builds locally but not on CI' issue once and for all. Saves up to 4 hours per build when signing manually.

XCTest + XCUITest. Unit tests for ViewModel and UseCase, UI tests for critical flows (onboarding, payment, authorization). On average, code coverage is 75%.

Process and Timelines

Cost is calculated individually after analyzing the technical specification and design. Typically, the first 2 weeks are spent on design, after which we finalize the timeline and budget.

Order turnkey development — we will evaluate your project in 2 business days and propose the optimal architecture. Contact us to discuss your task: we guarantee code quality, compliance with App Store Review Guidelines, and experience with projects of any scale. Get a consultation — we will help you choose the right stack and avoid common mistakes at the start.