B2B Digital Insights – September 2026

Hi & hello!

Last time I wrote about the difference between an app and a product, and how Apple moved the bar from "it doesn't break the rules" to "does it deserve to exist at all." This issue picks up right where that left off. Because it's not just Apple raising the bar. Everyone is.

TL;DR:‍

• The foldable iPhone brings a new canvas that your app either uses cleverly or just sits on, lost.
• The EU Cyber Resilience Act turns security into a legal obligation, with a deadline that's already running.
• On Android, Google is closing the door on anonymous sideloading.

Three different things carrying one message: "it works" is no longer enough. What matters more and more is whether someone stands behind the product (and who), and whether it can earn its place.

And to close, something straight from us: we wrote a case study on how we used AI to speed up product listing for Lékárna.cz by 40%. Because a raised bar isn't only about rules and risks. It's also about where technology actually makes a company money.

The iPhone Duo (on sale from October 23) brings a display unlike anything an iPhone has had before. Unfolded, it comes close to the size of an iPad mini and is almost square. For the user, it's not a phone and a tablet stuck together, but a single screen that grows as you unfold it, because both displays have essentially the same aspect ratio.

For you as a product owner, it's a new surface that your app needs to be able to do something with.

What it means in practice

• Apps built on native SDKs adapt largely on their own. What proved true with Liquid Glass holds here too: the system does most of the work for you. BUT only if you actually stand on those native foundations.
• Apps won't change by themselves just because a user opens them. To handle the unfolded space, they have to be built for the new iOS. Until then they'll run in their original format, quite possibly on just half the display, with empty space around them.
• The difference between "the app runs" and "the app uses the space" is exactly the difference between an app and a product I keep writing about here.

Who it'll be great for

• Apps where it makes sense to see the list and the detail at once. Mail, notes, tickets, CRM, readers. The classic split view (list on the left, content on the right) is exactly what the unfolded space offers.
• Information-dense apps. Dashboards, weather, finance, analytics. More room means more context without constantly switching screens.
• Productivity and multitasking in general.

Where I wouldn't rush, on the other hand‍

• Single-purpose apps with one action (one form, one button). Unfolding gets you no value, just empty space.
• Apps whose value is in a quick open – do – close. Optimizing for a large canvas is then an investment with no return.
• Games and fully custom UI that don't stand on system components. Nothing adapts for free there, and it's always extra work.

And one strategic tip that's easy to miss

The foldable iPhone isn't the only reason to think about an adaptive layout. Once you prepare your app to use more space, you open doors elsewhere too: to iPad, and above all to Mac. An adaptive layout is a kind of stepping stone: an app that already knows the "big canvas" can be brought to macOS almost for free. One investment, three platforms.

💡 What this means for your business

Native SDKs = adapting to the foldable and to Mac will be a matter of targeted tweaks, not a rewrite. Custom or hybrid solutions = count on extra work and decide whether it's worth it. The redesign for the foldable itself can wait. Weigh how many of your users actually have such a device and time the big investment accordingly.

The main takeaway? An adaptive layout pays off even without the foldable. Treat it as preparation for more platforms, not a cost because of one phone.

Fairly quietly, something kicked in that will affect most companies. The reporting obligation under the EU Cyber Resilience Act (CRA) takes effect on September 11, 2026, more than a year before the regulation's general applicability on December 11, 2027.

What does that mean concretely? From September 11, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents. A first warning within 24 hours of becoming aware, a full notification within 72 hours. You report to ENISA and your national CSIRT through a single platform.

And now the trap most people miss. Plenty of companies think the obligation applies only to products placed on the market after September 11. That's wrong. The regulation extends it to every product with digital elements that's already on the EU market. A router from 2022, firmware from the pandemic days, an app you shipped three years ago and have "just" been running ever since.

Source: European Comission – CRA reporting · HeroDevs: CRA Reporting Obligations Start September 2026

At June's mDevCamp, cybersecurity united the whole room (you can already find recordings of all the talks on YouTube). This is exactly why. It's stopped being a technical nice-to-have somewhere at the back of the backlog. It's a legal obligation with a deadline that's already running.

