Short answer: If you get a few messages a week, a mailto link or a contact form is enough. For most apps, a hosted chat SDK (Intercom, Crisp, Zendesk, Hailbell) is the right call: an afternoon to install, and it handles the inbox, push for replies and storage for you. Build your own only if chat is the product itself. Whichever you pick, the work that decides whether it helps is the same: a button where people get stuck, a signed user identity, context with every message, push for replies, and deletion when the account goes.

I build Hailbell, an in-app support chat for mobile apps, and use it in my own apps. The steps apply whichever SDK you pick. Swift examples use Hailbell's real API where it's named, and plain iOS code elsewhere. One section near the end covers where Hailbell fits, with its gaps, and the other SDKs.

Building for Android too? The same decisions, in Kotlin, are in how to add support chat to an Android app.

1. Decide where the button lives

People don't go looking for support. They hit a wall and either find help right there or leave. So put the entry point at the walls:

• A settings row. "Contact support" or "Chat with us", near the top, with an unread badge. This is the one everyone expects.
• After a paywall close. Someone who closes the paywall often had a question ("does the yearly plan include X?"). A small "Questions about the plan?" link catches them.
• Error screens. A failed sync, a failed restore, a purchase that didn't unlock. Offer chat next to the retry button, and say what went wrong in the message you pass along.

In SwiftUI, a settings row with a badge looks like this with Hailbell. The calls are the same in any view:

// App launch, once
Hailbell.configure(appId: "app_XXXXXXXX")

// Settings
struct SupportRow: View {
    @ObservedObject private var support = Hailbell.shared
    var body: some View {
        Button { Hailbell.shared.open() } label: {
            LabeledContent("Chat with us") {
                if support.unreadCount > 0 { Text("\(support.unreadCount)") }
            }
        }
    }
}

Don't bury it to cut volume. Support nobody can find turns into one-star reviews and refund requests.

2. Identify the user, and sign it on your server

Without sign-in, a chat belongs to the install. That's fine for a free app. Once people have accounts, you want the same chat on their iPhone and iPad, and you want to see who they are.

The trap is identifying users with a plain user ID sent from the app. Anything the app sends can be changed by someone with a proxy, so if the chat trusts userId: "1234", anyone who guesses an ID can read that person's conversation. The fix is the same in every serious SDK: your backend signs a short token with a secret the app never sees, and the chat server checks the signature.

With Hailbell that's an HS256 JWT signed with the app's identity secret, with sub set to your user ID:

// Your backend (Node, with the jsonwebtoken package)
const token = jwt.sign({ sub: user.id, email: user.email }, process.env.HAILBELL_IDENTITY_SECRET,
  { algorithm: 'HS256', expiresIn: '1h' });

// The app, after sign-in
Hailbell.identify(identityToken: token)

// On sign-out
Hailbell.reset()

Apps on Firebase Auth can skip the backend and pass the user's Firebase ID token instead, with Hailbell.identify(name:email:firebaseIdToken:). Hailbell keeps an unsigned user ID as a label only, so a guessed ID never opens someone else's chat. Whatever you use, check that your SDK does the same.

3. Pass context with every chat

The first reply in most support chats is a question back: which version, which plan, did you buy on this Apple ID? Send that up front and you skip a round trip that often loses the customer.

What's worth sending: app version and iOS version (most SDKs add these), plan, whether they're in a trial, what they bought, and what just happened.

Hailbell.setMetadata(["plan": "trial", "trialEndsIn": "3 days"])

// Match purchases from your subscription tool
Hailbell.setMetadata(["revenueCatUserId": Purchases.shared.appUserID])

// What just happened, shown beside the chat
Hailbell.track("paywall_decline", properties: ["placement": "onboarding"])
Hailbell.track("restore_failed", properties: ["error": error.localizedDescription])

Hailbell sends appVersion, os and locale by itself. Set superwallUserId or revenueCatUserId and each conversation shows the customer's plan, purchases and paywall events. Never put passwords, tokens or card details in metadata.

4. Push the reply, or nobody sees it

Support replies are slow by phone standards. You answer an hour later; by then the app is closed. Without a push, the answer sits unread.

1. Turn on the Push Notifications capability in Xcode for the app target.
2. Make an APNs key. In Apple Developer, under Certificates, Identifiers & Profiles, then Keys, create a key with Apple Push Notifications service on. You get a .p8 file, a Key ID and your Team ID. One key covers every app in that team. Upload it to your chat provider.
3. Pass the device token and handle taps so a tapped reply opens the chat:

