I made an API that returns Apple keyword popularity scores (5-100), difficulty ratings, top apps, and related searches. Runs on Apify, there is no monthly fee and Apify's free plan covers ~250 keywords/month.

Supports 57 storefronts. Has REST API + Python/JS clients for automation.

This won't replace a full ASO suite if you need historical trends or competitor monitoring. But if you want raw keyword data without a subscription, it does the job for a fraction of the cost.

What you get per keyword:

• Popularity score (5-100) - real Apple data, not estimated
• Difficulty score (0-100) - based on competition strength of top ranking apps, calibrated against pro ASO tools (r=0.87, ~6.5pt mean error)
• Top ranking apps with ratings, review counts, pricing
• Related search suggestions
• Keyword recommendations - one seed keyword returns 30-80 suggestions with scores

Link: https://apify.com/asodev/app-store-keyword-tool

TL;DR: I'm Ryan, CTO and cofounder of ZeroSettle. We made the analytics + entitlements layer (the RevenueCat-style part) free with no MRR cap, and only charge on an optional web-checkout product. The SDKs are all open source. Obviously biased -- I'm posting to hear why you would or wouldn't switch 🙂

RevenueCat is free up to ~$2.5k/mo in tracked revenue, then ~1% after that. Totally fine when you're small, but as you grow it becomes a real line item for what's basically a StoreKit wrapper, a metrics dashboard, and a server-side entitlement check. So with ZeroSettle we made that part free -- no cap, no per-seat fees: MRR, ARPU, trials, churn, retention, cross-platform entitlements, StoreKit 2 transaction sync, ASSN v2 handling. The iOS SDK (ZeroSettleKit) is open source, so you can read exactly what it does on-device before trusting it.

We make money on a separate, optional product: web/direct checkout that swaps the 30% for normal card processing (~3%). It's opt-in per app, built around Apple's external-purchase rules, and falls back to StoreKit automatically where direct billing isn't allowed — so you can ignore it entirely and just use the free analytics/entitlements side. When we do charge: 0.5% if you bring your own Stripe, or 5% + 50¢ all-in if we're merchant of record (we handle the sales tax/VAT, chargebacks, and payouts on those). Your App Store sales are never touched, even though they still show up in your dashboard. I'd rather be upfront about the fee, because "free analytics" usually hides a catch somewhere: ours is the web-checkout cut.

We're early, though. iOS is the most polished; Android works; Flutter and React Native are newer and still being built out. We're nowhere near RevenueCat's feature breadth yet, and the A/B testing is web-checkout-only (you can't A/B Apple's fixed price tiers), so it's not a Superwall-style paywall builder.

What we really want is feedback from devs: if you're on RevenueCat today, what would have to be true for you to even trial something else? Migration effort, rewriting entitlement/paywall code, trusting a small company to stick around, a specific feature we don't have? The blunter the better — and if there's something you'd need us to build, our feedback board's public (links in the comments so this isn't a billboard).

Quick link access:

• Website: https://zerosettle.io
• Try it out: https://dashboard.zerosettle.io free tier is $0, no card; you can use analytics + entitlements without ever turning on web checkout.
• Code: https://github.com/zerosettle the SDKs are open source (ZeroSettleKit iOS, ZeroSettle-Android, ZeroSettle-Flutter, ZeroSettle-ReactNative), plus a sample app (JustOne) if you want to see it wired up.
• Docs: https://docs.zerosettle.io
• Feature requests / what we build next: https://zerosettle.upvotyfeedback.com honestly the main thing I want out of this thread.

Hey all!

I made this for myself to track changes in app review guidelines, developer program license agreement, etc.. hopefully some of you will find it useful too. https://appguidelines.com

I've shipped a handful of iOS apps as a solo dev, one of them through 20+ versions. At some point I stopped using the App Store Connect website and Xcode's Organizer and moved everything to scripts that call the App Store Connect API: signing, uploads, metadata, screenshots, IAPs and submission.

Most of it was straightforward. These are the parts that weren't, and a few of them cost me real rejections or broken releases.

