CMS Development for Mobile App Content
A marketer wants to change a promotional banner, update prices, or add a new product category. In an app with hardcoded content, this means building a release, reviewing in App Store and Google Play — 24-72 hours of waiting. Users see outdated data. We solve this with a Headless CMS, which moves editable content outside the app. Now changes are published in minutes, without updating the app. Our experience: 50+ projects where this architecture reduced content publishing time by 10x compared to the release cycle.
What CMS Architecture to Choose for a Mobile App?
Headless CMS — delivers content via API, the mobile client renders itself. Contentful, Strapi, Directus, Sanity. Backend + Admin Panel — custom CMS on your own backend (Laravel Nova, React SPA) with full control over structure. Firebase Remote Config — only for flags and simple configs, not for content with images. Contentful reduces content load time by 2x compared to a custom panel thanks to built-in CDN. At 100K DAU, traffic savings can reach $2000 per month.
| Parameter | Strapi | Contentful | Custom Panel |
|---|---|---|---|
| License | Open-source | Paid SaaS | Any |
| Self-hosted | Yes | No | Yes |
| Admin UI out of the box | Yes | Yes | No, needs development |
| Customization | WYSIWYG, relations | Through App | Full |
| CDN | Through your hosting | Built-in | Through your hosting |
Rule of thumb: if content changes less than once a quarter — leave it in code. If frequent — use CMS. For a quick start, Contentful works; for long-term flexibility, choose Strapi or custom.
How to Implement Caching with ETag?
A typical mistake is loading all content every time the screen is opened. At 100K DAU and 50 loads per day, this consumes hundreds of gigabytes of traffic. Solution — ETag: the server computes a hash of content, the client sends it in If-None-Match. If content hasn't changed, the server responds with 304 without body.
class CmsRepository( private val api: CmsApi, private val dao: CmsContentDao, private val prefs: CmsPreferences ) { fun observeHomeScreen(): Flow<HomeScreenContent> = flow { // From cache first val cached = dao.getHomeScreen() if (cached != null) emit(cached.toContent()) // Check for update try { val response = api.getHomeScreen( ifNoneMatch = prefs.homeScreenEtag ) if (response.code() == 304) return@flow // cache is fresh val fresh = response.body()!! dao.upsertHomeScreen(fresh.toEntity()) prefs.homeScreenEtag = response.headers()["ETag"] emit(fresh) } catch (e: IOException) { // Network unavailable — cache already served } } } On the client, we store cache in a local database (Room on Android, CoreData on iOS). First serve from cache, then check for fresh version. This gives instant response and saves bandwidth. In one project, this approach reduced server load by 70%, saving $3000 per year on hosting.
What Is Managed Through CMS?
Not all content should be externalized. If it changes less than once a quarter, keep it in code. Typically we externalize:
- Banners and promo blocks on the home screen
- Onboarding and splash content
- Push notification texts and in-app messages
- Product/service catalog (if not from ERP)
- Static pages (FAQ, terms, contacts)
- Feature flag settings
- Localized content (different texts for regions)
Typical Mistakes When Implementing CMS
Let's look at three common problems with approaches to solutions.
| Mistake | Consequences | Solution |
|---|---|---|
| No caching | 10-20K extra requests per day | Use ETag + local DB |
| Poor API contract | Days spent parsing, frequent bugs | JSON schema per screen, versioning |
| Localization not accounted for | Content in wrong language | Accept-Language on client, i18n in CMS |
ETag caching is 2x faster than versioning for update checks and reduces network traffic by 70%.
CMS Implementation Process
Based on five years of experience (50+ mobile CMS projects), the stages are:
- Analysis — determine dynamic content, design data structure.
- API contract design — JSON schema for all screens.
- Platform selection — Strapi / Contentful / custom.
- Implementation — configure CMS, write API endpoints, admin panel.
- Integration with mobile client — caching, updates, error handling.
- Testing — correct operation offline and under load.
- Deployment — CI/CD for CMS, CDN for images.
What Is Included in the Work
- Headless CMS development (Strapi / custom) with API contracts for your screens
- Client library with ETag caching (iOS / Android)
- Admin UI for content editing
- Localization and feature flags setup
- API documentation and data schema
- Test and production environments
- One month of support after launch
Timelines: 3 to 6 weeks, depending on complexity. Pricing is tailored individually. We guarantee content updates in minutes, without extra releases.
Contact us to estimate your project and get a consultation — we will help you choose the architecture and design the API contract.