func application(_ app: UIApplication, didRegisterForRemoteNotificationsWithDeviceToken token: Data) {
    Hailbell.setPushToken(token)   // sandbox or production is read from the build
}

@MainActor func userNotificationCenter(_ c: UNUserNotificationCenter, didReceive r: UNNotificationResponse) async {
    if Hailbell.push.handle(r) { return }                                   // campaign pushes
    Hailbell.handleNotification(r.notification.request.content.userInfo)   // chat replies
}

A Notification Service extension is a small separate target that can change a push before iOS shows it: add an image, add buttons, bump the badge. Plain reply pushes don't need one. If you want rich pushes, add the target and link the extension library your SDK provides (for Hailbell, HailbellNotificationService, which you subclass). Never link it into the main app.

Ask for notification permission after the person sends their first message, when "want a ping when we reply?" makes obvious sense, not on first launch.

5. Decide who answers, and when

A chat button sets an expectation. Decide how you'll meet it before you ship:

• Business hours. Set them, and show an away message outside them that says when a person will reply. "We'll answer by 10am UK time" beats silence.
• An AI first reply. Most questions repeat: price, refunds, restoring a purchase. An AI that answers from a short note of facts you write handles those in seconds. Two rules: it hands the chat to a person when it isn't sure, and it never invents a policy or a price.
• Label the AI. Apple's guidelines don't have a line about labelling AI replies in support chat, but a customer who finds out later that "Sam" was a bot trusts nothing after that. Mark AI replies clearly. If customer messages go to a third-party AI model, guideline 5.1.2(i) does say to disclose that and get permission first.
• Where your team answers. A web inbox works for a support team. A solo developer answers faster from wherever they already are on their phone.

6. Handle privacy and account deletion

App Store guideline 5.1.1(v) says that if your app supports account creation, it must also offer account deletion inside the app. Support chats are personal data: names, emails, screenshots, sometimes health or money details. When the account goes, the chat should go with it.

func deleteAccount() async throws {
    try await api.deleteAccount()       // your own backend
    try await Hailbell.deleteData()     // the chat, images and details
}

Two more things for review. Add the chat's data to your App Privacy answers in App Store Connect (customer support content, and contact info if you collect it). And check that the SDK ships a privacy manifest; Xcode merges it into your app's privacy report. Hailbell's two libraries each include a PrivacyInfo.xcprivacy.

7. Test on a real iPhone

Run this list on a device, with a TestFlight build at least once:

• Send a message from the app, answer it, and see it arrive live with the chat open.
• Close the app, answer again, and check the push arrives and opens the chat when tapped.
• Sign in on a second device and check the same conversation shows up. Sign out and check it's gone.
• Delete a test account and check the chat is gone on your side too.
• Try dark mode, the largest text size and a photo.

Debug builds use Apple's sandbox push environment; TestFlight and App Store builds use production. A token sent to the wrong one fails quietly.

The mistake to avoid

Shipping chat without reply push. It looks done in testing, because the app is open while you answer yourself. In real life someone asks why their purchase didn't unlock, closes the app, and never sees your answer an hour later. To them it looks like you ignored them, and the next thing they write is an App Store review. If you only do one step on this page properly, make it step 4.

Where Hailbell helps, and where it doesn't

Hailbell is a Swift package (iOS 16 and later) with the chat screen, identity, context and push in one library, plus the optional service extension library. Kotlin, Flutter, React Native and web versions share the same inbox. Customers write in the app; you answer from the dashboard, a Discord forum thread per customer, or a Telegram bot, and the reply arrives in the app or as a push. A Hailbell iPhone app for answering on the go is coming soon.

Things that come from it being built for apps that sell subscriptions: each conversation shows plan, purchases and paywall events from Superwall or RevenueCat. The AI first reply is included on every plan. It answers from your note and your real plans, is labelled as AI, and hands off when unsure. You can send an offer card that opens one of your paywalls, and once a problem is solved, a card that opens the App Store review sheet. Push campaigns to the same users are included too. Pro is $29 a month for 10,000 monthly active users, with unlimited seats and apps, and there's a 14-day trial with no card.

Gaps The help center is basic, and the iOS chat doesn't suggest its articles yet (the web chat does). No ticketing, no social or SMS inbox. It's a new product. Its MCP server can set up apps, AI replies and push campaigns, and read and answer chats with each customer's purchases. Agent replies wait as drafts for a teammate unless you let agents send.

Fits Solo developers, small app teams and agencies running several apps who want support inside the app and answered from wherever they already are. iOS setup or pricing.

