Your dev team pushes a routine SDK upgrade. Nothing dramatic, just a dependency bump ahead of a new OS release. Two days later, someone notices the News Feed calls in your Braze integration are failing silently. No error, no crash log, just messages that stopped showing up. Sound familiar?

Or maybe you’re on the marketing side. Your inbox campaign, the one that’s been quietly running for two years, just stopped delivering. Nobody flagged it. Nobody warned you.

Here’s what happened. Braze pulled News Feed out of every SDK by the May 28, 2026 release. This wasn’t sudden. It followed years of phased deprecation, starting when Content Cards was introduced as News Feed’s replacement. But phased or not, if you weren’t watching closely, it caught you off guard.

This is a practical, no-panic guide to Braze News Feed migration: what broke, how to map your old News Feed use cases onto Content Cards or Banners, and how to audit your implementation before it turns into a bigger problem. 

Let’s cut to the chase. 

What broke, and when

The long goodbye. Braze didn’t remove News Feed overnight. Content Cards was introduced as News Feed’s intended successor years ago. From there, News Feed-related methods, including created, categories, linkText, requestFeedRefresh, and logFeedDisplayed, were marked deprecated across SDKs through 2025. Full removal landed with the May 28, 2026 SDK release.

What “removed” actually means? This isn’t a warning you can put off for another quarter. Braze confirmed the removal fully strips all News Feed UI elements, data models, and actions from the SDKs. So if your app compiles against a current SDK version with News Feed code still sitting in it, the build fails. It doesn’t throw a runtime warning. It doesn’t degrade gracefully. It just won’t compile.

Who’s actually affected? If your team already moved to Content Cards or Banners, you’re fine. Nothing to do here. But if you’re still running an older SDK with legacy News Feed integration, you’re exposed the moment you update dependencies for any other reason. A security patch. A new OS requirement. An unrelated feature your product team wants shipped next sprint. The trigger rarely has anything to do with News Feed itself, which is exactly why it catches teams off guard.

The silent risk. Most teams don’t proactively audit third-party SDK deprecations. That’s just reality. Deprecation notices sit in changelogs nobody reads until something breaks. So this often surfaces as a broken build or a support ticket months after the fact, not as a clean, planned migration. 

Content cards or banners: Picking the right replacement

Here’s something worth knowing upfront. Braze didn’t build a single like-for-like replacement for News Feed. Instead, it split News Feed’s job across two separate channels: Braze Content Cards and Braze Banners.

Content Cards is the direct architectural heir to News Feed. Think of it as a swipeable, dismissible feed, with Classic, Captioned Image, and Image Only card types. It supports pinning, read and unread state, and full analytics tracking right out of the box through the default feed UI. If your old News Feed felt like an inbox, Content Cards is where that inbox lives now.

Banners, on the other hand, are newer and lighter. They’re developer-placed, inline units meant to sit within an existing screen, a homepage strip, a specific in-app page, rather than living in their own dedicated inbox view.

So how do you decide which one fits your use case? Ask yourself one question. Was the old News Feed use case “a place users go to see everything,” or was it “a message that should live inside one specific existing screen”? The first points you to Content Cards. The second points you to Banners.

Think about it this way. A retailer running an in-app “offers hub” needs Content Cards. A SaaS product surfacing a single upgrade nudge on the billing page needs a Banner. Same underlying goal, different shape. 

Mapping common News Feed use cases to their new home

Once you know the deciding question, most of your old News Feed use cases map cleanly. Here’s how the common ones break down.

Promotional inbox and offers feeds, the dedicated “deals” tabs that housed a running list of promotions, map to Content Cards. They preserve the scrollable, dismissible, multi-item feed experience your users already know.

Order and account updates that used to sit in a News Feed tab also map to Content Cards, since they benefit from persistence and a dedicated unread count badge.

A single homepage promo strip, the kind of rotating banner-style message that used to be pinned inside News Feed, maps to a Banner. It’s meant to live in one specific placement, not inside its own feed.

Cross-sell or upsell nudges on specific screens, a cart page upsell, a settings page reminder, also map to Banners. They’re built to show up exactly where the moment happens, instead of asking users to go find an inbox.

Editorial or content-style announcements, longer-form updates about new features or product news, map to Content Cards’ Classic or Captioned Image types. Both support titles, descriptions, and images inside a single scrollable card.

Here’s a quick reference for your team:

News Feed Use Case	Recommended Channel
Promotional inbox or offers feed	Content Cards
Order and account updates	Content Cards
Editorial or feature announcements	Content Cards
Single homepage promo strip	Banners
Cross-sell or upsell nudges on specific screens	Banners

Two quick examples to make it concrete. A fintech app’s “What’s New” feed belongs in Content Cards. An ecommerce brand’s single free shipping threshold banner on the cart page belongs in Banners. 

Running a Braze health check before you migrate

Before you touch a single line of code, run a quick audit. Here’s what that actually looks like.

Start with the codebase. Search across every platform your app ships on for any remaining News Feed method calls, requestFeedRefresh, logFeedDisplayed, and any leftover News Feed UI references.

Check the dashboard side too. Campaigns and Canvases built on the old News Feed channel inside the Braze dashboard don’t migrate themselves. Removing the SDK code doesn’t retroactively fix your dashboard-side messaging. You’ll need to recreate those as Content Cards or Banners campaigns.

Re-identify users where it’s required. On iOS specifically, migrating off the News Feed UI requires re-identifying users by calling changeUser for non-anonymous users. This one’s easy to miss, and skipping it can create a real gap in your personalized messaging. It’s a small step on paper, but it’s the kind of thing that only shows up as a problem weeks later, when engagement data looks off, and nobody can figure out why.

And here’s the thing. This forced migration is a good moment for a broader Braze health check, not just a box to check. Teams that are already in their Braze integration for this reason often find other outdated configurations sitting right next to it. Old SDK versions. Unused legacy methods. Campaigns nobody’s touched in a year. Might as well look while you’re already in there. 

Wrapping up

News Feed is fully gone as of the May 2026 SDK release. Content Cards and Banners together cover everything it used to do, and once your team knows which channel maps to which use case, the fix is straightforward.

This kind of SDK-driven deprecation isn’t a one-time headache. It’s a recurring reality of running on any vendor’s platform. Today it’s News Feed. Next year it’ll be something else. Treating it reactively, only fixing it when a build breaks, costs more time and more trust than treating it proactively.

If you’d like a second pair of eyes on your News Feed remnants, your dashboard campaigns, or your broader Braze SDK migration, our team at Mavlers runs Braze health checks for exactly this reason. Let’s talk.