What Makes an App Technically Impossible to Build Now?

A dating app wanted to create a feature that would vibrate your phone differently depending on how compatible a match was with your preferences, stronger vibrations for better matches and gentler ones for casual interests. The idea was simple enough on paper (and honestly quite clever from a user experience perspective), but when we started testing the prototype we discovered that iOS doesn't let developers control vibration intensity at all, you get one standard vibration pattern and that's it. Android offers a bit more flexibility but even then the hardware varies so wildly between devices that what felt like a gentle buzz on a Samsung would rattle a Pixel off the table. The whole feature had to be scrapped, not because we couldn't write the code but because the platforms simply don't expose that level of control to developers.

Technical impossibility in app development rarely comes from a lack of coding skill, it comes from the hard boundaries that platforms, physics and third-party services place around what's actually possible on a mobile device.

After building apps for the last decade I've had to deliver bad news to clients more times than I'd like, telling them that their vision for a particular feature just can't be done. Not "can't be done within budget" or "can't be done this year", but genuinely impossible given current technology and platform restrictions. These conversations never get easier because people naturally assume that if they can think of something then developers should be able to build it, which makes sense when you look at how far mobile technology has come. The reality though is that mobile devices have very real limitations that desktop computers don't face, and app developers work within boundaries set by Apple and Google that can shut down entire feature sets before a single line of code gets written.

Battery and Hardware Access Limits

Mobile devices are battery-powered machines and both iOS and Android place strict limits on what apps can do in the background specifically to prevent developers from draining that battery. I worked on a fitness tracking app that wanted to use the GPS constantly throughout the day to automatically detect when users started exercising, no need to manually start a workout session. Sounds reasonable until you realise that continuous GPS usage would kill most phone batteries in about four hours. The operating systems know this so they throttle background location access quite aggressively, which meant we had to rely on much less accurate cell tower triangulation when the app wasn't actively open. The feature worked but it was nowhere near as precise as the client had envisioned.

Temperature sensors present another frustrating limitation. Several clients have asked about reading ambient room temperature through the phone, maybe for a smart home app or a baby monitoring solution. The problem is that phones do have temperature sensors but they're designed to monitor the device's internal temperature to prevent overheating, they're not calibrated for external readings and they're not exposed to developers through any official API. You could theoretically jailbreak or root a device to access these sensors but that immediately disqualifies your app from the App Store and Google Play.

When Third-Party APIs Let You Down

Your app might be technically perfect but if it relies on external services then you're only as reliable as your weakest dependency. I've seen this play out in painful ways over the years, particularly with social media APIs that change their terms or restrict access with little warning. A restaurant discovery app we built integrated heavily with Instagram's API to show food photos from local venues, then Instagram changed their API access requirements and suddenly half the app's content disappeared overnight. The client had to pivot their entire content strategy because we could no longer pull in the photos that made their app useful.

Always build your app architecture assuming that any third-party service could disappear tomorrow. Store copies of data locally where legally permissible, have fallback options ready, and never make your app's core value proposition dependent on someone else's API staying available.

Payment processing APIs come with their own set of restrictions that can make certain business models technically impossible. A marketplace app wanted to implement instant payouts to sellers the moment a buyer made a purchase, but both Stripe and PayPal have mandatory holding periods for new accounts and certain transaction types. This wasn't a feature we could negotiate or code around, the financial regulations and fraud prevention requirements that these payment processors follow make instant transfers impossible for most use cases. The client's entire business model assumed immediate payouts so this limitation genuinely made their app concept unviable.

• Social media APIs can restrict or remove access without notice
• Payment processors enforce holding periods and verification requirements
• Mapping services have query limits that can break location-based features
• Weather data APIs often have delays that make real-time features impossible
• Authentication services can change their pricing or shut down entirely

Real-Time Processing on Mobile Devices

Mobile processors have become impressively powerful but they're still a fraction of what a proper server can handle, and they overheat quickly under sustained load. A healthcare client wanted their app to analyse blood test images using computer vision, processing the photo entirely on-device for privacy reasons. We built a prototype that worked but it took nearly two minutes to analyse a single image and made the phone uncomfortably warm to hold. Users won't tolerate that kind of experience no matter how clever the underlying technology is.