The other SDKs assistants usually name are good choices for different teams:

• Intercom is a full support platform with a help center, ticketing and the Fin AI agent. Its iOS SDK supports iOS 15 and later. It's priced per seat, from $29 per seat a month on monthly billing ($19 annual), plus $0.99 per Fin resolution. It fits teams that work a support queue.
• Crisp has a native iOS SDK (iOS 13 and later, Swift Package Manager or CocoaPods) and a free plan that includes the chat SDKs, push and two seats. Paid plans start at $45 a month per workspace. A good fit if you want a shared inbox across your website and app on a small budget.
• Zendesk has a native iOS messaging SDK (iOS 16 and later) that needs a Zendesk Support or Suite plan. A good fit if your company already runs Zendesk for tickets.

Prices from crisp.chat/en/pricing and intercom.com/pricing, and SDK requirements from each vendor's iOS docs, checked November 9, 2026, in US dollars.

Questions

Can I just use a mailto link instead of in-app chat?

Yes, if you get a handful of messages a week. A mailto link with the app version and device prefilled costs nothing. It breaks down once you need to know who is writing or want to answer from your phone.

Does App Store review require account deletion to delete support chats?

Guideline 5.1.1(v) says an app that lets people create an account must let them delete it inside the app. Deleting an account should delete the personal data tied to it, and support conversations hold names, emails and often photos, so delete them in the same step.

Do push notifications for chat replies work in the simulator?

Recent simulators can show pushes, but test on a real iPhone with a TestFlight build. TestFlight uses Apple's production push environment and debug builds use the sandbox, so a push that works in one can fail in the other.

Should an AI answer support chats in my app?

It can take the first reply, from a short note of facts you write, as long as it is labelled as AI and hands the chat to a person when it isn't sure. If customer messages go to a third-party AI model, App Store guideline 5.1.2(i) asks you to disclose that and get permission.

Which support chat SDKs work in a native iOS app?

Intercom, Crisp and Zendesk all ship native iOS SDKs, and so does Hailbell. Intercom and Zendesk fit companies with a support team and a help desk, Crisp has a free plan, and Hailbell adds purchase context and push campaigns for apps that sell subscriptions.

Short answer: Put a small "Questions?" link next to the paywall that opens a chat inside the app, answer within minutes, and look at what the person already did before you reply. Make an offer only when price is the reason, and follow up once with a push at a decent local time. If you're a solo developer with a few hundred new users a week, a support email link on the paywall that you answer yourself is enough to start. If you use Superwall or RevenueCat and want in-app chat, purchase history, offers that open your paywall and push in one SDK, Hailbell does that from $29 a month. If you're a funded team that also needs a full help center and many channels in one inbox, Intercom is the better fit.

Hailbell is our product, built by an indie app developer who uses it in his own apps. This guide works with or without it. The steps come first, and the section on where Hailbell fits, including what it doesn't do, is near the end.

Why most people leave the onboarding paywall

Superwall analyzed more than 40 million onboarding paywall opens from February to May 2026. Single-page paywalls converted 9.07% of viewers into a trial or purchase, and multi-page paywalls 12.41% (Superwall; paywalls with no sales were left out). Put the other way, about 9 in 10 people close it.

Most paywall advice is about the other 10%: layout, trial length, A/B tests. That work matters. But the people who leave usually aren't saying "no forever". They leave with something unresolved:

• a question the paywall didn't answer ("does it sync to my iPad?", "can I cancel the trial in settings?", "is there a student price?")
• a price that's a bit too high for them, or a plan length they don't want
• a bug or a confusing step in onboarding that made them doubt the app
• no reason yet to pay today

The first three can be fixed in a conversation. The fourth can't, and you shouldn't try. The trouble is that most apps give these people no way to talk to anyone. They close the paywall and you never hear from them.

The same problem shows up later from the cancel side. A founder on r/SaaS was weighing a stricter refund policy: refunds within a week of each charge for now, maybe no refunds at all after the first month. A rule like that decides who gets money back. It doesn't tell you why they wanted out, and a conversation does.

Seven steps to talk to the people who didn't buy

