DEV Community: mogee

My App Got Rejected for "Device Automation" on Google Play — Here's What I Had to Do

mogee — Tue, 24 Mar 2026 13:12:52 +0000

I built a small Android app called ALL SMS — it automatically forwards incoming SMS messages to a phone number, email, or webhook. Simple concept, clear use case. Then Google Play rejected it.

The rejection email cited the Device Automation policy, but the explanation was vague enough that I genuinely had no idea what was missing.

What is Google Play's Device Automation Policy?

The policy applies when your app performs automated actions on the device without direct user input — things like forwarding SMS, sending emails, triggering webhooks, or saving files automatically.

Google's stance: "You must clearly describe every automated action your app performs, and users must be aware of and consent to it."

Fair enough. But my app already had an SMS forwarding feature front and center. So what was wrong?

I Went Straight to Google

Instead of guessing, I submitted a support inquiry through the Play Console. After some back and forth (with help from a specialist), I got the real answer:

To qualify as a Device Automation app, your app must include at least 4 OS-level automation actions.

This isn't clearly stated in the public docs — at least not that I could find. But that was the benchmark. My app technically had automated features, but one was partially hidden in the UI and the implementation wasn't complete enough to count. I was sitting at 3.

What I Built to Fix It

I went back and made sure 4 clear, working automation actions were front and center in the app:

Forward SMS to a phone number — the core feature, always worked
Forward SMS to email — via SMTP or Gmail OAuth
Send SMS to a webhook (HTTP POST) — great for Slack, Zapier, custom servers
Auto-save SMS to CSV (newly added) — with a built-in in-app CSV viewer

Each one visible, documented, and clearly explained in the UI.

Key Takeaways

If you're building an app that touches device automation on Android:

You need at least 4 OS-level automation actions — this was confirmed by Google support, not public docs
Every automated action must be clearly visible in your UI, not buried in settings
Your demo video matters — show each automation actually running
If the rejection reason is vague, ask Google directly via Play Console support. It's the fastest way to get real criteria

The rejection was frustrating, but it pushed me to build a better app. The CSV feature I added is now one of the more useful parts of it.

Try ALL SMS

If you're looking for a simple, no-frills SMS forwarder for Android:
👉 Play Store — ALL SMS

I Built an Open-Source Bridge That Turns Claude Code Into a REST API

mogee — Mon, 23 Mar 2026 03:50:40 +0000

Why I Built This

If you're already paying for Claude Code (Max plan), you have access to an incredibly powerful AI right in your terminal. I wanted to get more out of that subscription — use it from my web apps, Slack bots, CI pipelines, and Python scripts running on other machines.

Anthropic does have an official API, but it's pay-per-token — a separate cost. Since I'm already paying for a subscription, I figured: why not use what I've got?

There are some great open-source wrappers like coder/agentapi and claude-code-api, but they're designed for local use only. I needed something that works remotely too — without having to set up reverse proxies, TLS certificates, and authentication from scratch.

What It Does

claude-api-bridge lets you use your existing Claude Code subscription as a REST API, accessible from anywhere.

One command. That's it.

npx claude-api-bridge start

And you get:

✅  Claude Code CLI detected
🚀  API server running on http://localhost:3456
🔑  Admin Token: cab-a1b2c3d4e5f6...
🌐  Public URL: https://random-words.trycloudflare.com

Now you have a real HTTPS endpoint that you can call from any app, anywhere in the world.

How It Works

Your App (anywhere on the internet)
    │
    │ HTTPS
    ▼
Cloudflare Tunnel (automatic SSL, zero config)
    │
    ▼
claude-api-bridge (your desktop)
    ├─ Token Authentication (SHA256)
    ├─ Request Queue
    └─ Claude Code CLI (your subscription)

Your desktop becomes the API server. Claude Code runs locally using your existing subscription. Cloudflare Tunnel handles the networking — no port forwarding, no ngrok, no reverse proxy setup.

Key Features

Feature	Details
🚀 One-command setup	No config files, no environment variables
🌐 Remote access	Cloudflare Tunnel with automatic HTTPS
🔑 Token management	Create, revoke, expire. SHA256 hashed — never stored in plaintext
💬 Session modes	Stateless (fresh each time) or Stateful (conversation memory)
📊 Web dashboard	Monitor at `/dashboard`
🔒 Secure	Rate limiting, CSP headers, execution timeout, output size limits
💾 Zero dependencies	SQLite for storage — no Redis, no Postgres

Quick Example

Python

import requests, time

BASE = "https://your-url.trycloudflare.com"
TOKEN = "cab-your-token"
H = {"Authorization": f"Bearer {TOKEN}", "Content-Type": "application/json"}

