New in NAPPS: June to August 2026

Three months of shipping.

Custom pages left our hands and landed in yours. Notifications learned who to reach and when to stay quiet. The analytics dashboard went live. And the app itself got a new look, on faster foundations.

Here is what changed, in the order it is likely to matter to you.

Custom pages are live

Until now, a custom page in your app meant asking us to build it. That is over.

Custom pages are a builder now. It sits alongside Home, PLP, PDP, and Menu, and it works the same way: drag components in, arrange them, publish. You already know the components, because they are the same ones you use in the other builders. Any Expresso component your team or your agency has built is available in there too.

Each page can be reached straight from your navigation. You can preview it as it will appear in the app, search across your pages once you have a few, and put custom pages behind their own permission so you decide who edits them.

Size guides. Brand stories. Care instructions. Campaign landers. Anything your store needs that a collection page was never going to carry.

Notifications know who to reach, and when to wait

Two changes, and together they change how often you can afford to send.

Segments. A notification can now go to a slice of your audience instead of all of it. Build a segment once from country, language, and customer status (everyone, registered customers, or anonymous app users) and reuse it. The segment list shows the share of your customers each one reaches, so you know the size of an audience before you send to it.

Dead hours. Give any automated notification a quiet window, with its own start time, end time, and timezone. The abandoned-cart message that used to fire at 3am now waits until morning. Timezones are respected per notification, so a store selling into three markets no longer has to pick one.

A real destination for every send. A notification can now open the wishlist, the menu, the Drops feed, the customer profile, a custom page, or any link, on top of the product, collection, order, and cart destinations you already had. No more sending someone to the home screen and hoping they find it.

Managing them got easier too: notifications are searchable, each one shows its audience on the card, and automated notifications carry translations, so the message reads properly in every market you sell to.

The analytics dashboard is live

Your app now reports on itself, in the dashboard, next to everything else.

It answers the questions your Shopify admin cannot: which products get viewed but not added, what people search for and find nothing, which push content actually earns revenue, how each Drop format performs, and how much of your install base you can reach with a notification.

Push and Drops revenue is attributed inside a 12-hour window and counted in each order's own currency. That window is deliberate, and so is keeping it separate from your Shopify, email, and paid numbers. If you want the reasoning, and a framework for which number belongs in which system, we wrote it up: mobile app metrics for Shopify brands.

Making those reports specific took new work in the app: which card and which layout a product was tapped from, where a wishlist add came from, and screen-level tracking. That is the difference between knowing your app converts and knowing which merchandising decision did it.

A new look, and a navigation bar you control

The app's navigation and toolbars were rebuilt around a glass material. Translucent bottom bar, glass toolbars across Home, PLP, PDP, search, menu, wishlist, and profile, a pill indicator that slides between tabs, and a bar that collapses out of the way on the screens where the content matters more than the navigation.

The bottom bar is also yours to configure now, where it used to be fixed:

• Choose which pages appear, and in what order.
• Pick a custom icon per item from the icon library, or reset to the defaults.
• Translate every label.
• Set the bar colors in the theme.
• Use a floating glass bar on Android, not just on iOS.

The part worth knowing about the glass: it adapts to the phone, on both platforms.

The app reads the device performance tier and steps the effect down on mid-tier hardware. On low-tier Android devices, and on Android 12 and below, it falls back to solid bars. On iOS 18 and below, the customer gets the native bottom bar of that generation, the one they already know from every other app on the phone.

Nobody gets a slow app for the sake of a nice bar. Your customer on a three-year-old phone gets the version that runs well on it.

A faster app

Most of this is invisible, which is the point.

• Every page loads off the main thread, so the app keeps responding while it works.
• Components load lazily, everywhere. The app preloads the components a customer is about to see and skips the ones they are not about to reach. Nothing loads just because it sits further down the page.
• Rendering work was cut in several places, including the PDP add-to-cart, product stories, Drops, and the bottom bar.
• Drops always preloads the next video, so the feed does not stall between clips. The Drops data itself preloads after Home and Menu, in that order.
• Lazy loading is what makes the app lighter on memory and processor. Preloading spends a little of that back on purpose, where it buys a faster first screen. Beyond that, the network cache is capped, and when the phone warns that memory is short the app clears its in-memory cache instead of waiting to be shut down.

Crashes and correctness, fixed: the app no longer crashes when it opens with no connection, or during onboarding, or on certain back navigations. Video stops when the app goes to the background. A memory leak in the rendering layer is closed.

Privacy, spelled out

Your app already asked for consent during onboarding. What changed is how much the customer can see and decide there.

The privacy step now names what is collected and what it is used for, section by section, and gives a toggle per section instead of one blanket yes or no. A customer who is glad to help with one thing and not another can say exactly that, on first open, without hunting through settings.

GDPR is why we changed it. It shaped two decisions: name what each section collects, and let a customer accept one purpose without accepting the rest. What your store needs to comply is your legal team's call, and this gives them a consent step precise enough to work with.

Every prompt and description is translated across 16 languages, including Apple's tracking prompt, so the customer reads it in their own language rather than in English. Their answer is respected everywhere the app sends data, and they can change it later from their privacy preferences.

Essential and performance data continue regardless, because the app cannot run or be kept stable without them. Nothing personal moves before someone says yes.

Stores, stock, and pickup

For brands with physical stores:

• Click and Collect on the product page, with availability shown per variant.
• A preferred store that sticks, with a sorted store picker, and availability that refreshes when the customer changes store.
• Navigation from the product page to store availability.
• A geo-restriction option, so app access can be limited by location.

Dashboard quality-of-life updates

• Clone a builder with a name, and carry its translations across with it.
• Import a layout from an existing builder instead of starting from scratch.
• Schedule PDP layouts, the way you already schedule Home and Menu.
• Reset a theme, or reset icons, back to defaults.
• Clear collection data in one action, with a prompt before you discard translation edits.
• Safe-area handling on PLP, so collection products stop getting clipped.

For your developers and your agency

Expresso got a proper runtime and proper tooling this quarter.

The runtime now supports the standard JavaScript APIs a real component needs: fetch with form data, multipart, and streams, WebSocket, Web Streams, Web Crypto, Compression, URL and URLPattern, TextEncoder, Blob, Performance, and timers. TypeScript definition generation improved, so component authoring has real types and real autocomplete.

The tooling is new: a UI tree you can inspect, fast refresh, console logs mirrored into the in-app devtools on both platforms, and scoped dev sessions that inject a component into a running app. All of it sits on a test suite covering the SDK, the rendering layer, and the Home, PLP, and PDP builders.

Custom components can now be placed in custom pages, and custom product-page components emit events. Agencies authenticate against a partner API with per-tenant access and pick which store they are working on.

Want any of this switched on, or a walkthrough of segments and the analytics dashboard?