What happens to your app when Apple releases a new iPhone with capabilities you never planned for? I've watched this play out hundreds of times—apps that worked perfectly suddenly feel outdated, or worse, they break completely because the team never thought about what comes next. And here's the thing, it's not just about keeping up with the latest shiny features; its about making sure your app doesn't become obsolete before you've even recovered your investment.
Creating a mobile experience isn't like designing a website where you can quickly push updates whenever you fancy. You're dealing with actual devices in peoples pockets, different operating systems that update on their own schedule, and users who might still be holding onto phones from five years ago because they work just fine thank you very much. The mobile landscape changes constantly—new screen sizes appear, processors get faster, cameras gain new capabilities, and privacy rules get stricter. Sure, you can't predict everything. But you can design for change itself.
The apps that survive aren't the ones built for today's technology—they're the ones designed to adapt to tomorrow's changes without needing a complete rebuild.
I mean, I've seen brilliant app ideas fail not because the concept was wrong or the execution was poor, but because the team never thought beyond launch day. They designed for the phones people had at that moment, and when things changed (which they always do), the whole thing fell apart. The cost of redesigning? Often more than the original design budget. That's why planning around technology changes isn't some nice-to-have consideration—it's genuinely one of the most important decisions you'll make before crafting a single wireframe. This guide will walk you through exactly how to think about these changes and what you can do to protect your investment.
Right, so here's the thing—phones change because the people making them are in a constant race to be better than their competitors. Apple releases a new iPhone with a fancy camera system, then Samsung needs to respond with something even more impressive. Its like a never-ending cycle that's been going on since the first smartphones appeared, and honestly? It doesn't show any signs of slowing down.
But there's more to it than just competition. Users genuinely want their phones to do more things. They want better cameras for sharing moments on social media, faster processors for gaming, longer battery life because nobody wants to carry a charger everywhere. Phone manufacturers are responding to real demands—not just making changes for the sake of it. Well, most of the time anyway...
When we talk about phone changes, we're really talking about a few key areas that affect how experiences need to be designed. The hardware improvements come thick and fast; new screen sizes, different camera setups, various sensor types (like face recognition or fingerprint scanners), and processing power that keeps getting better. Then you've got the software side—operating system updates that happen every year like clockwork, new programming features for developers, and changes to how apps are allowed to access things like your location or contacts.
Here are the main areas where phones keep evolving:
The tricky bit? All these changes happen at different speeds across different manufacturers. Android phones from various companies update at their own pace, whilst Apple controls both the hardware and software for iPhones—which means they can coordinate changes more tightly. This creates a fragmented landscape where your experience might need to work on a phone from three years ago sitting next to the latest flagship device, and they could be running completely different versions of their operating systems.
Right, so here's where things get properly tricky—you've got to craft an experience that works well on a tiny budget Android phone from three years ago and also looks brilliant on the latest iPhone with its fancy high-refresh screen. It's a bit mad really, because the difference between these devices can be massive; we're talking about screen sizes that range from under 5 inches to nearly 7 inches, processors that vary wildly in power, and memory that could be anywhere from 2GB to 12GB or more. But here's the thing—your users don't care about your technical challenges. They just want the experience to work.
I've seen too many experiences fail because the team decided to optimise only for the latest devices. Big mistake. Your experience needs to adapt to whatever its running on, and that means making some smart decisions early in the design process. We call this responsive design, and its not just about making things fit on different screen sizes (though thats part of it). Its about understanding that a user on an older device might need lighter images, simpler animations, and more efficient interactions to get the same experience as someone with a flagship phone.
When I'm planning device compatibility, I look at these key differences:
Test your experience on at least three different device types during design: a current flagship model, a mid-range phone from 2-3 years ago, and a budget device. This gives you a realistic picture of how most users will actually experience your design.
One decision you'll need to make early is whether to design for platform-specific experiences (separate approaches for iOS and Android) or create unified experiences that work consistently everywhere. I'm not going to pretend there's a perfect answer here, because honestly, it depends on your specific situation. Unified experiences can save time and resources—sometimes cutting design complexity by 30-40%—but you might need to compromise on platform-specific patterns that users expect. Platform-specific approaches give you maximum control over the user experience, but you're basically designing two experiences instead of one. Most projects these days lean towards unified experiences unless they have very specific platform requirements or need features that work differently across systems.
Here's something that catches a lot of people off guard—when Apple or Google releases a new version of their operating system, your experience doesn't just keep working exactly as it did before. I mean, it usually does... but not always. And even when it does, you might find that certain interactions stop working properly or that your design suddenly looks outdated compared to newer experiences.
Operating system updates bring changes to how experiences interact with the phone itself. New privacy settings might block something your experience was doing before; new design patterns might make your interface look old-fashioned; and sometimes interaction models get completely removed. Its a bit like the rules of the road changing whilst you're driving—you need to adapt quickly or risk problems.
Every major OS update introduces new requirements that experiences must follow. Sometimes these are mandatory right away, other times you get a grace period. But here's the thing—users upgrade their phones fast these days, so waiting too long means your experience might break for a large chunk of your audience. I've seen experiences crash on launch simply because they weren't prepared for a new OS version.
The changes fall into a few main categories: security and privacy requirements (like asking permission to access photos or location), performance improvements that expect experiences to behave differently, new gestures and navigation patterns, and deprecated features that no longer work. That last one is particularly tricky because your experience might have been relying on something that just... disappears.
You cant ignore OS updates, but you also don't need to panic every time one is announced. Most design teams follow this approach:
The reality is that maintaining an experience isn't a one-time cost—it's ongoing. Even if you're not adding new features, you need to keep your experience compatible with the latest operating systems. Budget for this from the start and you wont be caught out when Apple announces iOS 18 or whatever comes next.
So your phone's operating system just got updated and suddenly there's this shiny new feature that does something really cool. Maybe its a fancy camera mode, or a new way to handle notifications, or some AI thing that seems impressive. The question is—should you immediately design it into your experience? I mean, it's tempting, isn't it? But here's the thing: new doesn't always mean necessary.
I've seen plenty of experiences rush to adopt the latest features only to realise that maybe 5% of their users actually have access to them. That's a lot of design time for something most people cant even use yet. The smart approach? Wait and watch. See how quickly users update their devices, check your analytics to understand what OS versions your audience is actually running, and then make an informed decision rather than jumping on every new thing that comes along.
The best features are the ones your users actually need, not just the ones that look impressive in a demo
When you do decide to design something new, craft it in a way that doesn't break the experience for people on older devices. We call this graceful degradation—basically, the experience works perfectly fine without the new feature, but if someone has a newer phone it enhances their experience. Think of it like having a backup plan. Your experience should never crash or feel broken just because someone hasn't updated their phone in a while. I always tell design teams to craft new features with the "what if this fails?" mindset; what happens if the users device doesn't support it? Does the experience still work? Does it still make sense? If the answer is no, you need to rethink your approach before implementing anything.
Right, so you've designed your experience and it looks brilliant on your phone—but here's the thing, your phone is just one device out of thousands. I mean, literally thousands. And each one has its quirks, its own screen size, its own processor speed, its own way of doing things. Testing on real devices is absolutely non-negotiable if you want your experience to succeed in the real world.
When I first started crafting experiences, I made the classic mistake of testing everything on whatever phone I had in my pocket at the time. It worked perfectly for me...and then we launched. The feedback started rolling in almost immediately from users with different devices. Screens that were too small, buttons that didn't quite fit, interactions that crashed on certain phone models. It was a proper mess, honestly.
You can't test on every single device out there—nobody has that kind of budget or time. But you do need to test on a representative sample that covers your user base. Start by looking at your analytics (or industry data if you're just launching) to see what phones people actually use. Usually you'll want at least one high-end phone, one mid-range, and one lower-end device for both iOS and Android.
Screen size matters more than people think. What looks perfect on a massive phone can be completely unusable on a smaller one. Text that's readable on one device becomes tiny and unreadable on another. Buttons that are easy to tap become frustratingly small. You need to physically hold these different devices and use your experience like a real person would.
Simulators are useful for quick checks during design, sure, but they dont give you the full picture. They can't replicate how your experience performs under real-world conditions—things like poor network connectivity, low battery mode, or how the phone heats up during intensive tasks. I've seen experiences that run smoothly on a simulator absolutely chug on actual hardware because the simulator doesn't accurately represent the processing limitations of older devices.
Here's what you should be testing across different devices:
Device testing labs exist for exactly this reason; they let you access hundreds of real devices remotely without buying them all yourself. Services like BrowserStack or AWS Device Farm give you access to actual physical phones in a data centre that you can control through your browser. Its not quite the same as holding the phone in your hand, but its pretty close and way more practical than maintaining your own device library.
And look, I know its tempting to skip thorough testing when you're rushing to launch—but trust me on this one, the time you save now will cost you ten times more in support headaches and bad reviews later. Every hour spent testing across different devices is an investment in your experience's reputation and success.
This is where things get a bit tricky—and honestly, it's one of the questions I get asked most often. How do you plan for something that hasn't even been invented yet? The short answer is you cant completely. But here's the thing, you can design your experience in a way that makes adapting to new technologies much easier when they do arrive.
I've watched AR go from a gimmick to a genuine tool, machine learning shift from server-side processing to on-device capabilities, and 5G change how we think about real-time data. Each time a new technology emerges, some experiences are ready to take advantage whilst others need a complete redesign. The difference? How their foundation was structured from the start.
The best approach is to keep your experience's core functions separate from the specific technologies you're using today. Think of it like designing with blocks rather than gluing everything together permanently. When a new feature becomes available—lets say improved voice recognition or better camera capabilities—you want to be able to swap out just that piece without touching everything else. Its called modular design and it's saved me countless hours of rework over the years.
Keep an eye on what Apple and Google are talking about at their developer conferences each year; they usually hint at whats coming 12-18 months before it becomes mainstream. Pay attention to things like improved sensors in phones, new ways for experiences to communicate with each other, and changes in how operating systems handle privacy and security.
Set aside a small budget—maybe 5-10% of your design costs—for experimentation with new technologies. This lets you explore emerging features without risking your main experience functionality, so when something becomes popular you're already familiar with how it works.
I always tell clients to avoid designing around one specific technology or platform feature. Instead, create a flexible foundation that can adapt when new options become available. This might mean your initial design takes slightly longer, but you'll save so much time and resources when the next big technology shift happens—and it will happen.
One practical thing you can do is design your experience's interface to accommodate new interaction methods. We've gone from buttons to gestures to voice commands, and there's definitely more coming. Craft your navigation and core actions in ways that aren't tied to just one input method.
| Technology Area | What to Watch For | How to Prepare |
|---|---|---|
| AI and Machine Learning | On-device processing getting faster and more capable | Keep data collection and processing logic separate so you can switch methods easily |
| Sensors and Hardware | New sensors being added to phones (temperature, air quality, etc) | Design your experience to gracefully handle sensors that might not exist yet |
| Connectivity | Faster networks enabling real-time features | Design your experience to work offline first, then enhance with connectivity |
| Privacy and Security | Stricter controls over data access and tracking | Minimise data collection now and be transparent about what you use |
The reality is that some of the technologies that will matter most in five years time probably dont exist yet. But if you design your experience with flexibility in mind, you wont need to start from scratch when they arrive. You'll be able to adapt, improve, and stay relevant without breaking everything thats already working well for your users.
This is honestly one of the toughest decisions you'll face as an experience owner. I mean, nobody wants to leave users behind, but at some point supporting really old devices starts holding your entire experience back—it limits what features you can design, slows down your design team, and increases the chance of bugs and problems across the board.
The truth is there's no magic answer here, but I can share what tends to work based on years of making these calls. You want to look at your actual user data first. If only 2% of your users are on a device thats more than five years old, the maths gets pretty straightforward. Supporting that tiny group might be costing you 20% of your design time and budget, which is just not sustainable. But here's the thing—if that 2% represents your most loyal or highest-value customers? Well, that changes everything doesn't it.
Pull up your analytics and look at these numbers carefully:
Generally speaking, once a device version drops below 5% of your user base and its more than three OS versions behind current releases, its probably time to consider dropping support. Apple makes this easier because their ecosystem updates pretty uniformly;Android is trickier because theres so much fragmentation. You see, some Android users stick with older versions for years, not because they want to but because their device manufacturer stopped providing updates.
When you do decide to drop support for older devices, give your users plenty of warning—at least 3 months notice through in-app messages and emails. Explain why you're making this change and what options they have. Being transparent about this stuff goes a long way towards maintaining trust, even with users who might feel left behind.
Here's the reality—your users aren't all running the latest iPhone or the newest Samsung Galaxy. Actually, most of them probably aren't. I see this mistake all the time; designers get excited about some new feature and craft their entire experience around it, only to realise that 60% of their target audience can't even use it properly. Its a bit mad really.
The trick is to look at your actual user data. If you're designing a new experience, research who you're designing for—what devices do they typically use? What operating system versions are most common in your target demographic? A fintech experience aimed at business professionals will have very different device distribution than a casual game targeting teenagers. And these differences matter more than you'd think.
The best approach is to design a solid core experience that works everywhere, then layer on enhanced features for users with newer devices
I always tell clients to design their minimum viable experience to work on devices from about three years ago as a baseline. This doesn't mean your experience needs to look dated or perform poorly—it just means you're being smart about what features are truly necessary versus what's nice to have. You can still use new capabilities and interactions, but make sure the core functionality degrades gracefully on older hardware.
Think of it like this: everyone gets a good experience, but users with newer devices get an even better one. Maybe that means smoother animations, higher quality images, or access to features like AR that require specific hardware. The key is making sure nobody feels left out or gets a broken experience just because their phone is a few years old. Test on older devices regularly—not just the shiny new ones sitting on your desk. You'll be surprised what you discover.
Look—planning for changing phone technologies isn't about predicting the future or having some magic crystal ball in your office. Its about crafting flexibility into how you think about experience design from day one. I mean, you can't know what Apple or Google will announce next month, but you can create a design approach that lets you adapt when those announcements inevitably come.
The experiences that survive long-term are the ones crafted with change in mind; they use design patterns that can flex when new screen sizes appear, they keep their architecture modular so new features can slot in without breaking everything, and they maintain a testing process that catches problems before users do. But here's the thing—you also need to know when to hold back. Not every new technology deserves your attention right away, and honestly, jumping on every trend is a fast way to waste your budget.
What really matters is understanding your users and what devices they actually have in their hands right now. Sure, that new foldable phone feature looks interesting, but if 0.5% of your users own one... well, you've got better places to invest your time. The balance between supporting old devices and embracing new capabilities is where most experiences either thrive or struggle, and there's no universal answer—it depends entirely on your specific user base.
At the end of the day, successful experiences aren't the ones that chase every shiny new technology. They're the ones that make smart, informed decisions about when to move forward and when to stay put. Keep your users at the centre of those decisions, design with flexibility, test thoroughly, and you'll navigate whatever changes come next without losing sleep over it. The technology will keep changing—that's guaranteed—but your approach to handling that change can stay solid. Whether you need the experience design, user research, and technical roadmap that turns psychology into reality or you're building with freelancers, in-house teams, or AI—it all starts with experiences designed by experts. Let's craft your experience foundation.