B2B Digital Insights – July 2026

Anyone can generate an app with AI these days. But building a product that's actually worth something is a whole different discipline.

Apple has just carved that into the App Store rules. At mDevCamp, it showed up in the conversations about security. And on two of our projects, I'll show you what that difference looks like in practice.

Apple has said that variant no. 534 of the same app doesn't belong on the store. THANK GOODNESS. Because with AI, those variants are multiplying faster than ever.

In the new App Review Guidelines, section 4.3 changed almost unnoticed. Apple now says it won't accept apps that are "indistinguishable from what is already commonly available," and that opportunistically creating variants of existing categories "degrades discoverability, reduces quality, and harms both users and developers."

And it's going after the existing ones too. An app that isn't maintained or doesn't attract customers can get pulled from the store.

In plain English: anyone can generate an app today. But getting it on the store, and keeping it there, is getting harder and harder. And nobody benefits from the flood, least of all the users. This is good for… no one.

To be clear, Apple isn't taking a shot at AI itself. It talks about clones and unmaintained apps. But vibecoding opened an even faster route to those clones: today, variant no. 534 can be built by someone who isn't a developer at all. One decent prompt and done. I'm exaggerating, but not by much.

And that's exactly what Apple is reacting to. It built a barrier at distribution and started saying out loud that it doesn't want to promote or aggregate things that bring no value. That's a shift. The bar has moved from "it doesn't break the rules" to "does it deserve to exist at all."

To me, that's the difference between an app and a product.

Code is a commodity now. AI spits it out in minutes. The value was never in getting something to compile. It's in knowing why it should exist, who it's for, and making sure it still works and keeps evolving six months later.

I stand by this: not everyone needs an app. And right now, more than ever, it's worth talking about why yours should exist in the first place.

Source: Apple App Review Guidelines · MacRumors: Stricter Rules for Low-Quality Apps

💡 What this means for your business

If you have an app on the App Store that hasn't seen an update in a while, now is the time to ask: does it have a clear roadmap, or is it just "sitting on the store"? The new wording gives Apple a tool to remove unmaintained apps.

The newsletter is prepared by Lukáš Strnadel, founder and CEO of Futured. Want it delivered straight to your inbox? Subscribe.

What does an app that deserves its place on the store look like?

Take iROZHLAS, a project close to our hearts that we've been developing since 2021. We recently shipped version 6.0.0, which brought support for Liquid Glass, the new iOS 26 design system, along with the move to Swift 6. And because the adoption on a five-year-old codebase went surprisingly smoothly, we wrote a blog post about it.

The gist: adopting Liquid Glass meant dozens of targeted tweaks, no rewrite, no massive refactoring. The system delivers most of the changes on its own. But only if the app is built on native SDKs, which is something we insist on at Futured.

On top of that, our developer Jakub attended the invite-only Meet with Apple meetup in Warsaw, where companies shared their adoption experiences. The message was clear: users expect the change, and they embrace it.

💡 What this means for your business

Looks age faster than you'd think. Liquid Glass has been out for over half a year, users have gotten used to it, and apps without it are starting to feel dated. If your app is built on system SDKs, this is a matter of targeted tweaks, not weeks of refactoring. And if it can't adopt it in a reasonable time, that's a signal of deeper architectural problems. Which is valuable information in itself.

This year's mDevCamp, which we organized, brought together over 30 speakers from across Europe. The talks covered iOS, Android, Flutter, and Kotlin Multiplatform. AI was (unsurprisingly) everywhere. After all, the whole event closed with the Beyond the Prompt panel on what AI actually costs companies, and what's actually expensive in a world where almost anyone can generate code.

But the topic that ultimately united the whole room across platforms was cybersecurity.

And it didn't surprise us. We see it in our everyday work with clients: as the pressure for speed grows and vibecoded apps multiply, so do the vulnerabilities. At least wherever the process isn't properly covered by tests and security audits. Security has become the one topic nobody can afford to put off. And yes, it ties back to what I wrote at the start of this issue.

Our Pavel Měsíček, who puts together the mDevCamp program and lineup, sat down for an interview about what he enjoyed this year and what got discussed once the microphones were off. And a big thank you to the community for going all in, year after year.

We've been publishing App News for five years. And now we've taken it a step further.

…to put as much of ourselves into it as possible. Or rather, our expertise. Every issue now comes with our own take: what each piece of news means in practice, where we see opportunities, and where the risks are that are easy to overlook. Strategic recommendations on what to tackle now and what can wait.

It's for people who live and breathe technology but want the business context too. Because the tech news itself is only half the story.

Something we built that we're proud of: KRUH

When I write about the difference between an app and a product, this is exactly the latter. For a central security monitoring provider, we built a platform that coordinates response units in real time. Where every second decides whether the intruder gets away, or whether the damage ends up bigger than it had to be.

The platform, made up of three connected apps communicating in real time, cut the average response time by 30 seconds.

The biggest technical question mark? Prioritizing the severity of each callout. What the user sees as a single button stands on logic that has to be reliable, always. Day or night, no exceptions.

‍