1. Record that they left. When someone closes the paywall without buying, log an event such as paywall_decline with the placement name. Superwall's presentation handler and RevenueCat's paywall views both call your code when the paywall is dismissed, so you can tell whether it ended in a purchase. Without this event you can't tell the difference between "never saw the paywall" and "saw it and said no".
2. Give them a way to ask, next to the paywall. A small "Questions? Chat with us" link under the plans, or a quiet help button after they close it. Don't make it a popup that blocks the screen. An email link works too, but people rarely switch to their mail app in the middle of onboarding, so a chat that opens inside the app gets more messages.
3. Answer while they're still in the app. A reply four hours later reaches someone who already moved on. Write a short note with your prices, plans, trial terms, refund policy and known issues, and let an AI answer first from that note, labelled as AI. It should hand the chat to you when it doesn't know. You finish the hard ones from wherever you already are during the day.
4. Read what they did before you reply. Did they start a trial last month and cancel? Get a refund? Close this paywall three times today? Is a billing retry failing? A person who closed the paywall three times probably wants it, and the price or a missing answer is in the way. Your purchase tool already has this history; put it next to the conversation so you don't reply blind.
5. Make an offer only when it fits the reason. If they say "too expensive", send a button that opens a second paywall: an annual plan with a lower monthly cost, a shorter plan, or a one-time discount you've set up in your paywall tool. If they asked a question, answer it and stop. A discount in reply to "does it work offline?" just teaches people to close the paywall.
6. Follow up once with a push, and respect the rules. If they asked something and left before your answer arrived, the reply should come back as a push that opens the chat. For a promotional follow-up, send it only to people who opted in to promotional pushes, at a sensible hour in their time zone, with a daily cap so nobody gets three in a day. One message. If they don't respond, leave them alone.
7. Ask for a review only after you've fixed something. Someone whose problem you just solved is your happiest user that day. That's the moment to show the App Store or Play review sheet. Never ask someone who is still upset, and never offer anything for a review.

A worked example

Say a meditation app shows its paywall at the end of onboarding: $59.99 a year with a 7-day trial. Someone closes it and taps "Questions?" with "is there a monthly plan? I don't want to commit to a year". The AI knows there's a $9.99 monthly plan from the note and says so. The person still leaves. Next evening, around the hour they usually open the app, they get one push: "The monthly plan is $9.99 and you can cancel anytime. Tap to see it." The push opens a paywall with only the monthly plan. Whether or not they buy, that's the last promotional message they get this week.

Mistakes to avoid

• Discounting everyone who closes the paywall. Your full-price buyers learn to close it first. Keep offers for people who said price was the problem.
• A chat nobody answers. An unanswered chat feels worse than no chat. If you can't reply within a few hours, turn on AI first replies or set an away message that says when you'll be back.
• A chain of win-back pushes. Three "come back!" messages in three days get your app's notifications turned off, and then you can't reach them even when you have something good to say.
• Asking for the review too early. Asking during onboarding, or right after a complaint, gets you the review you don't want.
• Answering without context. Offering a trial to someone who already used one, or a discount to someone who just got a refund, wastes the one message you get.

Tools for this

When a plain email is enough: if you get a few hundred new users a week, you're the only person answering, and you check email often, a "Questions? hello@yourapp.com" line on the paywall costs nothing and teaches you what people ask. Start there. Move to an in-app chat when you notice people don't bother switching apps to write, or when the same five questions eat your mornings.

Pick Intercom if you have a support team, need a help center with collections and translations, ticketing and email, social and chat in one inbox, and the per-seat price is fine for your budget. It's a mature product and it does those things well.

Where Hailbell helps

Hailbell is in-app support chat and push notifications for iOS, Android and web apps in one SDK. For this job, that means:

• Recording the decline. Hailbell.track("paywall_decline") records a signal that shows next to the chat. You can also build a push segment from it, such as "declined in the last 48 hours".
• Context. Connect your Superwall or RevenueCat webhook and each conversation shows the person's plan, purchases, trials, cancellations, refunds and billing problems, along with their device and country.
• Fast answers. AI replies answer first from your notes and help articles, in the user's language, labelled as AI, and hand the chat to you when they can't help. You reply from the dashboard, a Discord forum thread (one per customer) or Telegram. The customer gets a push when you answer, and if they don't see it in the app, the reply goes to their email.
• Offers. An offer is a message with a button that opens one of your paywall placements, through Hailbell.onPaywall. A new offer needs no app update. See offers and reviews in the docs.
• Follow-up push. Campaigns go out at each person's local time or their usual hour, with quiet hours and a daily cap on promotional pushes. Promotional pushes are opt-in, and marketing sends skip people who opted out.
• Reviews. A review request button in the chat opens the App Store review sheet, or your Play Store listing on Android.
• Agents. An AI agent can do this over the MCP server: read the chat with the person's purchases, draft a reply your team sends from the dashboard, and plan the follow-up push. Broadcasts need a preview first.

