Mobile App Configuration from a Web Engineer's Perspective: Startup-Time Metadata Retrieval Approach

When a mobile app needs to change domains, how do you handle users who continue using older versions?

I’ve worked as a web frontend and backend engineer, and currently as an infrastructure engineer focused on AWS. Knowing the high degree of freedom in web development, the constraints of mobile app reviews and release cycles concern me. From an infrastructure perspective, the cost and risk of maintaining legacy domains also worry me.

In this article, I organize the challenges of mobile apps from multiple layers and propose an approach that retrieves metadata at startup. It’s a configuration that avoids vendor lock-in while reducing operational burden.

Mobile App Challenges from Each Layer’s Perspective

Infrastructure Engineer Perspective

The direct connection between infrastructure and apps is the FQDN. As services continue over time, this domain management can become technical debt.

When issuing new domains due to BFF re-architecture or similar changes, you need to maintain legacy domains while redirecting to new ones. DNS records remain, and unnecessary hosts keep running. Endpoints can become failure points at any time. You’d delete them if you could, but you can’t while users on older app versions remain.

Web Frontend Engineer Perspective

The strength of web frontend is deployment freedom. No reviews or installations required. Reload while ignoring cache, and the latest version arrives. Small fixes can be released multiple times per day.

Mobile apps have reviews, so this freedom isn’t available. The feeling of being able to release whenever you want doesn’t apply to mobile development.

Backend Engineer Perspective

The challenge on the BFF side is maintaining API compatibility. Regardless of how you design versioning, you need to keep old implementations running. This is another structure where code you’d like to delete accumulates.

Proposed Architecture: Startup-Time Metadata Retrieval

I am considering the following architecture.

Prepare a domain called meta.example.com and distribute it via CloudFront and S3. Use the bundle ID as the path and place metadata.json under it.

meta.example.com/
├── com.example.app-a/
│   ├── metadata.json
│   └── metadata.sha256
├── com.example.app-b/
│   ├── metadata.json
│   └── metadata.sha256
└── com.example.app-c/
    ├── metadata.json
    └── metadata.sha256

At app startup, retrieve this JSON and dynamically configure endpoints for backend and static assets. Cache the retrieved metadata locally with appropriate revalidation intervals.

Example metadata.json schema:

{
  "$schema": "https://meta.example.com/schemas/metadata/v1.json",
  "bundle_id": "com.example.app-a",
  "sha256": "xxxxxxxx",
  "revalidate_interval": 604800,
  "backend": {
    "host": "https://api.example.com",
    "ping": "/health",
    "retry": {
      "max_retries": 5,
      "backoff_factor": 2
    }
  },
  "static_assets": {
    "host": "https://cdn.example.com"
  },
  "maintenance_mode": {
    "enabled": false,
    "begin": "2026-02-14T00:00:00Z",
    "end": "2026-02-14T03:00:00Z",
    "message": "Under maintenance"
  }
}

The benefit of this approach is that backend domain changes and maintenance notifications can be completed on the infrastructure side alone. The app side only needs to retrieve metadata at startup and won’t be bound to hardcoded endpoints.

By setting CloudFront’s cache TTL to around 1 day to 1 week, costs can be minimized assuming infrequent updates. A cache busting mechanism should also be considered.

Comparison with Existing Solutions

Firebase Remote Config

Firebase Remote Config is currently offered for free. Functionally, it’s sufficient. However, there are the following concerns.

First is the risk of future monetization. Google services have historically transitioned from free to paid models. This could impact budget planning.

Next is management cost. You need to create a Firebase project for each app. The more apps you manage, the more projects you create and the more complex permission management becomes. For large enterprises operating multiple apps, this management overhead cannot be ignored.

Trade-offs of Custom Implementation

CloudFront+S3 custom implementation has initial setup costs. However, it avoids long-term vendor lock-in risks and enables centralized management of multiple app configurations. Schema evolution can also be controlled internally.

With S3, in the worst case, you can create a JSON file and upload it via drag-and-drop from the GUI console, and you have an update mechanism. For the very early stages, I think this is the easiest approach. However, when considering rollback strategies later, I think it’s necessary to narrow down the update methods to do this properly.

Considerations and Out of Scope

Considerations

Backward Compatibility Schemas evolve from v1 to v2. The issue of old apps being unable to read new schemas is addressed by designing schemas to maintain backward compatibility.

Security JSON tampering risk depends on internal security management. Manage S3 buckets with the principle of least privilege and consider CloudFront signed URLs.

Out of Scope

Rollback Strategy There is a risk that JSON update mistakes are immediately reflected to all users. Rollback strategies need to be considered separately.

Client Network Error Handling JSON retrieval failures at first startup and offline behavior are the app’s responsibility. The app side should handle this optimally.

Offline-First Apps This approach assumes network access at startup. It’s not suitable for apps where offline is the norm.

Real-World Operational Scenarios

This approach is effective in the following cases.

When domain changes occur. You no longer need to maintain legacy domains; updating the JSON is enough to guide users to new endpoints.

When maintenance notifications are needed. Simply enabling maintenance_mode in metadata.json causes the app to display a maintenance screen. Communication to users can be ensured before work involving downtime.

When you want to centrally manage settings for multiple apps. Consolidate to one domain while cutting paths per app for metadata. Management points can be reduced.

Thoughts and Questions

This approach is purely about operational efficiency from the backend layer’s perspective. Engineers with rich mobile app development experience may find missing perspectives or better methods.

How are domain changes and maintenance notifications solved in your environment? Are you using existing services like Firebase Remote Config, or custom implementations? If you have concerns or improvement suggestions for this approach, I’d love to hear them.