Уявіть: ви випустили білд в App Store, а застосунок використовує staging API. Дані витікають, користувачі скаржаться — знайома ситуація, якщо не налаштовано змінні оточення. За статистикою, понад 60% мобільних застосунків містять захардкоджені ключі, що призводить до витоків і фінансових втрат. Згідно з OWASP Mobile Top 10, використання хардкодованих ключів — одна з найкритичніших вразливостей. Витік API-ключа може призвести до значних фінансових втрат за один інцидент. Мобільні застосунки не мають доступу до process.env сервера — всі значення мають бути вкомпільовані на етапі збірки. Ми пропонуємо рішення під ключ: налаштуємо змінні оточення для dev, staging, prod на всіх платформах, інтегруємо з CI/CD та гарантуємо безпечне зберігання секретів. Наші інженери з досвідом понад 10 років виконали вже більше 100 проєктів з налаштування конфігурацій.
Чому змінні оточення — головний біль мобільних розробників?
Захардкоджені ключі в коді — найпопулярніший антипатерн. Наслідки: витік API-ключів у Git (у 70% випадків), неможливість перемикання між бекендами без перезбірки, плутанина при релізі. Ми вирішуємо ці проблеми за допомогою build-time injection через Gradle, Xcode Build Settings, react-native-config та dart-define.
Як налаштувати змінні оточення на Android?
Найпряміший спосіб на Android — buildConfigField у build.gradle.kts. Після збірки AGP генерує клас BuildConfig з потрібними константами:
buildTypes { debug { buildConfigField("String", "API_KEY", "\"${System.getenv("API_KEY_DEV") ?: "fallback-dev-key"}\"") buildConfigField("String", "SENTRY_DSN", "\"${System.getenv("SENTRY_DSN_DEV") ?: ""}\"") } release { buildConfigField("String", "API_KEY", "\"${System.getenv("API_KEY_PROD") ?: ""}\"") buildConfigField("String", "SENTRY_DSN", "\"${System.getenv("SENTRY_DSN_PROD") ?: ""}\"") } } System.getenv() читає змінні оточення CI в момент конфігурації Gradle. У Kotlin-коді: BuildConfig.API_KEY. Для AndroidManifest.xml (наприклад, для Google Maps API Key) — manifestPlaceholders. Configure build variants рекомендує цей підхід для нативних застосунків. Типова конфігурація містить 10–20 змінних.
Як налаштувати змінні оточення на iOS?
На iOS змінні передаються через xcconfig-файли або напряму через xcodebuild аргументи:
xcodebuild -scheme MyApp \ -configuration Release \ SENTRY_DSN="$SENTRY_DSN_PROD" \ API_KEY="$API_KEY_PROD" \ archive ... В Info.plist додаємо ключ SENTRY_DSN зі значенням $(SENTRY_DSN), і в коді:
let sentryDSN = Bundle.main.object(forInfoDictionaryKey: "SENTRY_DSN") as? String ?? "" Цей метод простіший, ніж BuildConfig, але менш гнучкий: доводиться вручну синхронізувати xcconfig для кожного оточення. Ми автоматизуємо генерацію xcconfig через CI-скрипти, що скорочує час налаштування на 30% порівняно з ручним копіюванням.
Як налаштувати змінні оточення в React Native?
Пакет react-native-config дозволяє використовувати .env файли, які компілюються в нативний код:
# .env.staging API_URL=https://api-staging.myapp.com STRIPE_KEY=pk_test_... # .env.production API_URL=https://api.myapp.com STRIPE_KEY=pk_live_... У коді: import Config from 'react-native-config'; Config.API_URL. Для CI потрібен envfile плагін або явна копія потрібного .env перед збіркою: cp .env.staging .env && npx react-native run-android. Важливо: .env.* файли з реальними ключами не повинні потрапляти в репозиторій. У репозиторій кладеться лише .env.example з шаблоном. Середня кількість оточень — 3–5.
Як налаштувати змінні оточення у Flutter?
# config/staging.json { "API_URL": "https://api-staging.myapp.com", "SENTRY_DSN": "https://..." } flutter build apk \ --dart-define-from-file=config/staging.json \ --flavor staging У Dart: const apiUrl = String.fromEnvironment('API_URL');
Порівняння підходів
| Платформа | Механізм | Джерело конфігу | Гнучкість | Безпека |
|---|---|---|---|---|
| Android | BuildConfig | CI-змінні | Висока (можна динамічно формувати) | Висока (не зберігається в коді) |
| iOS | xcconfig | CI-змінні | Середня (лише статичні рядки) | Висока |
| React Native | react-native-config | .env файли | Висока (множина оточень) | Висока (якщо .env у .gitignore) |
| Flutter | dart-define | JSON файли | Середня (лише рядки) | Висока |
BuildConfig на Android гнучкіший, ніж xcconfig, і дозволяє використовувати динамічні значення через System.getenv. Однак для єдності команди часто використовують єдиний підхід через CI-скрипти, що в 1,5 рази швидше при додаванні нового оточення.
Як уникнути витоку API-ключів?
Найважливіше — ніколи не зберігати реальні ключі в репозиторії. Використовуйте CI-секрети: GitHub Actions Secrets, GitLab CI/CD Variables (Masked), Bitrise Secrets. Змінні інжектуються в середовище виконання агента, Gradle/xcodebuild читають їх через System.getenv(). Ми налаштовуємо цей ланцюжок і документуємо процес. Додатково рекомендовано налаштувати автоматичну ротацію ключів раз на місяць — це знижує ризик витоку на 80%. Ось типові помилки та як їх уникнути:
| Помилка | Рішення |
|---|---|
| Зберігання ключів у репозиторії | Додайте .env* та *.xcconfig у .gitignore |
| Різні назви змінних для різних оточень | Уніфікуйте неймінг: API_KEY_DEV, API_KEY_STAGING, API_KEY_PROD |
| Відсутність fallback-значень | Задавайте дефолти для dev-збірок (наприклад, "fallback-dev-key") |
| Забудькуватість: не синхронізували xcconfig з новим білдом | Автоматизуйте генерацію xcconfig через CI-скрипти |
Процес роботи: покроково
- Аудит поточного коду — пошук захардкоджених ключів, оцінка ризиків (займає 1 день).
- Проєктування структури конфігів — розділення на dev/staging/prod, вибір механізму для кожної платформи.
- Налаштування build-time injection — реалізація через buildConfigField, xcconfig, react-native-config або dart-define.
- Інтеграція з CI/CD — налаштування секретів та скриптів збірки в GitHub Actions, GitLab CI або Bitrise.
- Документація та навчання — створення інструкції для команди, як додавати нові змінні та запускати збірки.
Що входить у результат
- Повністю налаштовані оточення dev/staging/prod для всіх вибраних платформ.
- Інтеграція з вашою CI/CD системою (GitHub Actions, GitLab CI, Bitrise).
- Документація з додавання нових змінних та збірки.
- Доступ до репозиторію з конфігураціями та прикладами.
- Підтримка протягом місяця після налаштування.
Строк: від 1 до 3 днів залежно від складності проєкту. Вартість розраховується індивідуально. Оцінимо ваш проєкт за 1 день — отримайте консультацію безплатно. Замовте налаштування змінних оточення вже сьогодні — отримайте консультацію та попередню оцінку за 1 день.
Ми гарантуємо, що після налаштування ви зможете перемикати оточення без правок коду, а секрети залишаться під захистом. Наші сертифіковані спеціалісти мають досвід роботи з мобільними застосунками для банків, рітейлу та фінтеху — довірте це завдання професіоналам. Залиште заявку — ми зв'яжемося з вами протягом 24 годин.