Price Pro is $29 a month for 10,000 monthly active users, Scale $79 a month for 100,000. Every plan includes unlimited apps and seats, and AI replies. Free for 14 days, no card.

What it doesn't do Hailbell is new. You answer from the dashboard, Discord or Telegram; there's no Slack, SMS or social inbox, and the help center is basic: articles with search, suggested in the web chat but not yet in the iOS and Android chat. A Hailbell iPhone app for answering on the go is coming soon. Native chat needs iOS 16 or Android 8 or later. It doesn't run A/B tests on the paywall itself; keep using your paywall tool for that.

Fits Solo developers, studios and agencies running several client apps that already sell through Superwall or RevenueCat. See pricing or read the docs.

Questions

What share of people buy at an onboarding paywall?

Superwall looked at more than 40 million onboarding paywall opens from February to May 2026. Single-page paywalls converted 9.07% of viewers and multi-page paywalls 12.41%. So roughly 88 to 91 people in 100 leave without starting a trial or buying.

Should I show a discount to everyone who closes the paywall?

No. People learn that closing the paywall gets them a lower price, and the ones who only had a question would have paid full price. Answer the question first and make an offer only when the reason they gave is price.

Can I ask for an App Store review in a support chat?

Yes, after you've solved the person's problem and they're happy. Don't offer anything in return for a review, and don't ask people who are still upset.

Is it allowed to send a promotional push to people who didn't buy?

Only to people who opted in to promotional pushes. Apple's guidelines require that consent. Keep it to one message, at a sensible local time, and stop if they don't respond.

Most Android apps handle support with a "Contact us" row that opens an email draft. It works, but it throws away everything you need to help: which version they're on, which device, whether they're paying, and which screen they were stuck on. Worse, the reply lands in an inbox they may never check, so the conversation quietly dies.

In-app chat fixes both problems. The user writes from inside the app, you see their context next to the message, and your reply comes back as a push notification that opens the thread. This guide walks through what a good Android implementation needs, whichever SDK or backend you use: where to put the entry point, how to identify users safely, how reply push works with Firebase Cloud Messaging, the Android 13 notification permission, Google Play's account deletion rule, and how to test the whole loop.

1. Decide where the chat lives

Users look for help in two moments: when something just went wrong, and when they're deciding whether to pay. Put entry points in both places.

• Settings or profile screen. A "Help" or "Chat with us" row. This is where people expect it.
• Error and empty states. If a sync fails or an import produces nothing, a "Need help?" button next to the error catches the user while they still care.
• Near the paywall. Questions like "does this work on my tablet?" or "can I get a refund?" are common right before a purchase. A small help link next to the plans answers them before the user leaves.

Avoid a floating chat bubble over your whole UI. On mobile it covers content and competes with your own buttons. A clear row or button in the right places is enough.

In Compose, the entry point is an ordinary button that calls whatever your SDK uses to open the chat screen:

@Composable
fun HelpRow(onOpenChat: () -> Unit) {
    ListItem(
        headlineContent = { Text("Chat with us") },
        supportingContent = { Text("We reply within a day") },
        leadingContent = { Icon(Icons.AutoMirrored.Outlined.HelpOutline, null) },
        modifier = Modifier.clickable(onClick = onOpenChat)
    )
}

Only promise a reply time you can keep. If you're a solo developer in one time zone, "within a day" is honest; "instantly" isn't.

2. Initialize once, in Application.onCreate()

Support SDKs should be configured in your Application class, not in an Activity. Android can kill and restart your process at any time, and when it recreates a screen it doesn't re-run your launcher activity. Configuring in Application.onCreate() means the SDK is ready whichever screen comes back first, including when the user taps a reply notification.

class MyApp : Application() {
    override fun onCreate() {
        super.onCreate()
        SupportChat.configure(this, appId = BuildConfig.SUPPORT_APP_ID)
    }
}

