Every few months a list appears claiming to know which app categories are booming. Most of them are guesses dressed as data, and the ones with numbers attached usually measure downloads, which is not the same thing as demand for design work. This article takes a different route. Instead of predicting a market, it looks at the structural forces that create sustained demand for mobile app design, names the categories those forces are currently pushing hardest, and is explicit about where the reasoning ends and speculation would begin.
Demand for apps is not demand for app design
The first thing to separate is app usage from app commissioning. Consumers spend most of their mobile hours inside a handful of enormous apps, and no amount of demand for those creates work for anyone outside those companies. The design work sits somewhere else entirely.
Where commissioned work actually comes from
Design engagements appear when a business has a process, a customer relationship or a piece of hardware that would be better served by an app it controls, and lacks the internal capability to design one. That is a completely different filter from consumer attention. A regional logistics company with 200 drivers generates more design work than a viral consumer app with a million downloads and two founders who design it themselves.
So the useful question is not “what are people downloading” but “what kinds of organisations currently have a mobile problem, a budget, and no design team”. Everything below is filtered through that.
Three drivers that create real work
Capability shifts. A device or platform can suddenly do something it could not before, cheaply enough to build on. New sensors, better on-device processing, faster networks. Each shift opens a category of product that was previously impractical.
Regulatory and compliance pressure. When rules change, organisations must adopt new processes, and processes on phones need interfaces. This is unglamorous, well funded, and almost never covered in trend pieces.
Labour economics. When staff are scarce or expensive, companies invest in tools that make each person faster, and increasingly those tools live on a phone in a pocket rather than a terminal on a desk. This is the quietest and most reliable driver of the three.
Notice that none of these is a style. “Neumorphism is in demand” is a sentence about visual fashion. The drivers above create demand for entire product categories, which is what actually pays for design.
AI native apps, and the shift from features to assistants
The largest current shift is the move from apps that contain an AI feature to apps whose entire interaction model assumes a capable model underneath.
Why mobile specifically
Phones carry the sensors that make assistance useful: a camera that can see what the user sees, a microphone for hands free operation, location for context, and a permanent network connection. An assistant on a laptop can read what you type. An assistant on a phone can look at the thing you are pointing at, which is a categorically different product.
On-device processing has also improved to the point where some inference happens locally, which changes the privacy conversation and removes latency from short interactions. That combination, sensors plus local inference plus cheap remote inference for the hard parts, is why so many briefs now arrive with an assistant in them.
What the design work actually involves
It is rarely a chat box, and teams that assume otherwise produce something disappointing. The harder and more valuable work is deciding where intelligence attaches to the objects a user already works with, how a suggestion is offered without hijacking the screen, and what the interface does while it is thinking. Those decisions are covered at length in the patterns that work when chat is the wrong answer, and the mobile specific constraints get their own treatment in designing AI mobile apps.
The trust layer is where most of the budget goes. Users need to see what the system used to decide, correct it cheaply, and understand when it is guessing, which is a set of patterns rather than a disclaimer.
How to read this demand honestly
Some of this is real and some is a funding cycle. The durable part is any product where the model does work a person genuinely could not do faster themselves. The fragile part is any product where the model is a wrapper around a search box. If a brief cannot articulate what the user could not do before, it is worth saying so before building.
Health, fitness and clinically adjacent apps
Sustained, well funded, and design heavy, for reasons that have very little to do with fashion.
The structural drivers
Health systems everywhere are trying to move care out of expensive buildings and into cheaper settings, which means remote monitoring, triage, adherence and follow up all need consumer grade interfaces. Wearables now produce continuous data that has to be made meaningful to a person who is not a clinician. And an ageing population in most developed markets increases the number of people managing long term conditions from home.
Each of those creates a product with a real user, a real payer, and a compliance requirement, which is the combination that produces budget.
Why the design is hard
Health apps carry constraints most consumer products do not. They handle sensitive data under regimes like HIPAA or GDPR, which shapes onboarding, storage, sharing and even analytics. They are used by people who are anxious, unwell or distracted, which raises the bar for clarity. They often need to work for someone with impaired vision or shaky hands, so accessibility is a requirement rather than a nice to have.
They also carry a specific ethical weight: the difference between motivating and shaming is a copy decision, and it is easy to get wrong. That territory is covered fully in health and fitness app design.
The adjacent categories
Mental health, sleep, nutrition, fertility, chronic condition management and clinic side tools all share the same design vocabulary. Our own clinical work sits on the operational side of this, in a clinic management system with six roles and tested safety rules, and the patterns transfer directly.
Financial apps beyond banking
Banking apps themselves are largely built. The demand has moved to the layer around them.
Where the work is now
Embedded finance, where a non financial company offers payments, credit or insurance inside its own product, is the clearest example. A marketplace adding instant payouts, a construction platform adding invoice financing, a retailer adding instalments. In each case a company with no financial design experience suddenly needs interfaces for money movement.
Alongside that sit business finance tools for the self employed and small companies, expense and spend management, and the compliance heavy onboarding flows that every one of them requires.
The design constraint that defines the category
Money interfaces are trust interfaces, and the design consequences are specific: unambiguous numbers, states that never leave a user unsure whether a transaction happened, and confirmation rather than optimism on anything irreversible. We have written the full treatment in fintech app design, and the underlying principle, that precision in how numbers are displayed is a design responsibility, applies to every product in this group.
On demand services and two sided marketplaces
The category people think is saturated, which is saturated only in the two or three verticals everyone names.
Why demand persists
Food delivery and ride hailing are settled. What is not settled is the long tail: trades, cleaning, tutoring, equipment hire, veterinary care, freight, childcare, salon services, agricultural services, medical transport. Each of these has local operators who watched the model work elsewhere and now want it in their market and their vertical.
The structural driver is that the model is proven, the infrastructure is commodity, and the remaining differentiator is execution. That is precisely the condition that produces design work rather than platform work.
What makes marketplace design distinctive
You are designing two products with one brand: a consumer app optimised for speed and confidence, and a provider app optimised for earnings, scheduling and dispute avoidance. The two have opposite priorities and must stay consistent. Add the cold start problem, where the product must feel useful before there is enough supply for it to be useful, and you have a genuinely difficult brief. The whole territory is covered in marketplace and on demand app design.
Field service and frontline operations
The least fashionable category on this list and, by a distance, the most reliably funded.
The driver is labour, not technology
Skilled trades are scarce in most markets, which makes each technician’s hour expensive. Any tool that removes twenty minutes of paperwork per job pays for itself quickly and measurably. That is the easiest business case in software, and it is why these projects get approved when consumer projects do not.
The same logic applies to drivers, warehouse staff, inspectors, care workers, site supervisors, utility crews and agricultural workers. All of them work away from a desk, all of them currently carry either paper or a badly designed app, and all of them cost their employer real money when the tool slows them down.
Why the design is genuinely hard
These apps are used in sunlight, in the rain, wearing gloves, with one hand, on a cracked mid range Android phone with no signal in a basement. Offline behaviour is not an edge case, it is the primary state. Data density matters more than whitespace, and the states nobody demos become the main experience.
It is also a category where a redesign disturbs people who have built genuine fluency, so the rollout is as delicate as the design. The full treatment is in field service app design.
Education, training and compliance learning
Quieter than the categories above but consistently funded, particularly on the corporate side.
Consumer language and skills apps are crowded and dominated by well capitalised incumbents. Corporate training, professional certification, safety compliance and industry specific upskilling are not, and they carry the same advantage as field tools: an organisation pays, completion is measurable, and often a regulator requires it. The design problems are habit formation, progress that feels real, and content that survives being consumed in five minute gaps between other work.
Connected hardware and companion apps
Any physical product with a chip in it eventually needs an app, and hardware companies rarely have designers who work on software.
The list keeps growing: home energy and solar, EV charging, security and access, agricultural sensors, medical devices, industrial monitoring, fitness equipment. The design problem is specific and repeatable. Pairing and setup is the highest risk moment in the entire product, because a customer who cannot connect the device returns it. After setup, the app must degrade gracefully when the hardware is offline, explain physical states in plain language, and handle firmware updates without alarming anyone.
These briefs are attractive because the hardware company already has revenue, already has customers, and has an obvious cost attached to a bad experience: returns.
What the strongest categories have in common
Look across the list and the pattern is clear enough to use as a filter.
A payer who is not the user
Health systems, employers, hardware manufacturers and marketplaces all pay for software used by someone else. That separation is what funds serious design work, because the payer has a measurable reason to care about whether the tool works.
A consequence when the design fails
A returned device, a missed dose, a driver who quits, a technician who reverts to paper, a payment that goes to the wrong account. Categories with real consequences attract real budgets. Categories where failure means mild disappointment do not.
Constraints that make the work non trivial
Offline operation, regulated data, two sided incentives, hardware states, clinical safety. These are the things that make a project hard to template, which is exactly why they get commissioned rather than assembled.
Where demand is softer than it looks
Being honest about the weak side matters as much as naming the strong side.
Generic consumer social, another habit tracker, another meditation app, another recipe app, another local events app: these have enormous supply, negligible differentiation, and usually no payer other than the founder. The design work exists but rarely at a level that sustains a studio, and the product usually fails for distribution reasons that no interface can fix.
Internal apps built because a manager wanted an app rather than because a worker needed one are the other soft spot. They get funded, they get designed, and then adoption sits near zero because the tool solved a reporting problem for the person who commissioned it and added work for the person holding the phone. The tell is a brief where nobody has watched the intended user do the job, which is a gap that half a day of watching would close.
Simple content and catalogue apps are also weakening, because a fast, well built website does the same job with none of the install friction. When a brief arrives for one, the responsible answer is often to ask whether an app is genuinely the right container before anyone draws a screen.
How to read demand if you are deciding what to build
If you are choosing where to point your own investment, three questions cut through most trend reading.
Who pays, and what does the failure cost them
If you cannot name the payer and the cost of the tool not existing, the demand is theoretical. If you can name both, you have a business case regardless of what any trend list says.
Does the phone do something a browser cannot
Camera, sensors, location, offline operation, push at the right moment, background processing. If none of these are load bearing in your idea, you may be commissioning an app for the wrong reason, and the cheaper route is a fast responsive site.
Can you reach the first hundred users without paid acquisition
Categories serving an organisation come with distribution attached, which is a large part of why they are more reliably fundable than consumer categories where distribution is the whole game.
What this means if you are commissioning design
Choose a studio by whether they have solved your category’s specific constraint, not by whether their portfolio is beautiful. Offline conflict resolution, clinical data handling, two sided incentive design and hardware pairing are all learned rather than intuited, and portfolio gloss tells you nothing about them.
Then expect the process to start with the constraint rather than the screens. A brief that opens with visual references and no discussion of who pays, what happens offline, or what a failure costs is a brief that will produce something attractive and wrong. If you are assembling one now, the structure of a brief that gets you what you imagined is worth twenty minutes, and reading competing proposals properly is worth rather more than that.
What each category costs and how long it takes
Categories differ more in scope than in day rate, and knowing the shape in advance stops a conversation going badly.
The variables that actually move the number
Screen count is the weakest predictor and the one everybody quotes. The real drivers are the number of distinct user roles, whether the product must work offline, whether regulated data is involved, how many states each screen carries, and whether hardware is in the loop.
A single role consumer app with network assumed is the cheapest thing on this list. A two sided marketplace has two products. A field tool with offline sync has a data model problem sitting underneath every screen. A clinical product adds review cycles that have nothing to do with design quality and everything to do with governance.
Rough shapes, stated as assumptions
Take a studio charging a blended rate and assume a designer works productively for six hours a day. A focused consumer utility with one role, twelve to eighteen screens and no offline requirement is a few weeks of design. A marketplace with consumer and provider apps, each with its own onboarding, payments and dispute handling, is a multiple of that rather than an increment, because you are scoping two products that must stay consistent.
Field and clinical products land between the two on screen count and above both on total effort, because the states multiply. A job screen that has a connected version, an offline version, a sync conflict version, a partially completed version and a rejected version is five designs, not one, and pretending otherwise is how timelines slip.
The honest framing is the same one that applies to websites: the sticker price tells you very little until you know what has been included and what has been quietly left out.
Where budgets get wasted
Two failures repeat. The first is paying for a full design of every screen before validating the core flow, which produces a beautiful file and a product nobody has tested. The second is the opposite, shipping the happy path only and discovering the missing states during build, where they get invented by a developer at speed. Scoping the states up front is what separates a design from a picture of a design.
Native, cross platform, or not an app at all
The category usually decides this, which is convenient, because it turns an argument about technology into a question about requirements.
When the category demands native
Anything leaning hard on sensors, background processing, precise camera control, on device inference, complex offline sync, or platform specific hardware integration. Field tools with heavy offline requirements and connected hardware companions frequently land here, not because native is better in the abstract but because the specific capability sits closer to the metal.
When cross platform is the right default
Most marketplace, health, education and finance products. The interface is the product, the hardware requirements are ordinary, and shipping one codebase to two platforms is a material saving that buys more design iterations. The design implication matters: you are designing one system that must feel correct on both platforms rather than two platform native experiences, so component decisions and platform conventions need deciding early and writing down. That is a design system question rather than an engineering one.
When the honest answer is no app
If the product is content, catalogue, booking or brochure, and none of the phone’s capabilities are load bearing, an installed app adds friction at exactly the moment a new user is least committed. Install, permissions and account creation are three gates a website does not have. Saying this out loud costs a studio work and saves the client money, which is why the question deserves a proper answer rather than a sales answer.
A worked filter: three briefs, scored the same way
Run the drivers as a scorecard and the differences become obvious. Score each brief on payer clarity, failure cost, phone dependency and distribution.
Brief one: a habit tracking app for general wellbeing
Payer is the founder. Failure cost is disappointment. Phone dependency is real but weak, since the same job is done by a notes app. Distribution is paid acquisition into a crowded category against free incumbents. Three weak signals out of four. This can still succeed, but it succeeds on marketing rather than design, and the design budget will not be the constraint.
Brief two: an inspection app for a regional utility
Payer is the utility, and the case is arithmetic: inspectors currently complete paper forms and re enter them at the depot. Failure cost is measurable in hours per inspector per week. Phone dependency is total, because the work happens on poles and in basements with no signal. Distribution is solved on day one, because the employer installs it. Four strong signals.
Brief three: a booking app for a chain of clinics
Payer is the clinic group. Failure cost is no shows, which have a known value. Phone dependency is moderate: reminders and calendar integration matter, but the booking itself works fine on the web. Distribution comes from existing patients. Three strong signals and one honest caveat, which is that the app should probably be an addition to a booking flow that also works in a browser rather than a replacement for it.
The scorecard does not tell you what is fashionable. It tells you which briefs have a business underneath them, which is the only definition of demand that pays.
What about visual style rather than category
There is a second way to read the question, which is which app aesthetics are currently wanted. It deserves an answer, but a smaller one than people expect, because style follows category far more than category follows style.
Style is downstream of constraint
A field tool used in sunlight needs high contrast, large targets and dense information. A clinical product needs calm, unambiguous surfaces and typography that survives a shaking hand. A finance product needs aligned numerals and restraint, because visual flourish reads as unseriousness when money is involved. In each case the constraint produced the look, not a mood board.
That is why briefs that lead with a visual reference and no constraint tend to produce work that looks current and performs badly. The reference is usually a consumer product with none of the requirements the new product actually carries.
What is genuinely shifting
A few things are worth naming without dressing them as trends. Interfaces are getting quieter, so heavy ornament, drop shadows everywhere and decorative gradients read as dated next to flatter, more typographic surfaces. Type is doing more of the work, which raises the bar on getting the scale and hierarchy right. Dark presentation has moved from a feature to an expectation, and building it properly means designing a second palette rather than inverting the first. Motion is being used more sparingly and more functionally, to explain where something came from rather than to decorate a transition, which is the line between motion that helps and motion that irritates.
Accessibility has also shifted from a compliance afterthought to a baseline expectation in commissioned work, particularly anywhere a public body or a regulated industry is paying.
The part that does not change
Legibility, touch target size, obvious affordances, honest states and fast response. Every one of those outlives whatever aesthetic is current, and every one of them is what a user notices when it is missing. A product that gets those right and looks a year behind will outperform a fashionable product that gets them wrong, which is the least fashionable sentence in this article and the most reliably true.
What we would watch rather than predict
Anyone who tells you confidently what mobile design looks like in two years is guessing. What can be said with more confidence is which conditions would change the picture.
Watch what happens to on device model capability, because the more inference runs locally, the more products become viable for privacy sensitive categories that currently cannot send data anywhere. Watch regulatory movement in health and finance, since new rules reliably produce new interfaces. Watch labour markets in the trades, because scarcity there has funded most of the field tooling built in the last few years. And watch distribution costs, since consumer app economics are decided by acquisition price rather than by product quality.
None of that is a forecast. It is a list of the dials that, if they move, would change which categories on this page are worth your attention.
If you are weighing a mobile product and want a straight read on whether the category, the payer and the constraint line up, describe the idea in a paragraph and you will get an honest answer, including when the answer is that a website would serve you better: hello@beconfidency.agency.
When the category is clear and the hard part is the product itself, that is exactly what our product design service is for.