DEV Community: Vidur Saini

How to market your app on TikTok without ads or creators

Vidur Saini — Sat, 14 Nov 2026 17:30:13 +0000

This guide was originally published on the Sendhour blog.

Short answer: Find posts in your niche that beat their account's usual views, copy their structure (never the footage), and post your version every day for a month, mostly as photo slideshows and short screen demos. Then keep the hooks that get installs, not just views. A solo developer can run this on one or two accounts alongside building the app. An agency or studio runs the same loop per client app, with an account per angle. Pay for ads or creators once you know which post converts, not before.

I build Sendhour, a tool for this exact loop, so keep that in mind. Most of this article works with no tool at all, and I say where Sendhour helps in one section near the end.

Some context on why I care. My apps stalled while I relied on App Store optimization alone, so I moved to organic short video. I now run about 15 TikTok accounts for my own apps, mostly photo slideshows plus some videos. My best posts have reached around 50,000 views. Most posts do far less, and that is normal.

Why organic TikTok works for apps

App Store search only reaches people already looking for something like your app. TikTok shows your post to people who weren't looking, and one post that lands can send more users than everything else you've tried. A developer on r/appdev described this: they tried build-in-public, SEO, Product Hunt and Reddit, and then one TikTok that crossed a million views brought more users than all of it combined. That is one person's story, not a promise.

The question people actually ask is the one in this r/AppBusiness thread: how do you get your first 1,000 users with no ad budget? Short video is one of the few answers that costs time instead of money.

The playbook, step by step

Pick two formats that fit your app. Most apps do well with one of these:
- Photo slideshows: a hook on the first slide, a few slides that build a story or a list, the app on the last slide. Cheap to make, no face needed.
- Screen demos: 6 to 10 seconds of the app doing one thing, with a hook written on the first frame. Best when the app has a visible before and after, like scanning a receipt and splitting the bill.
- Voiceover videos: real clips with a voice telling a short story that ends at your app.Start with two, not five, so you can tell which one works.
Find posts that beat their account's usual views. Search your niche on TikTok and open the profiles of people posting in it. You're looking for a post that did several times what that account normally gets, ideally 10 times or more. A big account's normal day tells you about the account. A small account's breakout tells you about the format.
Write down the structure. For each breakout, note the hook pattern, how many slides or seconds, where the payoff lands, and how it ends. For example: "Slide 1 is a relatable complaint, slides 2 to 5 are tips, slide 6 shows the app as the last tip."
Make your version. Same structure, your topic, your app, real photos or your own screen recordings. Never reuse the original footage or text.
Post every day on a schedule. One post a day per account is enough to start. Schedule a week at a time so a busy day doesn't break the run.
Add accounts before you add volume. Once one account has a format that works, a second account with a different angle (a different audience or a different problem your app solves) teaches you more than a second post a day on the first.
Post the same video on other networks. The same file can go to Instagram Reels and YouTube Shorts. It costs nothing, and sometimes the post that flops on TikTok does well somewhere else.
Measure, then repeat what works. Covered in the next section.

What to measure and what to repeat

Views are the first filter, not the goal. Keep a simple log for every post: the date, the format, the hook text, views after two days, and whether installs moved that day. After 30 or so posts, patterns show up. A hook style that keeps getting watched, a slide count that keeps working, a topic that sends installs even with modest views.

If your app uses RevenueCat or Superwall, Sendhour can keep the installs half of that log for you: it imports your daily installs and revenue and lists the posts published in the 48 hours before each jump. A jump after a post is a lead to test again, not proof the post caused it.

Then do three things:

Remake your best post with a new hook. Keep the body, change the first line.
Drop the format that never gets past the first second after two weeks.
Watch views against installs. If a post gets views but no installs, the hook is pulling the wrong audience or the app shows up too late. Show the app earlier, or make the hook about the problem the app solves.

A mistake to avoid: judging the whole channel on the first five posts. New accounts often start slow, and most posts on any account land well below its best. Commit to a month of daily posts before you decide TikTok "doesn't work" for your app.

Another one: reusing the exact same hook word for word across many accounts. It goes stale fast. Rewrite the first line every time, even when the rest is the same.

When paid ads or creators are the better choice

Organic is slow and uneven. Pay instead, or as well, when:

You need results this month. Ads buy reach on a timeline; organic doesn't promise one.
You already have a post that converts. Running a proven organic post as an ad is a much safer bet than paying for a cold one.
Your app sells on trust. Health, finance and coaching apps often need a real person on camera. If that isn't you, paying creators makes sense.
You have budget and no time. Organic costs hours every day. If your hours are worth more than the ad spend, pay.

For most solo developers with no ad budget, organic first is the right order. It finds the format, then money scales it.

Where Sendhour helps

Everything above works by hand. Sendhour does the slow parts of the loop:

Finding breakouts. The viral library collects TikTok posts from the last 30 days with at least 50,000 views and at least 3 times their account's usual views, plus YouTube Shorts, grouped by niche. It's step 2 done for you every day.
Making your version. The studio copies a post's structure and hook, as a slideshow from real photos for 1 credit, or as a short video from real clips with a voiceover for 4 credits a render. It never reuses the original footage.
Posting on a schedule. One calendar for many accounts across TikTok, YouTube, Instagram, Threads, Bluesky, X and LinkedIn, through each network's official API.
Ideas each morning. Autopilot prepares 1 to 3 drafts a day on paid plans. At first nothing posts until you render and schedule it. Once an account's last 10 drafts went out without edits, you can let autopilot post them for that account, each scheduled at least 2 hours ahead with an emailed link to cancel it.
Watching rivals. Add the accounts you compete with and see each one's posts that beat its own usual views, ready to remake.
Showing the app. Give Sendhour your App Store or Google Play link and it saves your app's screenshots; every slideshow can then show one in a phone frame on its last slide, free. With autopilot on, it also drafts a post when you ship a new release.
Measuring. Analytics for your own accounts, including TikTok posts made outside Sendhour.
Agents. Everything works from the AI of your choice through the API, MCP server and CLI, so an agent can read your numbers and draft next week's posts. Connect it with drafts only and nothing goes out until you approve it.