def ask(msg):
    r = requests.post(f"{BASE}/api/ask", json={"message": msg}, headers=H)
    rid = r.json()["requestId"]
    while True:
        p = requests.get(f"{BASE}/api/ask/{rid}", headers=H).json()
        if p["status"] == "completed": return p["response"]
        time.sleep(2)

print(ask("Write a function to check if a number is prime"))

JavaScript

async function askClaude(message) {
  const res = await fetch(`${BASE_URL}/api/ask`, {
    method: "POST",
    headers: { Authorization: `Bearer ${TOKEN}`, "Content-Type": "application/json" },
    body: JSON.stringify({ message }),
  });
  const { requestId } = await res.json();

  while (true) {
    const poll = await fetch(`${BASE_URL}/api/ask/${requestId}`, {
      headers: { Authorization: `Bearer ${TOKEN}` },
    });
    const data = await poll.json();
    if (data.status === "completed") return data.response;
    await new Promise(r => setTimeout(r, 2000));
  }
}

How It Compares

Feature	claude-api-bridge	coder/agentapi	claude-code-api
Remote access (HTTPS)	✅ Built-in	❌ Local only	❌ Local only
Token management	✅ Full CRUD	❌ None	⚠️ Static keys
Token security	✅ SHA256 hash	❌ N/A	❌ Plaintext
Session persistence	✅ SQLite	❌ In-memory	⚠️ In-memory
Crash recovery	✅ Auto	❌ No	❌ No
Zero config	✅ One command	✅ One command	⚠️ Config needed

Limitations (Being Honest)

Your desktop must be running — Claude CLI executes on your machine
One request at a time — Claude CLI is single-threaded, requests are queued
Free tunnel URL changes on restart — use a Cloudflare account for a fixed domain
Response time varies — typically 10 seconds to 2 minutes depending on the task

Try It

npx claude-api-bridge start

GitHub: github.com/smy383/claude-api-bridge
npm: npmjs.com/package/claude-api-bridge

Star ⭐ if you find it useful!

Built by the team behind ttapp — the mobile remote for Claude Code.

I built a community where your AI assistant is the only interface

mogee — Sat, 21 Mar 2026 02:51:58 +0000

Most developer communities are built for humans.

Obvious, right? But think about what that actually means: a browser, a UI, a login page, buttons to click. Everything optimized for human eyes and fingers.

I took a different approach with Maxpace: a developer community where your AI assistant is the interface. No web frontend. No mobile app. No dashboard to log into.

How it works

Maxpace exposes a remote MCP server. You connect your AI (Claude, or any MCP-compatible agent) to it with a single URL, and then just... talk.

Want to post something? Ask your AI. Want to search for discussions about a specific topic? Ask your AI. React, comment, join a meetup — all through your AI assistant.

claude mcp add maxpace --transport http https://[region]-[project].cloudfunctions.net/mcp

That's the entire setup. The AI becomes your community client.

Why no UI?

I kept asking myself: if AI assistants already read my PRs, write my docs, and manage my tasks — why aren't they participating in the communities I care about?

Developer communities are where knowledge lives. But getting that knowledge into your AI's context meant copy-pasting, screenshotting, link-sharing. It felt backwards.

So I flipped it: design the community for AI-mediated access from day one.

Authentication — no passwords, no browser

When you register via MCP, you get a token back in the response. That's it.

No email verification flow, no OAuth dance, no redirect URIs. The token is also sent to your email as a backup. Web-redirect-based auth requires a browser — Maxpace doesn't have one, so this approach felt natural.

Semantic search, not keyword matching

Every post gets an embedding on write. Search finds what you mean, not just what you typed.

Search for "handling async errors gracefully" and you'll find posts that never used those exact words. This works especially well in an AI-native environment where the search query itself is often generated by the AI from your natural language.

What it feels like

I use Claude Code daily via a mobile remote I built. So I interact with Maxpace the same way — from my phone, through Claude:

[me] → "Post something about stateless API design"
[Claude] → calls node_write tool
[Maxpace] → stores, embeds, returns post
[Claude] → "Posted! 3 people already bookmarked a similar post..."

The community lives inside my AI workflow, not outside it. That's the shift.

Try it

Maxpace MCP is public. The README has everything you need to connect:

👉 github.com/smy383/maxpace-mcp

Curious whether this resonates with other developers — or whether this is a solution looking for a problem. Drop a comment either way. 👇

I built a mobile remote for Claude Code — here's how

mogee — Sun, 01 Mar 2026 01:43:03 +0000

If you've used Claude Code, you know how powerful it is.

But there's one problem — you're chained to your desk.

What if you could send Claude Code commands from your phone, get real-time responses, and keep working from anywhere?

That's exactly why I built ttapp.

The Problem

