Internal Testing: What It Is, How It Works, and How to Set Up a Track

What is Internal Testing?

Internal Testing is a testing track in Google Play Console and TestFlight designed for distributing builds among development team members. Unlike open beta testing, access to Internal Testing is limited to a list of email addresses approved by the developer account owner.

The main advantage is minimal build delivery time to testers. In Google Play, Internal Testing does not require moderation — the build appears for participants within 5-15 minutes after upload. In the App Store via TestFlight, the build is also delivered without prior App Review but is subject to automatic checks for basic security requirements.

How Internal Testing Differs from Other Tracks

Google Play has three testing tracks: Internal Testing, Closed Beta (Open Beta), and Production. Internal Testing is the fastest and most limited in terms of participants (up to 100 people). Closed Beta allows up to 10,000 participants and requires setting up a testing page. Production is the final stage with full moderation.

When to Use Internal Testing

Internal Testing is used for initial build verification before passing to beta tracks. Developers upload daily builds for the QA team, check new SDK integrations, test compatibility with different OS versions, and identify regression errors before the build is seen by external testers.

Internal Testing in Google Play

In Google Play Console, Internal Testing is a separate track available in the Release → Testing section. To add a tester, simply enter their email address — the participant receives an invitation and a link to join via Google Play. Builds are uploaded through the same interface as production releases.

Publishing Process in the Internal Track

The developer uploads an App Bundle or APK to the Internal Testing section of Google Play Console. The system checks basic requirements: signature, code version, and API compatibility. After 5-15 minutes of processing, the build becomes available to testers. The status is tracked in the console: Draft, In Review, Ready to Test.

// Fastlane — publishing to Internal Testing track
lane :internal_testing do
    gradle(task: ":app:assembleRelease")
    
    upload_to_play_store(
        track: "internal",
        release_status: "completed",
        rollout: 1.0
    )
    
    slack(
        message: "Build uploaded to Internal Testing"
    )
end

Managing Testers

Adding participants is done through the Testers section in Google Play Console. Group upload via CSV file is supported. Each tester receives an email with an invitation and installation instructions. To revoke access, simply remove the participant from the group — the installed app continues to work, but new updates will not be delivered.

Internal Testing in App Store via TestFlight

In the Apple ecosystem, the role of Internal Testing is played by TestFlight — a platform for distributing beta versions. TestFlight supports up to 100 internal testers, who are added by email via App Store Connect. Publishing a build does not require a full App Review, but the build is automatically checked for minimum requirements.

TestFlight Internal Testing Features

Unlike Google Play, where Internal Testing requires no moderation at all, Apple performs an automatic Basic Review. The check takes 30-60 minutes and includes scanning the binary code for malicious APIs and compliance with basic requirements. After a successful check, the build is available to testers within 24 hours. The build is valid for 90 days.

Setting Up Internal Testing in App Store Connect

In App Store Connect, Internal Testing is configured in the TestFlight → Internal Testing section. The account owner adds testers by email and assigns roles. After uploading a build via Xcode or Transporter, the system notifies participants about the availability of a new version. Testers install the app via the TestFlight app on their device.

How to Set Up an Internal Testing Track

Setting up Internal Testing for both platforms takes 10 to 30 minutes. Below are step-by-step instructions for Google Play and App Store. The process does not require changes to the app code — just a one-time setup of the developer console.

Integration with CI/CD Systems

Both stores support publishing to Internal Testing via API. Gradle Play Publisher (Google Play) and Fastlane (both platforms) are used for automation. A CI/CD pipeline can upload builds to the Internal track after each successful run of unit tests and UI tests.

Setting Up Test Accounts

For apps with authentication, it is necessary to prepare test accounts and provide them to the QA team. Accounts should have access to the test environment (staging/development) and should not affect production data. It is recommended to create a separate test Firebase configuration for the Internal track.

QA Workflow with Internal Testing

Internal Testing is integrated into the QA pipeline after passing automatic checks in CI. A developer or DevOps engineer uploads the build to the Internal track, after which QA engineers receive a notification and install the update on test devices via the app store.

Optimal Release Frequency

It is recommended to release builds to Internal Testing daily or after each significant change in the codebase. The QA team tests critical scenarios: authentication, main user flow, API integration, and local storage operations. Regression testing is performed on every third or fourth build.

Feedback Collection Tools

Use integration with tracking systems such as Jira, YouTrack, Trello, or GitHub Issues for collecting bug reports. Testers send screenshots, logs, and reproduction steps. TestFlight has built-in support for collecting screenshots and device logs on shake — data is sent to the developer via App Store Connect.

CI/CD Pipeline Integration

To automatically publish builds to the Internal Testing track, set up a CI/CD pipeline. After passing unit tests and UI tests, the script uploads the build to the Internal track and sends a notification to the QA team. Fastlane provides a ready-to-use action upload_to_play_store with the track: internal parameter. For iOS, use Fastlane Pilot to upload to TestFlight.

Internal Testing Limitations and Limits

Internal Testing has strict limits on the number of participants: up to 100 people in Google Play and up to 100 internal testers in TestFlight. Google Play additionally limits the number of groups — a maximum of 1 group for the Internal track. The App Store does not limit the number of builds, but each build has a 90-day validity period.

Differences in Limits Between Platforms

Google Play does not limit the number of uploaded builds in the Internal track, but after 90 days of inactivity, the track may be automatically suspended. TestFlight has stricter limits: up to 30 active builds simultaneously, up to 10,000 external testers (not Internal). Lifting restrictions requires participation in the Apple Developer Enterprise program.

Migration from Internal to Open Beta

After stabilizing the build on the Internal track, it is moved to Closed or Open Beta for testing with an external audience. Google Play allows copying track settings and transferring the build without re-uploading. TestFlight requires creating a separate external track with new tester groups.

Internal Testing Track Security

Builds in the Internal track are protected from external access: only participants authorized through Google Play Console or App Store Connect can download the app. Even if someone knows the app link, an unauthorized user cannot install the build. This ensures the confidentiality of new features and protects intellectual property during the development phase.