Teammates are unlimited on every plan, each with their own sign-in and a role, so a helper can make drafts without being able to publish. What it doesn't do: no paid ads. Plans start at $29 a month for 5 accounts; 15 accounts are $49. See pricing.

Questions

How long does organic TikTok take to work for an app?

Plan on weeks, not days. Give one format three to four weeks of daily posts before you judge it. Most single posts tell you very little; a run of 20 or 30 shows which hooks get watched.

Do I need to show my face?

No. Photo slideshows, screen recordings and voiceover videos all work without a face, and they are the easiest formats to make every day. If your app sells on trust, like coaching or health, a real person on camera can help, and that is where hiring creators starts to make sense.

How many posts a day should I make?

One a day per account is a good start and easy to keep up. Consistency matters more than volume in the first month. Add a second account with a different angle before you add a second daily post.

Is it fine to copy a viral post?

Copy the structure: the hook pattern, the number of slides, the pacing, where the payoff lands. Never reuse someone else's footage, photos or words. Your version should be about your app and your users.

Should I post the same video on Instagram Reels and YouTube Shorts?

Yes, it costs nothing extra and each network finds a different audience. Change the caption to fit the network, and watch which one sends installs.

How to add customer support chat to an iOS app (2026)

Vidur Saini — Sat, 14 Nov 2026 17:30:03 +0000

This guide was originally published on the Hailbell blog.

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.

Turn on the Push Notifications capability in Xcode for the app target.
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.
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.

How to add customer support chat to an Android app (Kotlin, 2026)

Vidur Saini — Fri, 13 Nov 2026 06:42:51 +0000

This guide was originally published on the Hailbell blog.

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:

Open chat from each entry point and send a message.
Confirm the message arrives with version, device and plan attached.
Sign in on a second device and confirm the same conversation appears.
Force-stop the app, reply from your side, and confirm the push arrives on the "Support replies" channel.
Tap the notification and confirm it opens the conversation.
Deny the notification permission and confirm chat still works with an unread badge.
Sign out and confirm the next user doesn't see the previous conversation.
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.

How to post your release notes to X, LinkedIn, Threads and Bluesky from Claude Code

Vidur Saini — Fri, 13 Nov 2026 06:41:54 +0000

This guide was originally published on the Sendhour blog.

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:

Level	What the agent can do	When to use it
Read only	List accounts, scheduled posts and analytics	Asking "what's going out this week?"
Drafts only	Everything above, plus create drafts you approve	Your default for launch posts
Full posting	Schedule and cancel posts that go out without a check	Repeat jobs you've already reviewed a few times

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:

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.
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.

Network	Text limit	Notes
X	280 characters per post	X weights some characters, such as many emoji, more heavily and counts links at a fixed shortened length. See Counting characters.
Threads	500 characters	Meta's API docs note that emoji are counted by their UTF-8 bytes. See Threads posts.
Bluesky	300 graphemes	Set in the `app.bsky.feed.post` lexicon; a proposal to raise it was opened in June 2026, so check the current limit before relying on more room.
LinkedIn	3,000 characters	See LinkedIn's Post and share updates help page.

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:

Read every draft against the changelog. Anything that isn't in the changelog comes out.
Check the accounts. If you run more than one X account, make sure the draft is on the right one.
Check the time. Open the scheduler's calendar and confirm the posts sit where you expect, in your time zone.
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:

Networks. Does it cover every network you post to, through the official API?
Permission levels. Can you give the agent drafts-only access?
Duplicate protection. What happens when a send fails halfway?
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.

DEV Community: Vidur Saini

How to market your app on TikTok without ads or creators

Why organic TikTok works for apps

The playbook, step by step

What to measure and what to repeat

When paid ads or creators are the better choice

Where Sendhour helps

Questions

How long does organic TikTok take to work for an app?

Do I need to show my face?

How many posts a day should I make?

Is it fine to copy a viral post?

Should I post the same video on Instagram Reels and YouTube Shorts?

How to add customer support chat to an iOS app (2026)

1. Decide where the button lives

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

3. Pass context with every chat

4. Push the reply, or nobody sees it

5. Decide who answers, and when

6. Handle privacy and account deletion

7. Test on a real iPhone

The mistake to avoid

Where Hailbell helps, and where it doesn't

Questions

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

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

Do push notifications for chat replies work in the simulator?

Should an AI answer support chats in my app?

Which support chat SDKs work in a native iOS app?

How to add customer support chat to an Android app (Kotlin, 2026)

1. Decide where the chat lives

2. Initialize once, in Application.onCreate()

3. Identify users without letting anyone impersonate them

4. Send context with every conversation

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

6. Let users delete their data, chat included

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

8. Test the whole loop before release

Which SDK should you use?

Wrapping up

How to post your release notes to X, LinkedIn, Threads and Bluesky from Claude Code

What you need

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

Step 2: Connect the MCP server to Claude Code

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

Step 4: Respect each network's limits

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

Guardrails worth setting up

Which scheduler should you use?

Wrapping up

2. Initialize once, in `Application.onCreate()`