DEV Community: Surya Polavarapu

App Intents, AppFunctions, and the Interface Your Test Suite Has Never Driven

Surya Polavarapu — Thu, 17 Sep 2026 11:45:32 +0000

iOS 27 reached every compatible iPhone on 14 September, and most of the coverage has understandably been about Siri - the new architecture, the conversational mode, the access to personal context. Underneath that consumer story is a change in who can reach into your app, and most development and testing teams haven't caught up with it.

The side doors are not new

The UI is the storefront: browse, add to cart, check out, in that order. Apple has been opening side doors into that shop for a decade.

SiriKit (2016) was a voice side door, but only for a few Apple-approved jobs: send a message, request a ride, start a workout, pay someone. Uber did not have to invent a general “Siri API.” It implemented “book a ride,” and Siri knew how to ask for pickup and destination. A person could complete a core action without opening the app. That is already a second interface.

Shortcuts (2018) was a recipe side door. A user, or your team, could save a sequence: “log this workout,” “order my usual,” “set Do Not Disturb and open Maps.” Tapping the shortcut, or saying “Hey Siri, run Morning,” ran those steps without walking the screens. QA rarely treated Shortcuts as a first-class surface, but customers were already using the app that way.

App Intents (2022) was Apple replacing those one-off side doors with a catalog of actions the system can call: Siri, Spotlight search, the Action Button, widgets, Shortcuts. “Create event,” “play this playlist,” “show my order.” Same idea as publishing a short list of APIs, except the callers are Apple’s system features instead of a website.

So the surface is old. What arrived this year is a far more capable visitor using it.

What changed is the visitor

Siri AI doesn't need the ten phrases you published. It reads the catalogue, looks at what's on screen and at personal context, forms a plan from a sentence, and calls actions in whatever order that plan requires.

Apple has been promising this visitor since WWDC 2024, where personal context, onscreen awareness and App Intents-powered in-app actions were announced together. The features were officially delayed in March 2025, slipped through that year and into early 2026, and landed on phones in September. The long gap matters here, because it means many teams filed App Intents under "did that in 2022" and stopped thinking about it. Three things are true now that weren't then.

Discovery flipped. Previously a user had to know a Shortcut existed or say a phrase you'd published. Now the assistant finds the action. Anything in the catalogue is in play — including intents someone added years ago for a Shortcuts integration and nobody has looked at since.

Sequence is no longer your design. A Shortcut runs the order you wrote. A screen flow only offers the next legal step. An assistant composing "move lunch, tell the attendees, book a car" calls whatever functions it decides it needs, in combinations no screen ever permitted. Every invariant a team relies on because "the user can't get there from here" needs rechecking.

Absence became a product problem. In 2022, skipping App Intents made you weaker in Shortcuts and the app still worked. Apple's documentation now describes SiriKit, Intents and IntentsUI as providing legacy support for existing interactions and points developers to App Intents for modern integration. SiriKit still covers its old domains; it does not carry you onto the new surface. Users will ask Siri to do the thing, Siri will do it in a competitor's app, and nothing will appear in your crash reports.

Google made the same move this year. Android 17 expanded AppFunctions, described in the release announcement as contributing an app's capabilities as orchestratable tools for Android MCP, the on-device equivalent of the Model Context Protocol. MCP is how agents call tools on servers; Google has pointed the same idea at the apps installed on a phone. Gemini integration is still in private preview with trusted testers, so Android teams have more runway — but two platforms converged on one pattern inside a single cycle. That's why 2026 is the story and 2022 wasn't.

Why this lands on QA

An App Intent or an AppFunction is a function signature: typed parameters, entity types it accepts and returns, discoverability settings, and a policy governing what authentication is required before it runs. Nothing a UI test depends on is present on that path — no screen to read, no element to tap, no navigation sequence quietly establishing state along the way.

Beyond the ordering problem above, three properties make this hard to verify.

Parameter values arrive from an interpreter. A UI constrains its own input: a date picker only emits a valid date, a dropdown only emits a member of a known set. An intent parameter is populated by a model reading a sentence, which makes "next Friday," spoken by someone in a timezone the app was never tested in, a live input to a function whose date picker never had to handle it.

Authentication and confirmation moved off the screen. When the action executes outside your UI, so does the moment where the user agrees to it. Apple exposes settings that govern this, and getting them wrong doesn't fail loudly — it means something happens the user never clearly consented to, a defect that surfaces in a review rather than in CI.

The caller changes without your code changing. This one has no precedent. A UI test pins a contract between your code and a human whose behaviour is stable. An intent's caller is a model updated on the platform's schedule. The same function, with the same tests green, can start being invoked differently after an OS update you didn't ship.

The tooling exists. Its scope is the issue.