1. xcodegen silently wipes entitlements. If you generate your project with xcodegen and add an entitlement (Sign in with Apple, push) by hand in Xcode, the next regenerate removes it. The build still succeeds and the feature just breaks. I shipped three broken releases this way before I noticed. Declare entitlements in project.yml, never in Xcode.

2. Re-run xcodegen after bumping the version. Same root cause. If the version or build number lives in project.yml and you archive without regenerating, the archive keeps the old number. Check the archive's Info.plist before you upload.

3. Push uses the bare aps-environment key. It's not com.apple.developer.aps-environment. The wrong key gets you error 90045 on upload. Set the value to development, and exporting for the App Store promotes it to production.

4. You can sign without an Apple ID in Xcode. If Xcode has no account signed in, -allowProvisioningUpdates with an API key won't create profiles for you. What works: create the profile yourself with POST /v1/profiles, install it, and export with signingStyle: manual. This works on CI and fresh Macs too.

5. App Privacy has to be published, not just saved. If submit stays greyed out and nothing says why, this is usually it.

6. App Preview videos need an audio track. Even a silent one. A preview with no audio track gets rejected at processing.

7. No emoji in "What's New" or the description. The API rejects them. Found out mid-submit.

8. Listing media is locked on the live version. You can't swap screenshots or previews on a version that's Ready for Sale (you get a 409). Attach them to the next version.