I kept having ideas while commuting, lying in bed, or grabbing coffee. By the time I got back to my desk, the momentum was gone.

Claude Code is incredible — but it lives on your desktop. And your desktop doesn't fit in your pocket.

What ttapp Does

ttapp connects your mobile phone to your desktop Claude Code session in real time.

Type a command on your phone
Claude executes it on your desktop
Results stream back to your mobile instantly

No VPN. No SSH. No complicated setup.

How It Works

The architecture is surprisingly simple:

Mobile (Flutter) → Firestore → Desktop (Tauri)
                                     ↓
                               Claude Code CLI
                                     ↓
Mobile (Flutter) ← Firestore ← Results

Mobile writes a message to Firestore
Desktop listener picks it up instantly
Claude Code runs with --resume for session continuity
Results stream back to mobile in real time

Tech Stack

Mobile: Flutter (iOS + Android)
Desktop: Tauri v2 (macOS, Windows, Linux)
Backend: Firebase (Firestore + Cloud Functions)
Bridge: Claude Code CLI with session resume

What You Can Do With It

🔧 Fix bugs while commuting
📱 Review code from your couch
🌙 Send a quick command at midnight
☕ Check build status over coffee

Try It Free

ttapp is free to start — no credit card needed.

👉 ttapp-remote.com

Available on iOS, Android, macOS, Windows, and Linux.

Would love to hear your thoughts — what would you add to a tool like this? 👇

I Built a "Give & Take" Feedback App Because Nobody Was Reviewing My Side Projects

mogee — Thu, 05 Feb 2026 04:08:48 +0000

The Frustrating Reality of Indie Development

I've shipped a few apps as a solo developer. Getting downloads? Possible with
some marketing. But getting real, actionable feedback? Nearly impossible.

App store reviews are mostly "great app" or "doesn't work" - nothing in
between. I tried posting on Reddit, Twitter, and Discord communities.
Sometimes I got lucky, but most responses were just polite encouragement, not
the honest critique I needed.

I realized other indie developers probably felt the same way.

## The Idea: What If Feedback Was a Trade?

I thought about how feedback works in creative communities. Writers have beta
readers. Designers have critique circles. Why don't indie developers have
something similar?

So I came up with a simple concept:

Give feedback → Get visibility

The more detailed feedback you provide to others, the more your own app gets
promoted to the community. It's like a mutual aid system - everyone helps
everyone.

I called it FeedApp (품앗이 피드백 커뮤니티 in Korean, which roughly
translates to "mutual help feedback community").

## How It Works

Register your app/web/game with screenshots and description
Browse other creators' projects and leave detailed feedback
Earn visibility - your project gets shown to people you helped
Receive feedback from other creators who understand the struggle

There's also a "feedback rate" system - if you don't reciprocate within 10
days, your rate drops. This keeps the community active and fair.

## Tech Stack

| Layer | Technology |
|-------|------------|
| Frontend | Flutter (iOS, Android, Web) |
| Backend | Firebase (Firestore, Cloud Functions) |
| Auth | Google, Apple, Kakao Sign-in |
| Push | Firebase Cloud Messaging |
| i18n | 4 languages (KO, EN, JA, ZH) |

I chose Flutter because I wanted to ship on all platforms with one codebase.
Firebase made the backend simple enough for a solo developer to manage.

## Challenges I Faced

1. Preventing "low-effort" feedback

Early on, I worried people would just write "nice app" to game the system. I
added a 30-character minimum requirement, but the real solution was the
community itself - creators naturally want quality feedback, so they give
quality feedback.

2. The "cold start" problem

A feedback exchange only works if there are people to exchange with. I
initially seeded the platform with my own projects and invited developer
friends. It's still small, but growing organically.

3. Cross-platform auth headaches

Implementing Kakao login (popular in Korea) alongside Google and Apple across
iOS, Android, AND web was... painful. Each platform has its quirks.

## What I Learned

Start with the smallest possible loop. My MVP was just: register → browse → feedback. Everything else came later.
Community moderation matters early. Even with 50 users, you need clear guidelines.
Solo development is lonely. Ironically, building an app about feedback made me realize how much I needed feedback myself.

## Current Status

~100 registered services
Web is live, mobile apps under review
Still early, but the core loop is working

## Try It Out

🌐 Web: feedapp-prod.web.app ← Live now!
🤖 Android: Under review (coming soon)
🍎 iOS: Under review (coming soon)

You can register your service on web first - it'll sync when the mobile apps
launch!

## I'd Love Your Feedback (Ironic, I Know)

Does this concept make sense?
Would you use something like this?
Any features you'd want to see?

As a solo dev, every bit of feedback helps. Thanks for reading! 🙏

If you're also an indie developer struggling to get feedback, let's connect.
Drop a comment or find me on the app!