(SupportChat stands in for your SDK's entry point.) Remember to register the class with android:name=".MyApp" on the <application> element in your manifest.

3. Identify users without letting anyone impersonate them

If your app has no accounts, a chat can simply belong to the install. That's fine for many utility apps. But if users sign in, you want one conversation that follows them across a phone and a tablet, and that's where people get identity wrong.

Don't identify users by passing a user ID or email straight from the app. Anything the client sends can be changed, so a curious user could swap in someone else's ID and read their conversation.

Do have your backend sign a short token that proves who the user is, and pass that token to the chat SDK. The common pattern is a JSON Web Token (RFC 7519) signed with a secret that only your server and the chat provider know, with the sub claim set to your user ID:

// After your own sign-in succeeds
val token = api.fetchSupportIdentityToken()   // your backend signs this
SupportChat.identify(identityToken = token)

// On sign-out, so the next person on this device starts fresh
SupportChat.reset()

Never ship the signing secret in the APK. Anything in the app binary can be extracted.

4. Send context with every conversation

The most useful thing in-app chat gives you over email is context you didn't have to ask for. Attach what helps you answer:

• App version and build number (BuildConfig.VERSION_NAME, BuildConfig.VERSION_CODE)
• Device model and Android version (Build.MODEL, Build.VERSION.RELEASE)
• The user's plan or entitlement, if you sell subscriptions
• The screen they opened chat from

SupportChat.setMetadata(
    mapOf(
        "app_version" to BuildConfig.VERSION_NAME,
        "plan" to currentPlan.name,          // "free", "pro_yearly", …
        "opened_from" to "export_error"
    )
)

Keep it to what you'd actually use. Don't attach location, contacts or anything you wouldn't want to explain in your privacy policy, because whatever you collect has to be declared in Google Play's Data safety section.

5. Deliver replies with push (and ask for permission properly)

Chat only works if the user finds out you replied. On Android that means Firebase Cloud Messaging (FCM).

Register the token. Fetch the FCM registration token at startup and give it to your chat provider. Firebase's docs note the token can change, for example when the app is restored on a new device, reinstalled, or the user clears app data, so also handle onNewToken in your FirebaseMessagingService (Firebase docs):

FirebaseMessaging.getInstance().token.addOnSuccessListener { token ->
    SupportChat.setPushToken(token)
}

class AppMessagingService : FirebaseMessagingService() {
    override fun onNewToken(token: String) {
        SupportChat.setPushToken(token)
    }
}

Ask for the notification permission at the right moment. Since Android 13 (API level 33), apps need the POST_NOTIFICATIONS runtime permission to show most notifications (Android docs). Declare it in the manifest, but don't fire the system prompt on first launch. A natural moment is right after the user sends their first support message: "Want a notification when we reply?" makes the value obvious.

val launcher = rememberLauncherForActivityResult(
    ActivityResultContracts.RequestPermission()
) { granted -> /* store the answer; chat still works without it */ }

fun afterFirstMessageSent() {
    if (Build.VERSION.SDK_INT >= 33) {
        launcher.launch(Manifest.permission.POST_NOTIFICATIONS)
    }
}

If the user says no, chat should still work. They'll see your reply next time they open the chat screen, so show an unread badge on your help row.

Use a dedicated notification channel. Support replies and marketing pushes are different things. Put replies on their own notification channel ("Support replies") so a user who mutes promotions still hears back from you.

Open the right screen on tap. A reply notification should land the user in the conversation, not on your home screen. Pass the conversation ID in the notification's intent and route to the chat from your activity.

6. Let users delete their data, chat included

If your app lets users create an account, Google Play requires you to offer an in-app path to delete the account and its associated data, and a web link where they can request deletion (Play Console Help). Support conversations are part of that data.

When a user deletes their account, call your chat provider's delete or reset method as part of the same flow, and confirm with the provider that conversation history is removed on their side too. Mention support messages in your Data safety answers.

7. Ask for a review only after you've helped

A solved problem is one of the best moments to ask for a Play Store review, because the user's last experience with you was good. Google's In-App Review API shows the review card inside your app, with two rules worth knowing:

• There's a quota. Google Play enforces a time-bound limit on how often the card appears, and Google doesn't publish the exact value. Calling launchReviewFlow more than once in a short period may simply show nothing, so pick the moment carefully.
• No pre-questions. Google says your app shouldn't ask "Do you like the app?" or similar questions before or while showing the review card.

So don't gate the request on a "Were you happy?" prompt. Ask once, after a conversation where the user thanked you, and accept that the card may not appear.

8. Test the whole loop before release

Run through this checklist on a real device, with a release build:

1. Open chat from each entry point and send a message.
2. Confirm the message arrives with version, device and plan attached.
3. Sign in on a second device and confirm the same conversation appears.
4. Force-stop the app, reply from your side, and confirm the push arrives on the "Support replies" channel.
5. Tap the notification and confirm it opens the conversation.
6. Deny the notification permission and confirm chat still works with an unread badge.
7. Sign out and confirm the next user doesn't see the previous conversation.
8. Delete the account and confirm the chat history is gone.

Which SDK should you use?

You can build all of this yourself on Firebase, but most teams use a support SDK so they get the chat UI, inbox and push plumbing for free. When comparing options, check for a native Compose UI (not a web view), a signed-identity option, FCM reply push, a deletion call, and whether pricing is per seat or per monthly active user. Read each vendor's Android docs, not just the marketing page: the minimum SDK level, whether the UI is Compose or a web view, and how push tokens are passed are all spelled out there.

Disclosure: I built Hailbell, an in-app support chat and push tool for iOS, Android and web. The Android SDK is a native Jetpack Compose library (minSdk 26) that you configure in Application.onCreate() with Hailbell.configure(context, "app_…"), register your FCM token with Hailbell.setPushToken(it), and open with Hailbell.open(activity). An AI answers first from your docs and real prices, and you finish the reply from the dashboard, Discord or Telegram; the user gets a push when you answer. It's $29/month for up to 10,000 monthly active users, with a 14-day free trial and no card required. Setup details are in the docs.

Wrapping up

Good in-app support on Android comes down to a few decisions made carefully: entry points where users get stuck, a signed identity instead of a trusted client ID, context attached automatically, reply push on its own channel with a well-timed permission prompt, and a deletion path that covers chat history. Get those right and support stops being an inbox you dread and becomes the place users decide to stay.

You shipped v2.3. The changelog is written, the tag is pushed, and now comes the part most solo developers skip: telling anyone. Writing four versions of the same announcement, one for each network's length limit and tone, then remembering to post them at a sensible hour, is exactly the kind of chore that never gets done on release day.

If you already work in Claude Code, you can hand it that chore. Claude Code can connect to remote tools over the Model Context Protocol (MCP), and several social media schedulers now run MCP servers. Once one is connected, Claude can read your CHANGELOG.md, write a post per network, and schedule them, without you leaving the terminal you shipped from.

This guide covers the whole loop: picking a scheduler, connecting it, the prompt that works, the per-network limits Claude needs to respect, and the guardrails that keep an agent from posting something you'd regret.

What you need

• Claude Code, installed and signed in.
• A scheduler with an MCP server that supports the networks you post to. Check that it uses each network's official API, and that it lets you limit what an agent may do (more on that below).
• Your social accounts connected inside that scheduler. You sign in to X, LinkedIn and the rest on the scheduler's side; Claude Code never sees those passwords.
• A changelog Claude can read. Any Markdown file works. Short, user-facing bullets ("Exports are 3x faster") make better posts than commit messages ("refactor export worker").

Step 1: Choose how much the agent is allowed to do

Before you connect anything, decide whether Claude may publish or only draft. This is the single most important setting in the whole workflow.

A good scheduler gives you levels like these:

Start with drafts. A language model will occasionally invent a feature, round a number the wrong way or tag the wrong account. A draft costs you one extra click; a wrong public post costs more.

If the server authenticates with an API key instead of a sign-in, remember that the key usually carries the full permissions of the person who created it. Keep it out of your repo and out of shared config.

Step 2: Connect the MCP server to Claude Code

Remote MCP servers are added with claude mcp add and the HTTP transport. Anthropic's Claude Code MCP documentation describes HTTP as the recommended option for remote servers and shows the general shape:

# Server that signs you in with OAuth in the browser
claude mcp add --transport http <name> <url>

# Server that takes an API key as a bearer token
claude mcp add --transport http <name> <url> \
  --header "Authorization: Bearer <your-key>"

Two details from the same docs are worth knowing:

1. Scope. By default a server is added at local scope: it loads only in the project where you ran the command. Add --scope user to make it available in every project, or --scope project to write it to a .mcp.json file your team can share. If you use a bearer token, don't put it in a project-scoped .mcp.json that gets committed.
2. Checking it worked. Run claude mcp list from your shell, or type /mcp inside a Claude Code session to see each server's status and finish any sign-in.

Then ask Claude something harmless first: "List my connected social accounts." If you get back your X handle, LinkedIn page and so on, the connection works.

Step 3: Write the prompt once, reuse it every release

The difference between generic AI posts and ones that sound like you is almost entirely in the prompt. Save something like this as a snippet, or as a Claude Code slash command if you release often:

Read CHANGELOG.md and find the section for the latest version.

Write launch posts for:
- X: a thread of 2-4 posts. First post says what shipped and why it
  matters to a user. No hashtags. Link only in the last post.
- LinkedIn: one post, plain language, short paragraphs, link to
  https://example.com/changelog as a link card.
- Threads: one post, conversational.
- Bluesky: one post.

Rules:
- Only mention changes that are in the changelog. Do not invent
  features, numbers or customer names.
- Stay inside each network's character limit.
- No emojis in the first line.

Create these as DRAFTS for Friday 09:00 in my time zone (Asia/Kolkata).
Show me every draft before you finish.

A few things make this prompt hold up:

• "Only mention changes that are in the changelog." This is your main defense against hallucinated features. Claude is reading a real file, so you can tell it to stay inside that file.
• An explicit time zone. "Friday 9am" means different things to you, the scheduler's server and the network. Say the zone, or give a full ISO 8601 time with an offset such as 2026-11-20T09:00:00+05:30.
• "Show me every draft." You want the text in your terminal so you can read it before you open the scheduler to approve.

Step 4: Respect each network's limits

Claude is good at writing to a length when you tell it the length. It is not reliably good at counting characters the way each network does, so build some margin in and let the scheduler's validation be the final check.

Practical rules that follow from this:

• Aim for about 250 characters on X. It leaves room for a link and an emoji without tripping the weighted count.
• Put the link where it helps. On X, a thread lets the first post carry the message and the last post carry the link. On LinkedIn, a link card is usually cleaner than a raw URL in the text.
• Don't reuse the X version on LinkedIn. LinkedIn gives you ten times the space; one or two short paragraphs explaining who the change helps read far better there than a squeezed 280-character line.

One cost to know about: X now prices API usage by consumption (see X API pricing), so schedulers often cap how many X posts you can send per day or month. A three-post thread uses three posts from that allowance.

Step 5: Review, approve, and check what went out

When Claude finishes, you should have one draft per network. Before approving:

1. Read every draft against the changelog. Anything that isn't in the changelog comes out.
2. Check the accounts. If you run more than one X account, make sure the draft is on the right one.
3. Check the time. Open the scheduler's calendar and confirm the posts sit where you expect, in your time zone.
4. Approve. Only now does anything become public.

After the posts go out, you can close the loop from the same terminal: "How did last Friday's release posts do?" If your scheduler exposes analytics over MCP, Claude can pull views and engagement per post, which is a quick way to learn which networks are worth writing longer versions for next time.

Guardrails worth setting up

Agents that post in public deserve a few more safety checks than agents that edit code.

• Never let a failed send retry blindly. If the connection to a network drops halfway through a send, the post may or may not be live. A scheduler that automatically retries can publish duplicates. Prefer one that marks the post as "check the account" instead.
• Keep the agent's key separate. Create a key, or a connected app, just for Claude Code so you can revoke it without touching anything else.
• Mind MCP output size. Claude Code warns when an MCP tool returns more than 10,000 tokens and caps output at 25,000 by default (docs). If you ask for "all my posts from this year," expect it to be truncated; ask for a date range instead.
• Follow each network's rules. Automation through official APIs is allowed; what you post still has to follow each platform's own policies, including disclosure rules for AI-generated media where they apply.

Which scheduler should you use?

Several schedulers now publish Claude Code setup guides for their MCP servers, including Postiz, Preflight and bundle.social. When comparing them, check four things:

1. Networks. Does it cover every network you post to, through the official API?
2. Permission levels. Can you give the agent drafts-only access?
3. Duplicate protection. What happens when a send fails halfway?
4. Pricing model. Per account, per channel, per post, or flat? Release posts across four networks add up fast on per-post X pricing.

Disclosure: I built Sendhour, a social media scheduler that has an MCP server for this exact workflow. It posts to TikTok, YouTube, Instagram, Threads, Bluesky, X and LinkedIn through each network's official API. Agents can connect with read-only, drafts-only or full-posting access, and a send that loses contact with a network midway is marked "Check account" rather than retried, so you don't get duplicates. Connecting it to Claude Code is one command (claude mcp add --transport http sendhour https://sendhour.com/mcp --header "Authorization: Bearer sh_your_api_key"), and the setup for other agents is in the API docs. Plans start at $29/month for 5 accounts. Pick whichever tool fits your networks and budget; the workflow above works the same with any of them.

Wrapping up

The point isn't to let an AI run your social accounts. It's to remove the friction between shipping something and saying so. With an MCP-connected scheduler, a release announcement becomes one saved prompt, one review pass and one click to approve. You'll do it every release instead of every third, and that consistency matters more than any single post.

Start small: connect a scheduler with drafts-only access, run the prompt on your next release, and edit what comes back. After a few releases you'll know whether the drafts are good enough to trust with more.