App configuration

How it works

The app developer declares the settings it accepts. On Android those are managed configurations, read through the RestrictionsManager API and described in the app's own XML. On iOS and iPadOS the MDM pushes a configuration dictionary that the app reads at startup. The AppConfig community standardised the key names in 2016, which is why the same setting often works across platforms.

The admin fills the values in the console, per app and per group. A sales team gets one tenant URL, a subcontractor another, and nobody touches a settings screen on the device.

The limit is clear: an app only accepts what it declares. If the vendor published no configuration schema, there's nothing to push. For public apps, check the vendor documentation; for your own builds, adding a handful of keys is usually an afternoon of work and saves weeks of support.

Why it matters for a fleet

First launch is where deployments die. A driver gets a new handset, opens the delivery app, and faces a screen asking for a server hostname he has never heard of. That becomes a support call, or worse, a typo that nobody notices until the data lands in the wrong tenant.

Configuration also lets you lock behaviour. Disable local file export, force the document viewer into read-only mode, pin the scanner app to a single warehouse profile. Changing a value later updates the devices without a reinstall, which matters when a backend URL moves.

One piece of advice from real deployments: keep configuration values in the console, never in the APK. Rebuilding an app because a URL changed is a waste.

How Appaloosa handles it

Appaloosa applies managed app configuration at install time, per app and per device group, for public apps that support it and for your own internal builds. Values can be updated later and pushed to enrolled devices without a reinstall, alongside kiosk mode and security policies. See the Mobile Application Management page.