Artifact in App Development: What It Is, Types, and How to Manage

What Is an Artifact in Development

An artifact (build artifact) is the result of compiling source code, ready for deployment or use as a dependency. The build process transforms source files (Java, Kotlin, Swift, C++, and others) into binary packages that can be run on a target device or server.

The concept of an artifact extends beyond executable files. For example, a JAR library is an artifact used as a dependency in other projects. A Docker image is an artifact containing the application and its environment. Even a test coverage report can be considered an artifact in the CI/CD context.

Modern development in large companies involves managing hundreds of thousands of artifacts. Google DORA links the maturity of artifact management to overall DevOps effectiveness — teams using artifact registries release faster and encounter fewer deployment issues.

Artifact Lifecycle

Each artifact goes through several stages: creation (build, compilation), validation (testing, security checks), storage (artifact registry), distribution (publication for download), and archiving or deletion (when the version becomes outdated).

Types of Artifacts in Mobile Development

Different platforms and technologies generate different artifact formats. Understanding the formats is essential for configuring the CI/CD pipeline correctly and choosing a storage system.

Android Artifacts

APK (Android Package Kit) is the traditional installation package format. AAB (Android App Bundle) is a modern format for publishing on Google Play, containing only the resources needed by a specific device. AAB reduces the installed application size by an average of 15-20% compared to a universal APK.

iOS Artifacts

IPA (iOS App Store Package) is an archive with code and resources for iOS devices. XCArchive is an intermediate artifact created by Xcode, from which the final IPA is exported. dSYM is a debug symbol file required for crash log symbolication.

Server and Library Project Artifacts

JAR (Java ARchive) — for Java/Kotlin libraries. AAR (Android ARchive) — for Android libraries with resources. Docker images — container artifacts for microservices. Each type has its own registry and version management rules.

Artifacts in the CI/CD Pipeline

Artifacts are the link between pipeline stages. Each stage consumes artifacts from the previous one and produces new ones. Understanding this flow is critical for setting up an effective CI/CD pipeline.

Artifact Flow in the Pipeline

A typical flow includes: commit -> build server compiles the code and creates an unoptimized artifact -> the test artifact is used to run tests -> on success, a release artifact is created -> it is signed and published in the artifact registry -> the artifact is pulled from the registry for deployment to staging and production. Each transition between stages is accompanied by an integrity check and requirement compliance verification.

Intermediate and Final Artifacts

The pipeline can create multiple artifacts at different stages. Debug artifacts contain debugging information, unoptimized ones are built quickly for testing, release artifacts are final, with optimization and obfuscation. The CI system must be able to distinguish between them and apply appropriate retention policies for each type.

name: Artifact Flow
on: [push]

jobs:
  build-debug:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew assembleDebug
      - uses: actions/upload-artifact@v4
        with:
          name: debug-apk
          path: app/build/outputs/apk/debug/app-debug.apk
          retention-days: 7

  test:
    needs: build-debug
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: debug-apk
      - run: ./gradlew testDebugUnitTest

  build-release:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v4
        with:
          name: release-apk
          path: app/build/outputs/apk/release/app-release.apk
          retention-days: 90

Cache vs Artifact

It is important to distinguish between dependency cache and build artifacts. Cache (Gradle cache, CocoaPods cache) speeds up repeated builds but is not intended for deployment. Artifacts are the final product, ready for distribution. Set a TTL of several days for cache, and weeks or months for artifacts.

Artifact Repositories

Artifacts should not be stored on the build server — specialized systems exist for this purpose. A Repository Manager provides centralized storage, indexing, access control, and integration with CI/CD tools.

Popular Artifact Registries

JFrog Artifactory — a universal manager supporting Maven, Gradle, Docker, NuGet, npm, APT, YUM. Sonatype Nexus — an open-source alternative supporting major formats. GitHub Packages — a built-in registry in GitHub, convenient for teams already using GitHub. GitLab Container Registry — for Docker images.

Registry Selection Criteria

Key factors: supported formats, licensing model (open-source/enterprise), integration with existing CI/CD, replication capabilities between regions, availability of automatic cleanup policies for old versions, and compliance reports.

// Jenkins pipeline — publishing APK to Artifactory
def server = Artifactory.newServer(
    url: 'https://artifactory.company.com',
    credentialsId: 'artifactory-api-key'
)

def uploadSpec = """
{
  "files": [
    {
      "pattern": "app/build/outputs/apk/release/*.apk",
      "target": "mobile-apps/android/release/""
    }
  ]
}
"""
server.upload(uploadSpec)

Versioning and Naming

A proper artifact versioning strategy is critical for build reproducibility and change tracking. Without versioning, it is impossible to determine which version of the code caused a problem in production.

Semantic Versioning (SemVer)

The MAJOR.MINOR.PATCH standard: MAJOR changes with incompatible API changes, MINOR with backward-compatible functionality additions, PATCH with backward-compatible bug fixes. For CI/CD, build metadata is added to the version: 2.4.1+build.20260703.1. This allows you to determine exactly which commit produced a specific artifact and when it was created.

Traceability — Git Link

Each artifact should contain metadata about its origin: commit SHA, CI build number, branch name, build date. This information is recorded in the artifact manifest and allows you to reconstruct the context of its creation at any time. Without traceability, working with artifacts becomes version guessing, which is unacceptable for production systems with audit requirements.

Artifact Naming

Naming convention: {project}-{module}-{version}.{ext}. For example: messaging-sdk-2.4.1.aar or app-release-2.4.1.apk. The build server can automatically generate a version based on a Git tag or the CI system build number.

• Use Git tag as the version source — this links the artifact to a specific code state
• Add commit SHA to metadata for precise identification during debugging
• Configure retention policy — keep the latest N versions, archive the rest

Snapshot vs Release

In Maven/Gradle artifact registries, release versions (fixed, immutable) and snapshot versions (current development, can be overwritten) are distinguished. In CI/CD pipelines, snapshot artifacts are convenient for development, but only release versions should be used in production.

Artifact Security

Artifacts are a key element of the software supply chain. Artifact compromise can lead to malicious code entering production. Artifact security includes several protection levels.

Artifact Signing

APK files are signed with jarsigner or apksigner; IPA files are signed with an Apple certificate; Docker images are signed with Content Trust (Notary) by Docker. Signing guarantees integrity and confirms the artifact author. The CI/CD pipeline should include signature verification for all third-party dependencies.

Vulnerability Scanning

Before publication, the artifact is checked by automated scanners: Snyk, Trivy, Sonatype Nexus IQ, GitHub Dependabot. They analyze included dependencies, versions of used libraries, and known CVE vulnerabilities. If a critical vulnerability is detected, the release is immediately blocked until it is fixed by developers.

Supply Chain Levels

SLSA (Supply chain Levels for Software Artifacts) is a security framework defining trust levels from SLSA 1 (basic) to SLSA 4 (maximum). The build server must generate a provenance attestation — a cryptographically signed statement about how and from what code the artifact was built.