Bolt On in Mobile Development — What It Is, Methods and How It Works

What “Bolt On” Means in Development

Bolt on — a metaphor meaning attaching a new functional block to an existing system. Unlike the word “add”, “bolt on” implies that the component was not designed from scratch for the current architecture but is integrated as an external solution. This could be a library, framework, API client or a ready-made UI element.

Developers “bolt on” components for several reasons: to avoid reinventing the wheel, to speed up development, or to add functionality the team cannot build on their own. Working with dependency management has become so standardized that bolting on a library takes minutes, not days. However, incorrect integration can lead to version conflicts, increased app size and security issues.

The term is universal and applies to any platform: iOS, Android, Web. On iOS, CocoaPods and SPM are dependency managers; on Android — Gradle; on Web — npm. The process of bolting on involves several steps: choosing a component, checking compatibility, adding it through a manager, configuring and testing.

Bolting On a Library: Working with Dependencies

Dependency managers are tools that automate adding third-party libraries to a project. They solve three tasks: downloading library code, resolving transitive dependencies and managing versions. Without a manager, developers would have to manually download files, copy them into the project and track updates.

Each platform uses its own manager: iOS — Swift Package Manager (SPM) or CocoaPods, Android — Gradle with Maven Central, Flutter — pub.dev. The principle is the same: you specify the package name and version in a configuration file, the manager downloads dependencies and configures the build.

Example of Bolting On a Library on Android

Let’s add Retrofit — an HTTP client for Android. In the module-level build.gradle file, add the dependency, sync the project, and the library is ready to use. Gradle automatically downloads Retrofit itself and its transitive dependencies: OkHttp, Gson converter.

dependencies {
    implementation 'com.squareup.retrofit2:retrofit:2.9.0'
    implementation 'com.squareup.retrofit2:converter-gson:2.9.0'
    implementation 'com.squareup.okhttp3:logging-interceptor:4.11.0'
}

Example of Bolting On a Library on iOS

In iOS projects via Swift Package Manager, a library is added through Xcode: File → Add Packages. Alternatively, via Package.swift. For Alamofire, a popular networking library, just specify the repository URL and version. SPM will download the sources and add them to the build.

// Package.swift
let package = Package(
    name: "MyApp",
    dependencies: [
        .package(url: "https://github.com/Alamofire/Alamofire.git",
                 from: "5.9.0")
    ]
)

Bolting On an API: Integrating External Services

API integration is one of the most common “bolting on” scenarios in mobile development. Almost every app communicates with a server: sending data, receiving content, authenticating users. Bolting on an API means configuring the network communication between client and server, handling responses and errors.

The process includes three stages: choosing an HTTP client, configuring endpoints and handling responses. Modern clients like Retrofit (Android) and Alamofire (iOS) provide a declarative API for describing requests and automatic response serialization. After bolting on the client, the developer works with typed data models instead of raw JSON strings.

// Define API interface with Retrofit
interface GithubApi {
    @GET("users/{username}/repos")
    suspend fun getRepos(
        @Path("username") username: String
    ): List<Repo>
}

After describing the interface, you just need to create an instance of Retrofit, pass the base URL and add interceptors for logging, authentication and error handling. Then the client instance is injected into a repository or ViewModel. Bolting on an API can be considered complete when the app successfully sends a request and correctly handles the response.

Bolting On a UI Component: Building the Interface

UI components from ready-made libraries are another common target for “bolting on.” Instead of drawing a custom element from scratch, developers add a library with ready-made controls: cards, buttons, input fields, navigation menus. This speeds up development and ensures UI consistency.

On Android, Material Components from Google implementing Material Design are used. On iOS — standard UIKit or third-party libraries like SnapKit for layout. In Flutter, the entire UI consists of widgets, and bolting on a new component often means simply adding it to the widget tree and configuring parameters.

Bolting On a Custom View on iOS via SnapKit

SnapKit is a library for Auto Layout via DSL. After adding it through SPM, you can describe constraints declaratively, without Interface Builder. This speeds up layout and makes code more readable. Bolting on SnapKit is a five-minute task, after which the entire project uses a consistent layout style.

import SnapKit

let button = UIButton()
view.addSubview(button)
button.snp.makeConstraints { make in
    make.center.equalTo(superview)
    make.width.equalTo(200)
    make.height.equalTo(48)
}

Checking Compatibility Before Integration

Before bolting on any component, check three parameters: target platform version, license and maintenance activity. A library that has not been updated in two years may contain unfixed vulnerabilities. An outdated API may not compile with a new SDK version. The license may prohibit commercial use.

• minSdk/target — does the OS version match your target audience
• License — Apache 2.0, MIT, GPL — is it allowed in your project
• Relevance — when was the last commit and release in the repository
• Size — will the library increase the APK/IPA size critically
• Transitive dependencies — will the library pull in conflicting versions

Common Problems When Bolting On and How to Fix Them

Even a simple “bolt on a library” operation can turn into hours of debugging. Let’s look at four typical problems developers face when integrating dependencies and ways to solve them.

Transitive Dependency Conflict

Two libraries may require different versions of the same package. Gradle on Android throws a ConflictException, while Swift Package Manager tries to resolve the conflict automatically but not always successfully. The solution is to force a version or exclude the transitive dependency using exclude. Sometimes it’s easier to find an alternative library.

implementation('com.example:library-a:2.0.0') {
    exclude group: 'com.example', module: 'conflicting-lib'
}

Multidex on Android

When adding several large libraries, the method count may exceed the 65K limit. Android requires enabling multidex in build.gradle and adding MultidexApplication. Without this, the app will crash on startup with the error “Cannot fit requested classes in a single dex file.”

Library Does Not Work on Simulator

Some native libraries contain code signed only for physical devices. On iOS, this happens when connecting libraries with arm64 architecture for the simulator. The solution is to exclude the simulator architecture from the fat framework or wait for a version with .xcframework support.

Increased Build Time

Each bolted-on library increases build time. KAPT — the annotation processor for Kotlin — significantly slows down Gradle. The solution is to use KSP instead of KAPT, minimize the number of dynamic feature modules and cache dependencies. After bolting on the first library, measure build time as a baseline.