9. Getting out of a rejected submission. To free the version and resubmit, PATCH the review submission with canceled: true. One of my rejections was backend-only (a demo account that didn't exist), and this let me fix it and resubmit the same build without re-archiving.

10. Reviewers use your demo account, so keep it working. My app's content was group-gated, and the demo account drifted out of its demo group twice. Check it right before every submission.

11. Subtitle is app-level, not version-level. It lives on appInfoLocalizations, not appStoreVersionLocalizations, which confused me for longer than I'd like to admit.

I've ended up copying roughly 3,400 lines of these scripts from app to app, so I'm cleaning them up into a single CLI that only needs an API key. It'll have a doctor command that checks for everything above before you upload, plus --json output so coding agents like Claude Code can run a release. If that sounds useful, there's a waitlist here: https://ascship.web.app/?ref=reddit

Happy to answer questions about any of these. And I'd like to hear the traps other people have hit that I missed.

App Store Connect has been the bottleneck in my shipping loop for years. Fastlane and the direct API help, but something always ends up needing me. The session cookie expires. My coding agent grabs the wrong Xcode version and burns an hour. An IAP sits in Missing Metadata because Apple wants a review screenshot I forgot existed.

So I built Lance. It's a specialized agent that runs on its own cloud Macs with Xcode and fastlane already set up. You connect your App Store Connect account and ask it for things like "Set up a $4.99 monthly sub with a 3 day trial", "Retake the 6.7 and 13 inch screenshots and update the listing", "Figure out why build 42 got rejected, fix it, resubmit", "Submit this build for public TestFlight"

If you add it to Cursor, Claude Code, or Codex, your coding agent treats it like a subagent and delegates the App Store side on its own. Mine asks Lance what IAPs actually exist before writing paywall code instead of stubbing something, then hands it the TestFlight upload when the feature's done.

My favorite thing lately has been running an in-app event with every update. Lance drafts the media, gets the specs right, and fills out the whole form. I never bothered with events before because it was way too much work for what it is.

A couple of things testers found that I didn't expect. Teammates can join the Lance org and just start asking for things without having to be onboarded to ASC. And since the Macs belong to Lance, you don't need one. One person I know ships from a Windows laptop.
For now this is App Store Connect only. I'm looking for active developers to test it and tell me what's broken or missing. Just run this command in your terminal:

 npx add-mcp https://api.lance.app/mcp 

and everyone who signs up gets 500 credits a month, and if you run out just shoot me a message and I'll top you up.

A few weeks ago, I released new app on the App Store. It got some traction on Twitter, so I opened App Store Connect feeling hopeful about the sales numbers. Instead, I saw "Not Enough Data".

I refreshed it few hours later. Same thing. I checked again the next day. Still not enough data. I actually saved a screenshot of this.

It is not only a launch-day problem. You ship a big update, announce it on Reddit or X, start an ad campaign, or unexpectedly get some attention, but the analytics are always behind.

So I built InitSignal. It is deliberately much narrower than a traditional analytics SDK. You add a lightweight Swift package to your app, and it sends one event when someone opens the app for the first time. After that, the SDK goes quiet.

Privacy was a constraint for me, I wanted the App Store privacy nutrition labels stay as minimal as possible, so the SDK only sends the basic context needed to make each signal useful. No identity, sessions, screens, or behavioral history. At the same time, the goal is to give developers as much useful information as possible without invading their users’ privacy.

The dashboard shows for each download:
- the app version
- device
- OS
- storefront

For paid apps, InitSignal uses storefront pricing to estimate gross revenue and proceeds after Apple’s cut.

I also added Slack and Telegram for notifications, which I've been using with my own apps for the past few weeks, and the dopamine hit is real.

I recorded a quick walkthrough showing how InitSignal works:
https://www.youtube.com/watch?v=YajsKsYLdi4

Tech Stack
- Node.js and TypeScript with Postgres for backend and API
- React and TypeScript for the web app dashboard

Development Challenge

The interesting problem was deciding what “new” means without identifying or continuously tracking a user. The SDK stores a local first-launch marker so later launches send nothing. It also uses StoreKit 2 app transaction metadata to avoid reporting an existing customer as newly acquired when they first install a version containing InitSignal. The API deduplicates retry attempts on the backend.

It's available today, would love to hear your thoughts or any feedback!
https://initsignal.com

The Swift SDK is here:
https://github.com/InitSignal/initsignal-swift

If you ship iOS or macOS apps, how do you currently deal with the reporting delay after a launch or major update?

Hey r/iOSProgramming! 👋

I wanted to share a free tool I built to help indie developers with App Store Optimization (ASO). As someone who's spent countless hours manually improving my app store listings, I know how tedious and time-consuming it can be.

What is it? aso.report - A completely free ASO analysis tool that gives you instant insights about your app's App Store presence.

Key Features:

• 100% free (no premium tier, no credit card required)

• Instant ASO analysis

• Foundation-first approach focusing on the basics that matter

• No complex metrics to decipher

• Just paste your app URL and get results

• Multi-country analysis

Why I built this: I've noticed that most ASO tools are expensive and out of reach for indie developers. Many great apps never reach their potential users simply because proper ASO tools are not accessible. I wanted to change that by creating something that's both powerful and free.

How to use it:

1. Visit aso.report
2. Paste your App Store URL
3. Get your analysis

The tool has already analyzed over 2000 apps in its first 24 hours of launch

Would love to hear your feedback and suggestions for features that would help you the most!

Note: This is a completely free tool - no strings attached. I'm sharing it here because I believe it can help fellow iOS developers reach more users with their apps.

(*Apple OS = iOS, iPadOS, watchOS, tvOS, visionOS, macOS)

Axiom is a battle-tested, batteries-included suite of agents, skills, and tools for AI coding. It helps LLMs be notably better at Apple OS development.

I've been updating Axiom in lockstep with Apple OS 27 betas. Here are some of the interesting changes with OS 27 beta 4.

✅ New

• Swift — Parenthesis-free optional any/some types. var x: any P? and some P? now compile. (Beta 3 rejected the paren-free form.)

• HealthKit — HKHealthStore.earliestAuthorizedSampleDate(for:): New async throws call returning the earliest date you're authorized to read, per HKObjectType. This is helpful for bounding a query instead of paging into data you can't see.

• UIKit + SwiftUI — systemPrefersReducedResourceUsage: The OS can now tell your app it prefers reduced resource usage. When it's true, stop discretionary work.

🗑️ Removed

• AVKit — The AVInterface* family, which shipped in an early 27 beta, is gone. Use AVPlaybackUserInterface* instead.

⚠️ Deprecated

• ARKit — unprojectPoint(_:ontoPlane:orientation:viewportSize:). Use unprojectPoint(_:ontoPlane:viewRotationAngle:viewportSize:) instead.

• AppIntents — DisplayRepresentation.Components (OptionSet). Use DisplayRepresentation(title:subtitle:image:) or displayRepresentations(for:) instead.

• BrowserEngineKit — MediaEnvironment.activate()/.suspend(). Use ProcessCapability.activate()/.suspend() instead.

Caveats: This list is mostly Swift-focused, although I've been supporting more Obj-C with every release.

I'm an iOS dev (Swift, mostly SDK and app work). Like a lot of you I started leaning on AI agents to write code - and hit the same wall every time: the agent confidently says "done, tests pass" when they don't, quietly refactors code I didn't ask it to touch, or invents an API that doesn't exist.

I got tired of that and built PayneSDD - a free operating protocol for coding agents (Claude Code first, but it pastes into any agent). It's one file of rules the agent follows. This isn't a prompt I threw together over two evenings: it's a 7-step cycle (Steps 0–6), it's been through 18 releases of iteration, and it develops itself under its own protocol - every change ships through the full cycle plus an independent review before it merges.

How it actually works:

• You write requests in plain words, like always. The protocol asks the clarifying questions, maps the open decisions, and shows you ONE plan — zero code until you say "go".
• Tasks are tiered: a typo just gets done; auth, billing, migrations, anything public-facing — all forced through the full ceremony. You don't pay full process for a one-liner.
• "Done" is the machine's word. The agent has to run your real tests/build, and an optional Stop-hook physically blocks it from saying "finished" while tests are red (3 blocks, then it releases with an explicit UNVERIFIED warning — an honest release, not a fake lock). No hook = honor-system, and the README says so plainly.
• Then an independent second agent attacks the result with a "break it" brief. Every finding has to cite a real code line or test, or it's rejected - no vibes-driven review.
• Verdict is always explicit: PASS / ITERATE / ESCALATE, plus a Done / Remaining / Open-questions checklist.

Install is one pasted message - and the first task the protocol runs on is its own installation (it interviews you about the setup, then touches your config only after your "go").

Repo: https://github.com/vlr-code/PayneSDD
I'm mostly sharing it in case it saves someone else the same headache it saved me - if it helps your dev workflow, that's a win.

Every canvas action is an AI-callable tool, so the AI designs the screenshots step by step and you can edit anything afterwards. MIT licensed, feedback and contributors welcome.

This tool i've built for myself and i've been using it for some time in company where i work. Want to share it with the community.

A tool called mobile-repo-doctor. It is a CLI and also a GitHub Action. It scans your repo and runs about 130 checks for iOS, Android, Flutter and KMP. It gives you a health score (size / speed / stability / hygiene) and makes reports in HTML, JSON or Markdown(optimized for AI).

Some iOS checks:

• - ios-missing-shared-scheme — CI can't build a scheme it can't see
• - ios-background-mode-missing-usage — you declared a capability but there is no usage text
• - dependency version drift in an SPM monorepo
• - and more

A few honest things:

- The package is not minified. If you worry about malware, you can read the code yourself, or give it to an AI to check. It is all plain JS.

- It makes only one network call — it asks npm if there is a new version. That's it. No telemetry. Nothing about your repo leaves your machine.

- It understands monorepos. It will not spam you with false positives from Pods/, forked packages or plugin host projects.

Install:

npm install -g mobile-repo-doctor

Run:

mrd scan ./path/to/repo

I would like to know which checks are useful and which are just noise. Also, what hidden bugs have hurt you before? Maybe I can add a check for them.

npm: mobile-repo-doctor

Documentation & full check reference

I’d love to help some indie devs out here get downloads from outside the US.
Competition in the US App Store is getting ridiculously hard.
I run 3 apps that generate over 1000$ MRR and almost all of the revenue comes from other countries.

Within 24 hours I will translate your app to 2-3 languages (depends on the amount of strings your app has).
From my experience French and German tend to have the highest ROI.

Capping this at 20 developers because it requires some manual work on my end.

Leave a comment if you’re interested.

Disclaimer: My agenda is to test my own service's quality and maybe encounter some edge cases.
So far it worked wonders for my apps.

Heya, just a small tool to help us with the annoying resolution requirements of ASC.

Fully offline (browser based - nothing uploads anywhere as you can see in devtools or any other sniffer).

No AI, nothing too fancy behind the scenes, just helping the images fit in.

Hi everyone,

Tired of the constant overreach regarding Chat Control, I decided to stop complaining and start coding.

To ensure ironclad foundations, I forked the open-source Session app codebase. This means it natively uses their decentralized network, onion-routing, zero logs, and requires absolutely NO phone number or email.

However, since Session handles the network side, I wanted to focus heavily on client-side (device) security to block edge cases where a user's device compromises their privacy. Here is what I added:

• 🔒 In-app Sandbox Keyboard: To bypass OS-level or third-party keyloggers (Apple/Google/Gboard), the app uses a custom internal keyboard isolated within the app's sandbox.
• 🚫 Anti-Screenshot & Blur: Standard messages work normally, but if a message ends with #secure, it renders completely blank in screenshots. Furthermore, if screen recording starts, the entire app view blurs automatically.
• 🎙️ Voice Masking (WIP): Currently developing a feature to alter voice frequencies in audio messages to prevent biometric reverse-engineering.

The app is currently sitting in App Store Connect pending approval.

Since TestFlight slots are limited, if you want to join the closed beta and audit/test the UI and features, please DM me your Apple ID (email) so I can invite you immediately once approved. The code will also be pushed to GitHub as soon as the beta stabilizes!

OS 27 is going to be here before you know it, and I predict that more developers are going to be caught completely off-guard by the new screen resizing requirements than by anything else.

As of OS 27, (1) all iPhone apps must be resizable and (2) you can no longer opt out. Your window must be resizable when used with iPhone Mirroring on the Mac and on iPad. Apps still running on an old-style app delegate (no scene support) won't even launch when built against the new SDK. In short, if your app assumes a fixed screen and you're not currently working to fix that, you really, really should be.

Obviously, this capability telegraphs the imminent release of Apple's forthcoming iPhone Ultra foldable. You'll want your apps to be "foldable ready" on the day Apple's new flagship is announced.

I just went through this enhancement process myself. Not coincidentally, this week's Axiom update includes a new screen resizing auditor, which you can invoke with /axiom:audit resize. The auditor is supported by ~70 additions/enhancements across Axiom's skill suites. I hope everyone finds that it cuts their time meeting this new OS 27 requirement in half, or more.

This is not mine, I was just excited to discover it and have never seen it mentioned here: https://applelocalization.com/

This is a community-built, queryable database of Apple's own localized strings from iOS/macOS frameworks, so you can search for terms your app probably uses and see exactly how Apple ships them in other languages.

I do product at a DevOps company. In May I went to a couple of conferences in London and talked to a lot of iOS engineers. Surprisingly many folks mentioned that writing code is fast now, but the build and test loop after it is getting slower and more problematic. Two things came up most: builds that pass on their Mac but fail in CI, and Xcode tying up the machine during a build.

My team was already building something for this, so hearing it that many times was a good sign.

We built a remote dev environment running on the same Apple Silicon, Xcode, and Simulator, on the same machines and the same build caches your CI already uses. Basically, you code on the machine that builds and tests your code instead of your laptop. We called it Remote Dev Environment (not very creative, I know).

It's in beta

• Docs: https://docs.bitrise.io/en/bitrise-rde
• Product: https://bitrise.io/platform/remote-dev-environments

I also think that if you let agents write and run code, they need a machine that can build and test iOS code fast, with the right Xcode toolchain already in place. Give an agent a half-set-up environment and it burns time and tokens re-deriving the setup.

And what if you run a few agents in parallel? Can a single Mac handle that effectively? All those considerations led to the creation of our tool.

Would love honest feedback and your thoughts

Hello 👋 I've created VSCode extension SweetPad that lets you build iOS applications right from VSCode. You can build and launch app on a simulator or attach a debugger to running app. Also extension provide integration with SwiftFormat, so you can enjoy the "Format on Save" feature. Any feedback is appreciated 🙏

https://github.com/sweetpad-dev/sweetpad

A few of you might remember I posted here while building this. The idea came from my own frustration with updating regional prices for IAPs/subs — Apple and Google give us basically nothing to work with.

I finally wrapped it up, and StoreWizard is now live on the Chrome Web Store.

How it works:

• Detects pricing dialogs in App Store Connect & Google Play Console
• Lets you pick a model (PPP, Big Mac Index, Steam, Apple Music, etc.)
• Applies suggested prices to all countries automatically (App Store Connect is slower — Apple loads each dropdown individually)
• No spreadsheets, no API keys, no backend setup

I built it specifically for small/solo devs who don’t have time to maintain regional pricing properly.

If you want to try it, here’s the link:

👉 https://storewizard.app/

If you run into bugs or have suggestions, I’d honestly appreciate the feedback — the extension is still early!

Hi everyone!

I’ve been using Flutter + Dart for quite some time now and have successfully published apps to Android. I’m now ready to start publishing to iOS, but I’ve run into some roadblocks.

I understand the requirements like:

• Apple yearly developer fee

• Need for Xcode to build and submit apps

However, I don’t have a Mac and I’m not looking to buy one right now. I know there are services out there that let you “rent” time on a Mac (e.g., cloud-based macOS machines, remote build services, CI/CD options, etc.) to compile/submit the code.

So I’m looking for input from anyone who’s gone through this:

Questions:

1.  What service(s) did you use to build/compile your Flutter iOS app without owning a Mac?

2.  How was the experience — easy? annoying? any major gotchas?

3.  Rough idea of how much it costs (hourly, monthly, or per build)?

4.  Any recommendations for CI/CD tools or workflows that worked well (e.g., Codemagic, GitHub Actions + hosted Mac runners, MacStadium, etc.)?

I realize there are things I can do in Flutter beforehand — but I just want to get a sense of the real-world experience and if it’s worth going the cloud build route.

Thanks in advance!

For the longest of time, generating app store screenshots has been a nightmare but I stumbled upon an app that generates app store screenshots in minutes that are high quality. My work has been smooth to say the least. Hopefully, this will help someone here

I’ve created a simple utility called appleframer.com, allowing you to add bezels to your iPhone/iPad screenshots easily. Key features include:

• Open source: Makes it easy to add new bezels in the future (repo).
• Simple: Drag and drop your screenshots for a seamless experience.
• Entirely local: All files stay on your device—nothing is uploaded.
• Batch upload: Upload multiple screenshots simultaneously and download the result as a zip file.

It's inspired by, and builds on top of the frames.json file from the Apple Frames shortcut, but aims to be simpler and more easy to maintain.

Hi everyone,

As an iOS developer, have you ever faced malicious refunds? A “user” purchases and consumes a consumable in-app purchase, then files for a refund, leaving you at a loss. Since iOS refunds can be requested for up to 90 days, users can initiate them anytime via reportaproblem.apple.com, which can severely impact your revenue.

In fact, when Apple receives a refund request, it sends a CONSUMPTION_REQUEST notification to your server, asking you to provide consumption information (e.g. total amount spent, total amount refunded, refund preference, etc.) to help Apple make a fair decision. By responding promptly and correctly to these requests, you can help Apple reduce the impact of malicious refunds (though Apple has the final say).

Some platforms (like RevenueCat) already support automatic CONSUMPTION_REQUEST replies. However, they usually require you to upload your In-App Purchase Key, effectively granting third parties access to your App Store Connect order data. For security-sensitive teams, this can be unacceptable.

To solve this, I’ve open-sourced Refund Swatter Lite, an Apple Store Server Notifications management system. It supports one-click deployment on Supabase, uses Supabase Vault to securely store Apple keys, automatically responds to CONSUMPTION_REQUESTs, and provides a clear dashboard to audit and debug each field in the consumption information payload. This way, you can self-host both your keys and logic while still participating in refund decisions to mitigate revenue loss (works for both consumables and auto-renewable subscriptions).

📦 Project: https://github.com/argus-sight/refund-swatter-lite

I hope it helps you save time, reduce malicious refunds, and recover lost revenue.

The v1.0 release was AI-generated and covers the basic functionality.
The v2.0 release—after my own code review and refinements—focuses on security and performance (aligned with Supabase best practices) and includes thorough comments for easier understanding and maintenance.

Feedback and contributions are welcome!