💡 What this means for your business

Find out* whether your products fall under the CRA's scope and who owns the reporting process at your company. When an actively exploited vulnerability shows up, 24 hours goes fast. You effectively need a component-level SBOM overview right now. Without it, you simply won't meet the 24-hour reporting obligation.

*Where to check whether you fall under the CRA

1. Where does your software run? The CRA's scope centers on products with digital elements (PDEs). If the code runs on the end user's device (mobile apps, desktop clients, browser plugins, firmware), it falls under the CRA. Pure cloud services (SaaS accessible exclusively through a browser) are regulated as services, and so are governed primarily by the NIS2 Directive.
2. Go through the Commission's official scope guidance. Or use a tool from an independent community and expert initiative (e.g. cyberresilienceact.eu) which draws on the official document and translates it into plain language.
3. Self-assessment for smaller companies. In July 2026, ENISA published a document and assessment calculator, the SME Cyber Resilience Maturity Assessment Model, which serves small and medium-sized companies as a practical questionnaire for gauging their maturity and gaps against CRA requirements.
4. Where to report. Submit reporting data through the centralized CRA Single Reporting Platform (SRP) interface, operated by ENISA. The platform automatically forwards reports to the national CSIRT in the manufacturer's country of establishment (in the Czech Republic, in cooperation with NÚKIB).

From late 2026, Google will require every developer to verify their identity before their app can be installed on a certified Android device, even when it's distributed outside Google Play. Unverified apps will be completely blocked. Enforcement starts on September 30, 2026 in Brazil, Indonesia, Singapore, and Thailand, and will expand globally in 2027.

It's not a check on the app's content, but on who stands behind it. Developers will have to provide their legal name, address, email, and phone number, which, by the way, may push independent developers to register as a company for the sake of their privacy.

In plain English:

Installing an app via APK or from alternative sources will only work if the developer is registered in the Android Developer Console, and every distributed app has to be signed by that developer. So it really won't be anonymous anymore: any malware can be traced back to a specific developer. Google defends it with numbers: according to its own research, sideloaded sources carry 50× more malware than Google Play. But the other side of the same coin is impossible to overlook. It also gives Google significantly more control over what runs on every single device.

And we're back to what I keep writing about. In the same year, both Apple and Google are tightening who can publish what, and keep it alive. The bar is shifting from "it works" to "it belongs here and someone is responsible for it." Exactly the difference between an app and a product.

Source: Android Developers Blog – developer verification · TechCrunch: Google will require developer verification

💡 What this means for your business

If you distribute anything outside the Play Store (employee apps, customer apps, direct APKs, MDM deployments, alternative stores), start verification now. You don't want to be dealing with registration and identity verification the moment enforcement reaches your market.

The global rollout isn't until 2027, so there's time to prepare. But not forever, and the first four countries show the direction.

Using AI, we sped up product listing by 40%. For the company, that's a huge saving across many layers, ones that genuinely change the whole business. What that 40% really means:

• ‍Time and capacity. The same team can list more products. OR gets freed up for work that needs judgment, not routine. I don't like "we'll save on people"; the perspective that matters far more to me is: "people do more valuable things than retyping parameters."‍
• Costs. A lower unit cost per listed product. For a large e-shop with thousands of new items a year, that adds up nicely.‍
• Time-to-market. This can often bring a company the biggest money. A product that's online days earlier starts earning earlier. For seasonal goods or new releases, a huge head start.‍
• Consistency and scalability. Listing quality doesn't swing depending on who's doing it. And when a big surge comes (an import, a new line, a product-range acquisition, you name it), the company handles it without hiring and training in bursts.

For me (and for us at Futured), that's the whole difference between AI "for show" and AI that genuinely helps the business.

Read the case study on our work for Lékárna.cz.

And to close, some good news: we're among the winners of the Clutch Global Awards.

We rank among the 15 best companies in the world for Kotlin development. The award is nice. But what pleases us most is what exactly it came for. Because it rests on precisely what this whole newsletter is about.

‍