Worth being precise, because the gap isn't an absence of tools. Apple shipped App Intents Testing alongside iOS 27 — an XCTest framework that runs intents, entities, enums and queries out of process, the way Siri and Shortcuts perform them, with type-erased APIs letting a test reference an intent by name and set its parameters without linking against the app target. It covers onscreen context through view annotations. On Android, adb shell cmd app_function list-app-functions enumerates what a package registers, execute-app-function invokes one with a JSON parameter string, and the AppFunctions Testing Agent goes further, letting you observe behaviour in a conversational flow.

These are good tools and anyone publishing intents should be using them. What they verify is that a function does what it claims when called. That layer is well served.

What remains unverified is the system the function now sits inside: whether a model read an ambiguous utterance the way you expected, whether an agent composing across three apps called your functions in an order your data model survives, whether any of that held after the platform updated the assistant underneath you. Those are properties of an interaction rather than of a function, and the discipline for testing them hasn't formed yet. Security teams recognised the shape early — tooling that inventories published intents and audits what they expose appeared quickly, because a new caller with access to an app's data and actions reads immediately as a threat model worth mapping. The quality equivalent is further behind.

Where a team can start

Inventory first. List every intent or function the app publishes, and record its parameters, its authentication policy, and what data it can reach. That list is usually longer than expected, for the reason above: intents accumulate, and the ones added for Shortcuts in 2022 are now exposed to a caller nobody anticipated.

Then use the platform tools for what they're good at, and be explicit about what sits outside them. Boundary cases on every parameter. Invocation from states the UI cannot produce. Confirmation behaviour when the app isn't in the foreground. Behaviour when the underlying data has changed between the agent reading it and acting on it. Past that, a team is making judgement calls without a safety net — and knowing that is better than assuming a green suite covers it.

The doors have been there for years. What's new is that something on the other side can now read the whole catalogue and decide for itself which ones to open.

We've spent years at QApilot building tests that describe a goal rather than a sequence of taps, because the surface underneath keeps moving. An assistant calling your app is a similar problem arriving from a new direction and needs to be addressed.

Liquid Glass Is Here: Testing Considerations for Developers and Quality Engineers

Surya Polavarapu — Thu, 03 Sep 2026 11:12:57 +0000

Liquid Glass is Apple's new design language announced at WWDC 2025 & shipped with iOS 26. Apple calls it their "broadest software design update ever" - the most significant visual overhaul since iOS 7 moved from skeuomorphism to flat design in 2013.

All UI elements like tab bars, buttons, switches, sliders - are now translucent and dynamic. They mimic real glass: they refract light, reflect their surroundings, and change appearance based on what's underneath them. Scroll a page and the navigation bar shifts in real time based on the content beneath it. The same button can look completely different against a dark wallpaper vs a light one.

What happened when it reached real devices?

In beta builds, users reported a lot of functional rather than purely aesthetic problems: 

Notifications on the lock screen were barely visible against transparent background. The Control Centre blended into whatever was behind it, making toggles hard to find
Navigation became unpredictable: Safari's forward button appears and disappears depending on context, search bars moved, and back buttons sometimes vanished entirely.
Touch targets got smaller and more crowded - tab bars were squeezed, spacing reduced
Contrast was insufficient for anyone with even mild vision difficulties - many users immediately turned on "Reduce Transparency" and "Increase Contrast" in accessibility settings just to make their phones usable

The Nielsen Norman Group published a detailed analysis in March 2026 that was unusually pointed for a publication that typically stays measured: the interface is restless, less predictable, less legible, and constantly pulling focus rather than supporting seamless access to content. They specifically called out that Apple has crowded and shrunk touch targets, seemingly tossing out the long-standing guideline of at least 0.4cm between targets and 1cm × 1cm tap areas.

Apple eventually responded in iOS 26.1 beta 4 by introducing a "Tinted" setting that tones down the transparency - a soft reversal of one of its most disputed visual decisions. The community largely received this as an acknowledgement that the initial implementation went too far.

The Mandate

Apple understood that a change this large needed a runway. So when iOS 26 shipped, they built an opt-out into Xcode, but requires all iOS apps to fully support the Liquid Glass design system by September 2026. 
This isn't optional. The iOS 27 beta, released at WWDC June 2026, confirms that UIDesignRequiresCompatibility , the flag teams used to opt out of Liquid Glass - is ignored when building with the iOS 27 SDK. Teams that used this flag to defer the migration now have regressions hidden in their code that QA never considered. Those regressions will all surface simultaneously when they adopt the new SDK.

Critical Considerations

The most important action for any team still using the compatibility flag is to remove the flag, build against the iOS 26 SDK, run the app on a physical device, and do a full regression pass now - before Xcode 27 is made mandatory, before a bug fix release forces the issue. 
Visual testing breaks down. Tools comparing pixel to pixel will flag everything during regression and the actual failures would get buried in the noise. Liquid Glass elements render differently depending on what's behind them - wallpaper, content, dark vs light mode, even time of day in some cases. There is no stable baseline to compare against. The same screen, in the same device can produce a different visual output on every run. Pixel-diffing tools flag everything as a regression.