Video processing presents similar challenges. An e-learning app wanted to let teachers record lessons on their phones and have the app automatically remove long pauses and mistakes, essentially editing the video on-device. The processing power required to analyse and re-encode video in any reasonable timeframe just isn't available on most devices. We could do it if we uploaded the video to a server but that defeated the client's goal of keeping everything private and local. Sometimes the physics of mobile hardware simply don't align with user expectations.

The Physics of Data Transfer

Mobile internet connections are unreliable in ways that WiFi rarely is, and this creates hard limits on what kinds of features can work reliably. A video conferencing app wanted to support up to 20 participants simultaneously with high-definition video, which sounds reasonable until you calculate the bandwidth requirements. Even with aggressive video compression you're looking at needing a sustained 15-20 Mbps connection, which many mobile networks simply can't provide consistently. Users on 4G in rural areas or on congested networks would just see frozen screens and timeouts, making the feature technically impossible for a significant portion of the user base.

The speed of light creates a minimum latency that no amount of optimisation can overcome, which is why truly real-time collaboration between users on opposite sides of the world will always have a noticeable delay.

File sync services face this same physics problem. A document collaboration app wanted to implement Google Docs-style simultaneous editing where you could see other people's changes character by character as they typed. This requires sending data packets back and forth constantly, often several times per second. On a stable broadband connection this works fine but mobile connections frequently drop packets or switch between cell towers which interrupts that constant stream of updates. We ended up having to implement a much cruder sync system that only updated every few seconds, which made the experience feel jerky and less magical than what users expected from desktop equivalents.

Platform Restrictions and Store Guidelines

Apple and Google maintain extensive lists of things your app absolutely cannot do if you want to be distributed through their stores, and these restrictions eliminate entire categories of apps from being viable. Cryptocurrency mining apps are banned outright because they drain batteries and generate heat. Apps that display user-generated content need moderation systems in place before they'll be approved. Any app that could be used to stalk or track someone without their explicit knowledge gets rejected immediately, which includes some legitimate use cases that clients have requested.

I had a client who wanted to build a parental control app that would let parents see their teenager's text messages and social media activity. On Android this is technically possible if you jump through enough hoops, but iOS makes it completely impossible without jailbreaking the device. Apple's sandboxing means that one app cannot read data from another app under any circumstances, there's no API for this and there never will be because it would be a massive privacy violation. The client's entire business model couldn't work on iOS which meant they were immediately losing half their potential market.

App Store Review Processes

