MADP, MEAP, MBaaS, LCAP: Enterprise Mobile Terms Explained

Enterprise mobile has more acronyms than most corners of software. An RFP might ask for a MADP with MBaaS, MAM support and LCAP governance, scored against an MXDP report from 2019, and expect you to know which of those still exist. Most of these terms came from analyst firms and vendors, and several have been renamed or retired, so even experienced buyers mix them up.

This glossary explains each one in plain English, says whether it still matters, and gives the practical question it should prompt when you are choosing how to build an app. We build RapidNative, an AI builder for native mobile apps, so at the end we place it on the same map.

The quick reference

The rest of this post goes through them in groups.

Platform categories: MEAP, MADP, MXDP and LCAP

MEAP: mobile enterprise application platform

Gartner coined MEAP in a 2008 Magic Quadrant, when companies were trying to put the same internal app on BlackBerry, Windows Mobile and the new iPhone. A MEAP was mostly middleware: a server that connected to back-office systems, plus tools to build clients for each device. Gartner's "rule of three" said a MEAP was worth it once you had three or more mobile apps, three or more operating systems, or three or more backend systems to integrate. Vendors of the era included Sybase (later SAP), Antenna, Syclo, Kony and IBM Worklight.

Today: the word is mostly historical, but the need is not. If an RFP says MEAP, it means internal apps for employees, connected to existing systems.

MCAP: mobile consumer application platform

Briefly, analysts tracked customer-facing app platforms as a separate category from MEAP. It did not last, because the same tools were building both.

MADP: mobile app development platform

MADP replaced both: one category for any platform that lets you design, build, test, publish and maintain mobile apps. It was the main analyst lens for mobile through most of the 2010s. In practice a MADP covers six layers: front-end development, backend services, integration, security and management, distribution, and updates. Our full guide to mobile app development platforms walks through them and the questions to ask a vendor.

Question it should prompt: which of those six layers will the platform own, and which will you keep?

MXDP: multiexperience development platform

In 2019 Gartner replaced its MADP report with a Magic Quadrant for multiexperience development platforms: building for mobile, web, conversational interfaces, wearables and voice from one toolset. The leaders were mostly low-code vendors. The term never caught on outside analyst reports.

Question it should prompt: do you actually need one tool for every channel, or great apps on the two channels your users live on?

LCAP and hpaPaaS: low-code application platforms

An LCAP lets developers and business technologists build applications through visual modelling, drag-and-drop interfaces and configuration rather than hand-written code. Gartner's earlier name for the category was hpaPaaS, high-productivity application platform as a service. OutSystems, Mendix, Microsoft Power Apps, Appian and Salesforce Platform are the best-known enterprise LCAPs. Mobile is one of several outputs, alongside web apps and workflows.

The trade-off: speed and central governance, in exchange for apps that run on the vendor's runtime and pricing that often scales per user. We compare the main options in our enterprise mobile app development guide, and the wider low-code landscape in low-code mobile app development.

Question it should prompt: if we stop paying, what do we have left?

RMAD: rapid mobile app development

RMAD described a mid-2010s wave of tools that let business users assemble simple mobile apps from templates and forms without IT. The term faded, but the idea became today's no-code builders, and now AI app builders.

Backend terms: MBaaS, BaaS and middleware

MBaaS: mobile backend as a service

A mobile backend as a service gives an app a ready-made backend: a database, user sign-in, file storage, push notifications and often realtime updates, all reached through an SDK. It means a mobile team does not have to build and run servers for standard features.

The category's history is a useful warning. Parse, one of the first popular MBaaS products, was acquired by Facebook in 2013 and shut down in January 2017, forcing thousands of apps to migrate. Firebase, acquired by Google in 2014, became the default after that. Supabase, an open-source alternative built on Postgres, is now a common choice because you can also host it yourself. Our explainer on what Supabase is covers why mobile teams pick it.

Question it should prompt: can we take our data and auth with us, or host the backend ourselves if we must?

Middleware and API gateways

In enterprise settings the backend often already exists. Middleware or an API gateway sits between the app and systems like SAP or Salesforce, translating and securing requests. This is what MEAPs used to bundle. Today it is usually a separate integration layer, and the app talks to it over REST or GraphQL.

