20 mobile app ideas for 2026, grouped by what made each possible Idea list

Every list like this is mostly reheated: a habit tracker, a receipt scanner, a "Notion but simpler". So the filter here was one question: could this have been built in 2024? If the answer is yes, it is off the list.

What follows is grouped by the specific platform change that opens the door, because the change is the only genuinely new part, and it is also the part that decides how long the window stays open.

Six shifts, twenty ideas, and the catch on each one.

1. Apps became callable tools

Android's AppFunctions lets an app expose annotated functions that the on-device assistant can discover and invoke: effectively every app acting as a local tool provider, with the platform as the registry and execution staying on the device. It is in preview with an early-access programme rather than general availability, which is exactly why it is worth looking at: the surface is not crowded yet.

1. The pantry that is never opened. A food inventory whose entire product is being callable: "what can I make tonight with what is in the house" answered by the assistant reading local state. Almost no UI at all.
The catch: you are building a data source, and the assistant owns the user relationship. Charge for the data, not for the screen.

2. A function permission manager. Show every installed app that exposes on-device functions, what each one can read and do, and let someone revoke a single function without uninstalling the app.
The catch: the platform may ship this itself. Historically it eventually does.

3. Your notes as a tool surface. A private notebook that exposes its own contents as on-device tools, so the assistant answers from your material with nothing leaving the phone.
The catch: it has to be a good notebook first. Nobody adopts a tool surface attached to a notebook they do not already use.

4. An agent action log. A plain-language record of what an assistant did on your behalf across apps, with undo where the app allows it.
The catch: entirely dependent on what the platform exposes. You may be designing against an API that does not exist yet.

2. Wallet-grade proof of age

Every EU member state has to make a certified digital identity wallet available by the end of 2026, and a narrower age-verification wallet is being pushed ahead of the full rollout. The mechanism that matters is selective disclosure: proving you are over a threshold without handing over a birthdate or a document.

5. A door-side verifier for small venues. Staff scan an anonymous over-18 proof. Nothing photographed, nothing retained, no ID passed across a bar.
The catch: this is a certification and liability problem wearing a software costume. The code is the easy third.

6. Proofs that point downward. Almost everything is built to prove you are old enough. A parent-issued proof of being under a threshold would let a service gate content down rather than up.
The catch: you need services willing to consume it, and they are under no obligation to.

7. A disclosure ledger. One timeline of every selective-disclosure request your wallet answered, who asked, for which threshold, when.
The catch: depends on wallet implementations exposing a readable history.

8. Classifieds where the proof replaces the account. No email, no password, no profile. An anonymous credential is the entry condition, which changes who turns up.
The catch: the usual two-sided cold start, now with a smaller starting pool.

3. Products that carry their own data

The EU's central product-passport registry went live in July 2026, and battery passports become mandatory from February 2027 for electric-vehicle and industrial batteries above 2 kWh, retrievable by QR code. Textiles follow later. The data is arriving on a published schedule, which is rare.

9. A passport reader that speaks plainly. Point at the QR, get what the fields actually mean for you: recycled content, state of health, what it does to resale value.
The catch: until the category rules land, most things you scan will have nothing to read.

10. Used-electronics pricing from state of health. Price a second-hand item from its recorded condition rather than the seller's adjectives.
The catch: the first mandated categories are not phones and laptops.

11. "Is this worth fixing". Passport data plus parts availability and a realistic labour estimate, turning repair-or-replace into numbers.
The catch: parts availability is the hard half, and no regulation hands it to you.

12. A household register. Every passport you own in one place, so warranty windows and recycling routes stop being a drawer full of paper.
The catch: low urgency. People do not open admin apps.

4. Satellite links became ordinary

Satellite messaging has moved from a flagship-only emergency feature to something spreading across mid-range devices, with Samsung extending support beyond its flagships during 2026. The constraint is what makes it interesting: bytes are scarce and latency is real.

13. An itinerary that degrades to satellite. Pre-compress the day's critical information: where you are sleeping, the ferry time, the emergency contact: into something that survives a text-only link.
The catch: it matters a few days a year, which makes it hard to charge for.

14. Fixed-code check-ins. Status codes rather than free text for people travelling alone, because characters are the budget. "Camped, on route, fine" in three bytes.
The catch: the safety framing raises the bar. A check-in app that fails quietly is worse than none at all.

5. Models that run on the phone

The processors in current phones run useful models locally: no per-call bill, no upload, and it works with the radio off. That changes what is economic for one developer more than it changes what is possible.

15. A librarian for your own camera roll. Find the receipts, serial numbers, parking spots and meter readings already sitting in twelve thousand photos. Entirely on the device.
The catch: crowded, and the platforms already do a slice of it for free.

16. Voice notes to structured records where audio cannot be uploaded. Site inspections, intake interviews, handover notes: the recording never leaves the device, only the structured summary does.
The catch: selling into those settings is slow, and the buyer is not the user.

17. A redactor that runs before you share. Faces, addresses, account numbers and names blurred on-device as a share-sheet step rather than an app you remember to open.
The catch: it has to be nearly perfect. One miss costs exactly the trust the product is made of.

6. Hardware that finally has reach

18. Room-level finding. Not another tag that says "within nine metres", but ultra-wideband precision that says which shelf.
The catch: hardware. You are now a hardware company with an app attached.

19. The half-open posture as the main layout. Foldables in tabletop mode give you two facing surfaces. Build for negotiation, teaching or translation across a table, rather than treating the fold as a slightly bigger screen.
The catch: small addressable market, and it is a layout, not a product.

20. eSIM profiles organised by place, not by carrier. As phones go eSIM-only the mess is a stack of half-used profiles. Sort them by where they work and switch on a border crossing.
The catch: carrier provisioning is where this gets hard, and none of it is in your control.

---

If I had to pick, it would be from the first group and the third, for opposite reasons. The AppFunctions ideas have a genuine window: the surface is in preview, so the field is empty, and empty fields close. The passport ideas have something rarer, a published date on which the data will exist. Most ideas make you guess whether demand turns up. That one tells you.

The two I would avoid are 12 and 15, and they fail in the same way: real problems that nobody is annoyed enough about to open an app for.