Even if something is technically possible to build, getting it approved for distribution is another matter entirely. Apps that replicate functionality already built into the operating system often get rejected for being "not useful enough". Apps that use private APIs (undocumented system functions that Apple and Google don't officially support) will get rejected even if they work perfectly. I've seen apps get rejected for having buttons that looked too similar to system buttons, for not clearly explaining what each permission request is used for, and for including placeholder content in screenshots. These aren't technical limitations in the coding sense but they make certain app concepts genuinely impossible to bring to market. App Store policies continue to evolve and become more restrictive over time.

Cross-Device Synchronisation Boundaries

Users expect their data to appear instantly across all their devices but the technical reality of making this happen reliably is remarkably complex. A note-taking app wanted to implement conflict resolution where if you edited the same note on your phone and tablet while offline, the app would intelligently merge both sets of changes when you came back online. This sounds straightforward but once you account for the thousands of different ways edits can conflict and overlap, you quickly realise why most apps just show you both versions and make you pick one. True automatic conflict resolution that doesn't occasionally destroy user data is genuinely difficult to get right.

Design your sync strategy around eventual consistency rather than immediate consistency. Let users know when their data is still syncing rather than pretending it's instant, because the honesty prevents frustration when things don't appear immediately on other devices.

Cross-platform development adds another layer of complexity here. An e-commerce app built with React Native wanted to share a shopping cart between the mobile app, a web app and a desktop app in real-time. Each platform handles local data storage differently, has different performance characteristics and may be online or offline at any given moment. Getting all these systems to agree on the current state of a shopping cart (bearing in mind that stock levels might have changed, prices might have updated, and promotions might have expired since the cart was first created) becomes a distributed systems problem that would challenge a team of PhD engineers. Most small app projects simply don't have the resources to solve this properly, which is why many teams start with simpler cross-platform approaches and evolve their architecture over time.

1. Design for offline-first functionality where data syncs when possible
2. Accept that perfect real-time sync across all platforms isn't realistic
3. Build clear user feedback for when sync is happening versus complete
4. Have a "last write wins" strategy with timestamps for simple conflicts
5. For complex data, store versions and let users choose rather than auto-merging

Security Requirements That Block Features

Modern security requirements, both from platform holders and from regulations like GDPR, make certain features technically impossible without compromising user safety. A messaging app wanted to implement a feature where you could search through your message history using their servers to make it faster than searching locally, but this would require uploading all your messages to their servers which immediately raises massive privacy concerns. End-to-end encryption means that the server can't read your messages, but if it can't read them then it can't search them either. The feature was impossible without fundamentally weakening the security model.

Biometric authentication creates similar constraints. A banking app wanted to use facial recognition to verify user identity before allowing large transfers, which sounds sensible until you think about the security implications. Face data is incredibly sensitive and storing it on your servers is a massive liability. Using the device's built-in Face ID is more secure but then you're limited to whatever accuracy Apple's or Google's systems provide, and you can't customise the behaviour or add additional verification steps. User verification systems need to balance security with usability, and sometimes security requirements force you to choose between a feature and keeping user data safe, and keeping data safe has to win every time.

When Users Won't Grant Permissions

An app might be technically perfect but if users refuse to grant the permissions it needs then the whole thing falls apart. Location-based apps are particularly vulnerable to this problem because users have become more cautious about granting location access after years of apps abusing it for advertising purposes. A retail app wanted to send notifications when users walked past their stores, which required always-on background location access. When we tested this with real users, over 80% of them denied the permission request because they didn't trust the app not to track their movements constantly.

The best designed feature in the world is worthless if users won't grant the permissions needed to make it work, and permission requests have become one of the biggest conversion killers in mobile apps.

Camera and microphone access face similar trust issues. A language learning app wanted to analyse pronunciation by recording short audio clips, but many users reflexively deny microphone access because they're worried about being recorded without their knowledge. Concerns about phone listening have made users increasingly wary of granting microphone permissions. Contact access requests get denied by users who don't want apps trawling through their personal relationships. Photo library access requests now need to explain exactly which photos you want and why, and users are right to be sceptical. You can build the most sophisticated features in the world but if asking for permissions scares users away then those features might as well not exist.

Permission Request Timing

iOS and Android both show permission dialogs at the moment you first try to use a protected feature, which means your app gets one chance to explain why it needs access before users make their decision. If they deny the permission then they have to manually go into settings to change it later, which almost nobody does. A meditation app wanted to access the user's heart rate data from their Apple Watch to provide personalised relaxation exercises, but they asked for health data access on the first app launch before users had even seen what the app could do. Nearly all users denied the request because they had no context for why it was needed. The feature became technically impossible to use not because of coding limitations but because of poor UX decisions around permission requests.

Building Within Real Constraints

After a decade of building apps I've learned that the most successful projects are the ones that work with platform limitations rather than fighting against them. This means having honest conversations early in the project about what's actually possible, before designs get finalised and budgets get committed. It means pushing back when a feature request would require capabilities that don't exist yet or would create such a poor user experience that nobody would use it anyway. The apps that succeed are the ones that find creative solutions within the boundaries that exist, not the ones that pretend those boundaries don't matter.

Technical impossibility isn't always permanent though. Features that couldn't be built five years ago are routine now, and capabilities that seem impossible today might become standard once the next generation of mobile hardware arrives or once Apple and Google decide to open up new APIs. The dating app with the variable vibration feature might be possible in a future iOS update. That blood test analysis app might run instantly once mobile chips get another few generations faster. Knowing what's impossible now is just as valuable as knowing what's possible, because it helps set realistic expectations and avoid wasting months building something that was never going to work.

If you're planning an app project and need an honest assessment of what's technically feasible, get in touch and we can review your requirements together before you invest time and money in something that might not be possible yet.

Frequently Asked Questions