Device and security terms: MDM, MAM, EMM, UEM

MDM: mobile device management

MDM controls the entire device: enrollment, passcode rules, Wi-Fi and VPN settings, which apps are installed, and remote wipe. It is the norm for company-owned phones and tablets.

MAM: mobile application management

MAM controls only the company's apps and the data inside them. IT can require a PIN to open a work app, block copying data into personal apps, encrypt app data and wipe just the work data when someone leaves. Because it leaves the rest of the phone alone, it is the usual answer for BYOD, bring your own device.

MDM vs MAM in one sentence: MDM manages the phone, MAM manages the app.

EMM and UEM

EMM, enterprise mobility management, was the suite that bundled MDM and MAM. UEM, unified endpoint management, extends the same controls to laptops and desktops. Microsoft Intune, Omnissa Workspace ONE (formerly VMware) and Jamf are the common tools.

Related terms you will see

• App protection policies: MAM rules applied to an app, usually by integrating the vendor's SDK into the app itself. That requires access to the app's source code.
• App wrapping: adding management controls to a compiled app without changing its source. Less common now, and not supported for every app type.
• Managed app configuration (AppConfig): a standard way for an MDM to push settings, like a server address, into an app.
• Conditional access: sign-in rules that depend on the device's state, such as blocking access from a phone that is not compliant.

Distribution terms

• Public store release: the App Store and Google Play, with review and policy rules. Customer apps go here.
• Custom apps (Apple Business Manager): private iOS apps, available only to the organizations you choose, deployed through the MDM.
• Managed Google Play private apps: the Android equivalent.
• Apple Developer Enterprise Program: in-house iOS distribution outside the App Store, restricted by Apple to qualifying organizations and internal use.
• TestFlight and Play testing tracks: beta channels before release.
• OTA (over-the-air) updates: pushing JavaScript or asset updates to an app without a new store build, allowed within the stores' rules. Expo's update service is a common example.

Build terms: native, cross-platform, hybrid

• Native: apps built with each platform's own tools, Swift for iOS and Kotlin for Android.
• Cross-platform: one codebase for both platforms that still renders native UI. React Native, Flutter and Kotlin Multiplatform are the main options.
• Hybrid: a web app inside a native shell (a web view), as with Cordova or Capacitor. Faster to make, but it often feels like a website, and Apple's App Store Review Guideline 4.2 rejects apps that are just a repackaged website.
• PWA (progressive web app): a website that can be installed to the home screen. No store review, fewer device features, especially on iOS.

Our guide to native vs hybrid app development goes deeper on the trade-offs.

The new vocabulary: AI app builders

The latest terms are not from analyst reports yet:

• AI app builder: a platform that generates an app from a natural-language description, a sketch or a screenshot.
• Prompt to app: the workflow itself, describing what you want and iterating by conversation.
• Vibe coding: building software mainly by prompting an AI and reviewing the result, rather than writing code line by line.

The question that matters is the same one as with low-code: what is the output? Most AI app builders produce web apps. For mobile, the output needs to be a real native project you can run on a phone, review and keep.

Where RapidNative fits on this map

In this vocabulary, RapidNative is an AI-first MADP whose output is a standard cross-platform app, with an MBaaS built in. You describe the app, or start from a sketch, screenshot or requirements document, and it generates a full-stack React Native and Expo app with a database, sign-in, file storage and realtime updates. You try it on your own phone by scanning a QR code. You can swap the built-in backend for your own Supabase project or APIs, and on paid plans you export the full TypeScript project with no proprietary runtime, so your engineers can add MAM SDKs, SSO or anything else your standards require. Public store releases can go through LetsDeploy.It, our sister service. For teams with stricter requirements, the enterprise plan adds SSO and dedicated support.

It is not an LCAP: there is no proprietary runtime and no per-user pricing for the people using your app. And it is not hybrid: the result is native UI, not a website in a frame.

Turning acronyms into questions

When an RFP lists acronyms, translate each one into the question behind it:

The acronyms change every few years. Those questions don't. If you want to see what a modern answer looks like, build a first screen of your app with RapidNative on the free plan and open it on your phone.