News from the market, opinion pieces and Indiespring updates.
AI tooling is everywhere right now, and its promise is compelling. But where does the hype end and the risk begin?
A client suggested we explore using AI tools as part of our design workflow. It wasn’t a big strategic shift at the time, more a case of staying open to how we could work more efficiently. Since then, it’s become a more deliberate part of how our design team operates.
An app has been running successfully for several years. Customers are using it, revenue is coming in and the business is focused on growth. Meanwhile, the technology underneath gradually falls behind. Dependencies become outdated, platform requirements evolve and knowledge of how the system works becomes increasingly fragmented.
In the fiercely competitive world of entertainment apps, few have embraced digital accessibility as wholeheartedly as Netflix.
We speak to CTOs and app owners in this position all the time. They’re not in crisis. There’s no live incident. The board isn’t demanding immediate answers. But at the same time, they know they’re carrying responsibility for something commercially critical without a structured, current view of its health.
In sectors like insurance and telematics, strong testing is crucial. The data generated through an app like IMS influences pricing decisions, claims assessments, driver risk analysis and, in some cases, legal disputes. If organisations can’t fully trust the quality and consistency of that data across devices and operating conditions, confidence in the wider platform starts to weaken too.
This question comes up in every leadership room eventually, and it came up at one of our recent events. It’s usually asked after a painful release. Or maybe a production incident, or a period where things technically “ship”, but don’t quite hold up. Then, the question is almost always framed as a motivation problem. When that often isn’t the issue at all.
The headline is this: Indiespring as a collective is excited about AI, but fairly balanced in their approaches. We’re not jumping into it doing every task for us, but there were certainly some useful (and some sillier) use cases brought to the table.
AI can help you create software remarkably quickly. It doesn’t remove the responsibilities around changes, ownership and bugs once the software becomes important. If anything - it means they require greater care.
The truth is, you need clarity before you can do anything - whether your team is big or small. A "problem app" usually gets labelled as a technical issue. Legacy code, fragile infrastructure, missing documentation... sometimes all of these things are at play, sometimes it's just one issue.
When IMS' mobile apps started failing, crash rates were rising. We stepped in to stabilise and brought structure back to the platform.
We all know the pain of a poor app review, and it's a heavy one. Rectifying the problem can cost time, stall releases, drain internal resources, damage user trust, and (as if that wasn't enough) risk revenue.
You’ve invested time into something new, whether it’s a seasonal feature or something you’d like to see stick around. Building features is costly. It takes time, resources and money - you want it to work.
Mobile platforms aren't static. Apple and Google continuously evolve their policies, introduce new technical requirements and respond to changing legislation across international markets. New rules governing subscriptions, downloadable content, user verification, privacy, age restrictions and regional compliance are introduced every year, often with relatively short implementation windows.
ES File Explorer had over 100 million downloads. Then Google found out what was happening in the background and removed it.
AppGratis had raised $13.5 million in funding and hit 12 million iOS users. Then Apple pulled it from the App Store without warning.
Manomio had licences, legal games, and Apple's approval. But a hidden BASIC interpreter triggered the takedown.
What do the team at an app agency actually get up to behind closed doors? Honestly, quite a lot. Most days, we’re deep in delivery mode. Solving technical problems, recovering struggling apps, untangling ageing codebases and helping clients move projects forward without throwing everything away and starting again. Still, agency life is rarely just tickets, stand-ups and release cycles.
Every feature needs building twice. Every release requires additional coordination. Testing becomes more complicated. Small differences between platforms create inconsistencies in the customer experience, while development teams spend more time maintaining parity than improving the product itself.
Device fragmentation is a persistent and destructive problem. With countless screen sizes and OS versions, your app behaving differently is high risk.
App owners rarely think about device fragmentation as a serious operational issue - until releases begin behaving differently in production than they did during testing.
Device fragmentation happens when your app performs inconsistently across different hardware configurations and operating systems.
We're not just designing for phones anymore. With new foldables, wearables and hybrids entering the market, ensuring compatibility is critical.
Coach USA came to us with a problem we see time and time again in transport: a mobile app that simply wasn't fit for purpose.
API changes don't sound dramatic, but they're one of the most common reasons we see stable apps start to fail.
With older application frameworks using lots of plugins, an SDK update can have a significant impact on app stability, how do we manage this?
While the allure of a shiny new system can be tempting, it's essential not to overlook the benefits of brownfield development.
When people think about app maintenance, they often think about bugs, crashes or releasing new features. In our experience, that's rarely the biggest problem.
You've done the builds, pushed the updates and your feature set is looking strong. But when the user count spikes, something gives.
Once your app is in the hands of real users, you start hearing things you didn't expect. You've lost visibility.
Many operators already have digital ticketing in place, but it doesn't feel like a success story. The app exists, tickets can be purchased… but adoption is lower than expected.
Operators are being asked to do more with less. Costs are rising, and passenger expectations are becoming shaped by seamless digital experiences in other sectors.
In reality, small weaknesses at the bus door shape revenue, cost and behaviour every day. When validation is slow, unclear or easy to bypass, the impact doesn't show up as a single failure. It shows up as a thousand small compromises.
Apps are often designed around stable conditions, then gradually adapted to handle real-world complexity. Over time, that gap between “how it should work” and “how it actually works” starts to widen. Connectivity is usually right at the centre of it.
If your travel app gives someone the wrong information, it knocks confidence in your brand. Telematics can help.
Most transport operators don't have digital ticketing in place, and the hesitation is understandable. Ticketing sits at the centre of the operation.
In transport, the appetite for going digital is rarely the problem. Most operators know they need to modernise.
It would be pretty dreamy if AI could just test everything for us, wouldn't it? On the surface, AI-powered QA tools tick all the boxes.
That's something we hear a lot from teams dealing with brownfield apps that have become more hassle than help.
Every December, the same conversation! A push to get that final update out before everyone clocks off.
We often hear people saying they want one QA tool that does it all. The trouble is, that tool just doesn't exist.
AI makes everything look the same. If you've spent any time in design circles lately, you've probably heard that sentiment.
You had to move fast. But now, months later, you're still building on top of early code. It wasn't meant to last, and it's starting to show.
If your app's performance keeps dipping under pressure, it might be time to look at how your codebase handles large tasks.
Outsourcing gets a bad rap. But when approached properly, it's not a risk. It's a strategic advantage.
Accessibility is one of those things many teams put off. But it's not just a user experience issue. It's a business liability.
We know we need to go mobile, but we don't even know where to start. React Native offers momentum without the mess.
Reflectly is a journal utilizing artificial intelligence to help you structure and reflect upon your daily thoughts and problems.
How much does it cost to build an app? Unfortunately without exploring your requirements in detail, it's often difficult to give even a rough pricing indication.
You might think you're in control. But if you've outsourced any part of your mobile app, there's a chance you're not.
In an era where data breaches and regulatory scrutiny are increasingly common, ensuring the security and compliance of business operations is paramount.
One of the most daunting hurdles businesses face is app store rejection. The answer could be as simple as this: you're not implementing proactive testing.
Mobile device fragmentation occurs when some mobile users are running older versions of an operating system while others have updated.
Musi was a well-loved music app with over 66 million downloads. But that didn't stop Apple removing it from their store overnight.
We hear it all the time: We've inherited this code from another team. Taking over inherited code can feel more like damage control than development.
Offshoring app development can look like a smart move on paper. But when your app is built on years of inherited code, those savings rarely hold up.
A single snippet of code shared with an agency will never be enough to diagnose a broken app. You need the full picture.
You've ticked all the QA boxes. But it still crashes once it's in users' hands. Emulators can only tell you so much.