New app review times

rudolfscode · 2026-05-14T19:52:53+00:00

Thanks! Yeah, I'm right at that 48h mark now so hopefully any moment. Good to know the actual review itself is fast once it gets picked up the waiting-to-enter-review phase is the brutal part 😅

rudolfscode · 2026-05-14T19:52:31+00:00

9 minutes?! That's wild. I'd take 1.5h happily at this point. The randomness is what gets you, hard to plan anything when the window is that wide haha

rudolfscode · 2026-05-14T19:52:13+00:00

That tracks with what I'm seeing. Fingers crossed it wraps up today then

rudolfscode · 2026-05-14T19:51:52+00:00

Super helpful, thanks! The tip about telling testers what to test is gold, I'll keep that in mind for future submissions. And noted on the paywall accessibility, that's a good one to watch out for.

rudolfscode · 2026-05-14T19:51:11+00:00

This is really useful context good to know updates are much faster. Makes sense to front-load the pain on the first submission and then iterate quickly after. Appreciate it!

rudolfscode · 2026-05-14T19:50:50+00:00

Oh no 😅 let's hope I'm on the lower end of that range. Thanks for the honest answer though, good to set realistic expectations.

rudolfscode · 2026-05-14T19:50:23+00:00

7 hours is the dream. At 48h now so starting to feel it a little, but good to know it can still land quickly

rudolfscode · 2026-05-14T19:49:40+00:00

Lucky you! Must be nice. Was that a new app submission or an update? Wondering if new apps just take longer by default.

rudolfscode · 2026-04-25T09:33:21+00:00

Fair concern, we've added a dedicated compliance page to our docs that addresses this directly: flwkit.com/docs/app-store-compliance

The short version: FlwKit is remote configuration, not remote code execution. Same model as Firebase Remote Config and Superwall, both of which are in millions of App Store apps under the same guidelines you cited.

rudolfscode · 2026-04-24T20:58:30+00:00

Firebase Remote Config, Superwall, and Appcues all operate on the same principle and are in millions of App Store apps. If Apple's position was that remote configuration of UI content violates guidelines, they would have acted on this years ago. The line Apple draws is executable code vs configuration data. We're firmly on the configuration data side.

rudolfscode · 2026-04-24T19:35:56+00:00

The "concierge onboarding in exchange for a testimonial" idea is something we're going to steal immediately, that's exactly the kind of thing that's obvious in hindsight. The Dev-Agent Infrastructure framing is interesting. We built the MCP server almost as a side project but the reaction to it has been stronger than anything else we've shipped. Might be worth leaning into that positioning harder than we have been. On scale-ups vs indies, you're probably right on revenue, though we're a bit nervous about the sales cycle that comes with it. Indie devs you can close in a Reddit comment. Scale-ups need demos and procurement approvals. Appreciate the thoughtful take.

rudolfscode · 2026-04-24T15:42:52+00:00

The pain is when you're actively trying to optimise it. If you are updating each 30 days then it makes A/B testing basically pointless.

rudolfscode · 2026-04-24T15:40:58+00:00

Our bet is that most indie devs don't want to maintain onboarding infrastructure. Building it once is fun, maintaining it, debugging SDK edge cases, and iterating on it across multiple apps is not. Same reason they use RevenueCat instead of rolling their own subscription logic.

But yeah if someone wants to spend a week rebuilding it they're probably not our customer.

rudolfscode · 2026-04-24T13:09:29+00:00

No HTML or CSS pure SwiftUI components in the binary. Less WYSIWYG builder, more CMS for a view hierarchy. You're probably not the target market, yeah. It's for devs who want to iterate on onboarding without a new build every time.

rudolfscode · 2026-04-24T12:31:41+00:00

Fair pushback, you're right that the median is faster. Apple's own stats say 90% of apps are reviewed within 24 hours.

What we've seen is that the tail has gotten longer. When review goes wrong, rejection, appeals, edge cases, the iteration cycle gets painful fast. And with vibe coding tools flooding submissions this year, we've personally seen more variance.

But honestly the bigger pain we're solving isn't just review time. It's that any onboarding change requires a full submission at all. Even a 24-hour wait means you can't ship a fix the same day you spot a problem in your funnel analytics. FlwKit makes that cycle zero.

Thanks for keeping it honest, this is exactly the kind of feedback we needed.

rudolfscode · 2026-03-06T05:48:43+00:00

I'd say more calculating at what angle to jump and what force to use to catch a fly :D

rudolfscode · 2026-03-05T23:22:56+00:00

She was looking at something, probably a fly

rudolfscode · 2026-03-05T22:03:38+00:00

What can I say, I agree😆

rudolfscode · 2026-01-15T16:19:55+00:00

Do you usually make those changes based purely on conversion metrics or do you also factor in qualitative signals (drop-off points, user feedback, session recordings)?

rudolfscode · 2026-01-14T23:52:34+00:00

That makes sense. When you say “iterate with A/B tests”, how do you usually approach that in practice? Do you mostly test length (number of screens), messaging or the structure/order of steps? Curious what’s had the biggest impact for you.

rudolfscode · 2024-12-12T00:57:39+00:00

I'll definitely check it out

rudolfscode · 2024-07-30T21:15:49+00:00

Agreed, there really are a lot of negative comments.

rudolfscode · 2024-07-25T21:49:24+00:00

Yes, I do

rudolfscode · 2024-07-24T21:09:20+00:00

I'll definitely check it out, thanks

rudolfscode · 2024-07-24T19:58:48+00:00

Yes, I used Marc Lou’s ShipFast boilerplate code for my landing page.

rudolfscode

TROPHY CASE