Touch target testing becomes necessary. The NN/g piece documents that Apple went against its own guidelines on tap target sizing. For apps adapting to Liquid Glass, elements that previously passed accessibility and tap-size checks may no longer. Every interactive element in a migrated app needs re-verification - not just against design specs but against real device behaviour.

The hidden regression problem. Teams that deferred Liquid Glass via the compatibility flag now have untested code paths. The single most important action for these teams: remove the compatibility flag, build with Xcode 26 against a physical iOS 26 device, and run a full regression pass - discover the regressions at your own pace rather than under Xcode 27 deadline pressure. Most haven't done this yet.

What testing against Liquid Glass actually requires

When Liquid Glass migration shifts the position of a tab bar item, reformats a navigation element, or resizes a button, test steps that relied on the previous element location or identifier fail. Not because the feature broke but because the anchor the test was using no longer sits in the same place. Many elements shifting simultaneously, across many screens, where the alternative is manually triaging and rewriting every broken test step by hand.

At QApilot, our AI native system works through a resolution hierarchy - accessibility identifiers, relative positioning, visible text, and a vision-based fallback that identifies the element the way a human tester would: by what it looks like and where it sits in the flow. The healed step is flagged for review before the fix persists in the system - the team sees what changed and approves it.

Our Auto Bug Finder surfaces accessibility gaps per screen during Crawler execution - contrast issues, missing labels, elements that fail WCAG checks - precisely the category of failure Liquid Glass migration is most likely to introduce.

Liquid Glass shipped with real performance issues on older devices - early builds showed sluggish rendering and elevated GPU load that Apple progressively resolved through subsequent updates. An app migrating to Liquid Glass today still carries that risk, particularly on devices outside the latest hardware generation. QApilot captures CPU, memory, battery, and rendering metrics during test execution - surfacing performance regressions as part of the same run that validates functional behaviour.

The September 2026 deadline and the Xcode 27 SDK mandate are arriving in the same window. For any team planning a release in the next twelve months, the question of whether their app has been tested against Liquid Glass is worth asking now.

Google upgraded Android's UI language, can test automation keep up?

Surya Polavarapu — Thu, 13 Aug 2026 10:48:42 +0000

On May 19, Google made it official: Jetpack Compose is now the only way forward for Android UI. The older approach of writing screens in XML, the markup language that defined app development for over a decade, is now placed in maintenance mode. No new feature launches, bug fixes only. 

For most developers, this landed as good news. Compose is genuinely better to build with: less code, faster iteration, cleaner architecture. So most of the attention since has been on what developers gained and barely anything on what happens to the test suites!

What actually changed under the hood

To understand why this matters for quality teams, it helps to know what automation tools have always relied on.

Android testing frameworks typically found elements on screen using identifiers: resource IDs, class names, positions in a structure called the View hierarchy. Every button, text field, and screen element in an XML-based app lives in that hierarchy. Your test says "find the element with ID btn_checkout" and the framework finds it.

Compose doesn't produce Views. It produces a semantics tree - a structure closer to how a screen reader navigates an app than to how traditional layouts worked. These are two different models.

Appium can interact with Compose, but not in the way most teams currently have it set up. It requires switching to the UIAutomator2 driver specifically - not the Espresso driver - and it only works if developers have explicitly added testTag modifiers to Compose elements and enabled testTagsAsResourceId in the app configuration. Those are deliberate, manual steps that someone on the engineering side has to take for every element that needs to be reachable by a test.

Most teams migrating existing apps to Compose haven't done this. The result is a test written to find btn_checkout by its resource ID will silently fail on a Compose screen - not because the button disappeared, but because the element it was looking for no longer exists in that form. Tests stop finding elements and the suite starts failing. So when teams are quickly rewriting UI code, they are quietly invalidating years of recorded test steps, locators, and automation logic

The same problem we solved for Flutter is now arriving for the Android native ecosystem

This isn't a new class of problem. Flutter introduced a version of it years ago, and it was worse. Flutter renders entirely on its own canvas, bypassing the native UI framework completely. UIAutomator2 sees nothing. XCUITest sees nothing. There is no View tree, and no semantics tree accessible through standard drivers. The only reliable paths are Flutter Driver - which only works on debug builds, not release ones.

At QApilot, we built our proprietary layer using advanced methods like OCR & computer vision precisely because standard locators find nothing. No custom framework setup or coordinate scripts - the test finds the element visually, the way a human would.

Compose is a step along the same spectrum. The accessibility layer is still reachable if the app is configured correctly. The problem is that "configured correctly" now requires deliberate choices from the development team that most aren't making yet.

The abstraction layer we've built normalises Native, Flutter, React Native, and WebView apps into a single locator and action interface. Compose First is another reason why that kind of abstraction matters. The specific UI framework your team chose to build in shouldn't be a variable that determines whether your test suite survives a platform update. 

It's worth watching how quickly Android teams migrate. Compose adoption has been steady but slower than Google would prefer - partly because legacy codebases are large, and partly because migration comes with invisible costs that don't show up in a developer experience comparison.