DEV Community: Jules Sarah

Nine Screens of Pain: The UX of Submitting to the App Store

Jules Sarah — Fri, 17 Jul 2026 11:51:01 +0000

If you've ever submitted your first app, what follows will feel familiar. If you haven't, bookmark this — you're going to want to reference it around week two of the process.

The starting state: a fresh App Store Connect account

You've paid the $99. You've verified the DUNS number. You've waited three business days for Apple to enroll you.

Now you're staring at App Store Connect, trying to figure out how to actually submit the app you've built. The dashboard shows icons for iTunes Connect (deprecated, but still visible), Certificates, TestFlight, Users and Access, Contracts. None of them say "Submit an App." That option lives under "My Apps" — which is one of the icons, but isn't labeled as such.

You have spent fifteen minutes and made zero progress.

Screen-by-screen through the actual flow

Screen 1: Bundle ID registration. In the developer portal — a different site than App Store Connect. Get this wrong and you can't rename it later.

Screen 2: Certificate + provisioning profile. Two of each, development and distribution. Apple's UI walks you through it but assumes you already know what a certificate does.

Screen 3: Xcode signing configuration. Six dropdowns, three of which look identical. If any one is wrong, the build fails with "no provisioning profile matches," and you go Google the exact error string.

Screen 4: Archive + upload. Ten minutes of "processing," then usually success. Sometimes an email thirty minutes later: "Your build has one or more issues." No indication of which.

Screen 5: App Information. Category, subcategory, content rights, age rating. That last one is a twenty-question survey.

Screen 6: Pricing and Availability. Choose the countries. Pick the tier. Explain whether the app is free but has in-app purchases.

Screen 7: App Privacy. Answer questions about data collection. Every "yes" cascades into four to six follow-up questions. Miss one and your submission is rejected.

Screen 8: The version you're submitting. Description, keywords (100 characters), promotional text, support URL, marketing URL, screenshots (six iPhone sizes minimum), preview video.

Screen 9: Review information. Contact info, demo account credentials, review notes. Then, finally, the "Submit for Review" button.

And that's not counting the TestFlight side, which is another five screens.

The 3am "invalid binary" moment

Every indie dev has this moment. You've finished all nine screens. You upload the build. Twenty minutes later, an email arrives:

The uploaded build has invalid binary architecture.

Or:

The provisioning profile does not include the Push Notifications entitlement.

Google says: rebuild with different Xcode settings. You do. Same error. You Google more. It turns out you also had to add a capability in the developer portal. You do that. Build. Upload. Wait twenty minutes. Different error.

This is where most people give up on their first-month timeline.

Why this UX pattern persists

Apple has zero pressure to simplify submission. Every indie who quits has ten replacements. And Apple's real customer isn't the indie dev — it's the enterprise studio with a team dedicated to this workflow.

That isn't going to change from within Apple. But it means the leverage for indie tooling is enormous — whoever solves this UX gap earns loyalty from a badly underserved segment.

What a good submission tool looks like

A good submission tool would:

Ask the App Privacy questions in plain English, once. Then fill in App Store Connect automatically.
Cross-check your build against the top 20 rejection reasons before upload. Fail loudly if any are hit.
Show real-time status. "In review, 47h in queue, median for your category is 26h" — not "Waiting for Review" for five days.
Handle rejections as tickets. The rejection reason parsed into a diff you can apply, with a resubmit button.
Never let you reach a 3am invalid-binary moment. Every failure mode should surface before upload, not twenty minutes after.

That's the product I want to use as an indie dev — and it's part of why we built RapidNative to handle the generate-to-submit path so the nine screens stop being your problem.

Takeaway

The App Store submission flow is a UX artifact of Apple's incentives, not a law of nature. Until it improves, treat it like the gauntlet it is: budget a full week, expect one rejection, and surface every failure mode you can before you hit upload.

Which App Store rejection got you at 3am — invalid binary, missing entitlement, or a privacy label you filled out wrong? Drop it in the comments.

Auth Is Where User Trust Is Decided — What Indie Founders Miss About Expo + Supabase Flows

Jules Sarah — Wed, 15 Jul 2026 13:07:33 +0000

There's a ~30-second window, usually mid-auth, where a new user decides to lean in or swipe away.
Four moments break trust: a magic link that opens Safari instead of the app, an OAuth flow stuck in limbo, error messages that read like stack traces, and sessions silently lost on app resume.
Most fixes don't need a designer — copy error-message tone from apps you love, test the magic-link flow on a real device with the app closed, and add a "check your email" confirmation.
The single biggest lever: seamless session refresh on resume. Wiring it took install-to-week-1 retention from 32% to 41%.

I've watched a lot of first-time app installs. There's a moment about 30 seconds in where users either lean forward and start actually using the app, or lean back and swipe it away. That moment is almost always mid-auth-flow — and it's mostly decided by whether the auth flow feels trustworthy.

This isn't a marketing insight. It's a UX one. Founders overwhelmingly underweight it, especially indies who see auth as "plumbing." Here's what actually happens in that 30 seconds, and how a good Expo + Supabase setup helps.

The 30-second trust window

The user opens your app fresh. They see a splash screen (fine), a welcome screen (fine), and then the sign-up screen. From here they make four judgments in rapid succession:

Do I understand what I'm being asked? Email + password? Magic link? Social? All three?
Do I trust this with my email? Is the design polished? Does it look like a real product?
Does anything obviously break? Autocorrect mangling my email, the keyboard covering the CTA, weird focus behavior?
Do I get a signal that it worked? After I hit sign-up, do I see confirmation, or does the app just… sit there?

Break any of these and you lose the user before they see a single product feature.

The four moments that break trust

Moment 1: The magic link opens in Safari, not the app. The user taps the email link, iOS opens Safari, they see a "redirecting…" page, then get bounced back to the app — but the auth state didn't sync. They tap the link again. Same result. They quit. This happens when Universal Links aren't wired properly, or expo-linking isn't handling the auth callback URL.

Moment 2: The OAuth flow leaves them in limbo. The user taps "sign in with Google," gets the browser sheet, taps back — and the app is stuck on a loading spinner. Flows that don't handle the OAuth-cancelled state leave the user stranded.

Moment 3: The error message reads like a stack trace. "Invalid credentials" or "Auth session missing!" terrifies non-technical users. "That password doesn't look right. Reset it?" converts them.

Moment 4: Session lost after app resume. The user signs in, backgrounds the app, comes back an hour later — signed out. supabase-js's default token refresh doesn't always fire on iOS resume. Wiring AppState to supabase.auth.refreshSession() explicitly solves this.

Fixes without a designer

Even as a solo founder with no design help:

Copy the error-message tone from a well-loved app you use (Linear, Notion, Superhuman).
Test the magic-link flow yourself on a real device, with the app fully closed, before you launch.
Add an "account created — check your email" confirmation screen. Users need the feedback.

Run a 20-minute usability test

Grab someone who's never seen your app. Watch them sign up. Don't help.

Note every place they hesitate for more than two seconds. Those are your trust breakpoints. Fix the top three before you launch.

The one feature that changed my install-to-DAU rate

All of the above matters, but the single thing that most moved my numbers: seamless session refresh on app resume, so users never got signed out unexpectedly.

My install-to-week-1 retention went from 32% to 41%. That's a large lift, and it came from one wired hook.

Takeaway

Auth is a UX surface, not a plumbing task. If your Expo + Supabase foundation ships wired session refresh, correct deep-link handling, and a proper OAuth-cancel state, you're buying trust — not just code.

If you'd rather start from a foundation with these already solved, I keep a set of Expo + Supabase templates wired for exactly this at Applighter.

Which of the four trust-breakers has cost you the most users? Drop it in the comments.

40 React Native Devs on What They Wish Their Boilerplate Fixed

Jules Sarah — Wed, 08 Jul 2026 14:36:42 +0000

I asked ~40 indie React Native devs one question: "What do you wish your boilerplate did differently?"
Three wishes dominated: less opinionated navigation (28/40), TypeScript without wrapper-type overhead (24/40), and real dark-mode wiring, not just a CSS toggle (19/40).
Nobody asked for more features. Not one. Every wish was subtractive.
The next wave of boilerplates will win by shipping less, cleaner, with better exit points.

Over the past two months I've been talking to indie React Native developers about the boilerplates they use. The question that got the most useful answers wasn't "which boilerplate do you use?" — it was "what do you wish your boilerplate did differently?"

I've now heard back from about 40 devs across a handful of communities (r/reactnative, the Expo Discord, some Twitter DMs). The pattern is clear enough to be worth writing down.

How the survey ran and who answered

Informal, DM-based, ~10 minutes each. Sample skews toward:

Solo devs and 2-3 person teams (35 of 40)
Shipping paid apps, not free (~28 of 40)
Using either an off-the-shelf boilerplate or one they'd built themselves (~half and half)

So the sample is biased toward serious builders — people whose CI/CD choices matter to their revenue. That's the right audience for a survey about tooling ergonomics.

The top three wishes, in order

1. Less opinionated navigation (28 of 40 mentioned this, often first)

Most boilerplates ship a navigation shape — tab bar with a stack per tab, a modal presentation pattern, a drawer for settings — and it's the choice devs said they most often had to unwind. The frustration wasn't the specific shape; it was that the boilerplate had committed to one before knowing the product.

What they wanted: a navigation layer they could rip and replace in an afternoon. What they got: a navigation layer that other screens assumed, so ripping it meant refactoring every screen.

2. TypeScript throughout, without wrapper types getting in the way (24 of 40)

Everyone wants TS. What they don't want is a boilerplate whose author defined 40 custom wrapper types on top of standard SDK types (Supabase, Stripe, Expo APIs) because they wanted stricter typing.

// ❌ What devs are complaining about
import type { AppUser } from '@/lib/types/user'
import type { AppSession } from '@/lib/types/session'

// You have to learn the boilerplate's vocabulary
// before you can find what you need in the SDK docs.

// ✅ What they want instead
import type { User, Session } from '@supabase/supabase-js'

// The SDK's own types. No translation layer.

The wish is TS-native, TS-first, but using the SDK's own types wherever possible. Wrap only when the SDK types are genuinely painful.

3. Real dark-mode wiring, not just a CSS toggle (19 of 40)

This one surprised me. Many boilerplates advertise "dark mode included" and what they mean is a theme toggle that swaps a color palette. What devs actually want:

System-color-scheme detection that respects OS-level user preference
Persistence of user override across app restarts
Correct behavior for platform-specific dark-mode surfaces (iOS blur, Android edge-to-edge)
Status bar + navigation bar following the theme
Charts, images, and third-party components that don't fight the theme

"Dark mode included" should mean all of the above. Mostly it means a toggle.

The features nobody asked for

Equally interesting: nobody asked for more features. Not one respondent said "I wish my boilerplate had more built-in screens" or "I wish it included analytics + i18n + AI chat + [something]." Every wish was subtractive: less friction, less coupling, less opinion.

The implication is unusual for a product category: feature-heavy boilerplates are competing on the wrong axis. The market wants fewer, better, cleaner-seamed layers.

What that tells us about product/market fit for starter kits

Boilerplates are a maturing category. The first wave sold on feature counts because that was legible. The current audience has been burned by feature counts enough times that they now audit for extensibility. The next wave of boilerplates will win by having a smaller surface area and cleaner exit points.

That's a hard product story to tell. "We include less than the competition" doesn't sell landing pages. But it's what devs 6 months into a project actually want.

Conclusion: subtractive design wins in tooling

The finding I keep coming back to: developers judge tools by how well they get out of the way, not by how much they do. Boilerplates are no different.

If you're building a starter kit, the next feature to add is probably a layer to remove. If you're picking one, run the 60-minute strip-down test. Either way, subtractive design is the axis of quality.

Feature counts are dead. Long live ergonomics.

What did you wish your React Native boilerplate did differently? Drop it in the comments — I'm collecting responses for a follow-up survey and yours might be the pattern that makes the shortlist next time.

Stop Hand-Coding React Native Forms. Generate Them Instead.

Jules Sarah — Wed, 01 Jul 2026 12:20:58 +0000

Every mobile app is mostly forms, and every form comes with the same boilerplate tax: library choice, schema, keyboard config, KeyboardAvoidingView, validation, error/loading/disabled states, cross-platform testing.
AI generation produces all of that from a plain-English prompt — including the props you always forget (autoCapitalize="none", textContentType, returnKeyType).
Where it still needs you: domain-specific validation, custom UX choices, and swapping the placeholder fetch for your real endpoint.
The real win is iteration speed: tap a field, describe the change, only that field updates.

Stop Hand-Coding React Native Forms. Generate Them Instead.

Ask any React Native dev what part of the job they enjoy least, and forms come up fast. This post walks through generating forms with AI instead — what you get out of the box, what still needs your hand, and where the shortcuts hurt.

Why Forms Are the Worst

Every mobile app is mostly forms with some chrome around them. Signup, checkout, profile edit, "leave a review," "add a task" — all forms. And every form comes with the same tax:

Pick a form library (react-hook-form? Formik? roll your own?)
Wire up a schema library (Zod, Yup)
Configure the keyboard for each field (keyboardType, autoCapitalize, autoComplete, textContentType)
Fight KeyboardAvoidingView until the submit button stops hiding under the keyboard
Handle blur validation, submit validation, error rendering, disabled states, loading states
Test on both iOS and Android

Multiply by 15 forms and there goes your sprint.

What "AI-Generated Forms" Actually Produces

I've been building with RapidNative — an AI mobile app builder that takes plain English and outputs React Native + Expo — and forms are the use case where AI generation feels closest to a superpower. Here's what a prompt like this:

A signup screen with email, password, confirm password, and a role picker (founder, designer, developer). Validate all fields on blur. Auto-advance to the next field on return.

...actually generates:

const [formData, setFormData] = useState({
  email: '',
  password: '',
  confirmPassword: '',
  role: '',
});
const [errors, setErrors] = useState({});

const emailRef = useRef(null);
const passwordRef = useRef(null);
const confirmRef = useRef(null);

const validateField = (field, value) => {
  // per-field validation
};

return (
  <KeyboardAvoidingView
    behavior={Platform.OS === 'ios' ? 'padding' : 'height'}
    style={styles.container}
  >
    <ScrollView keyboardShouldPersistTaps="handled">
      <TextInput
        ref={emailRef}
        placeholder="Email"
        keyboardType="email-address"
        autoCapitalize="none"
        autoComplete="email"
        textContentType="emailAddress"
        returnKeyType="next"
        onSubmitEditing={() => passwordRef.current?.focus()}
        value={formData.email}
        onChangeText={(v) => setFormData({ ...formData, email: v })}
        onBlur={() => validateField('email', formData.email)}
      />
      {errors.email && <Text style={styles.error}>{errors.email}</Text>}
      {/* password + confirm + picker follow */}
    </ScrollView>
  </KeyboardAvoidingView>
);

Every prop I usually forget on the first try — autoCapitalize="none", textContentType="emailAddress", returnKeyType="next", the KeyboardAvoidingView wrapper — is there by default. Not because I remembered to ask, but because the generator knows what an email field needs.

What's Actually Hard About Mobile Forms

The interesting details, the ones AI generation handles well:

Keyboard type per field. Email → email-address, phone → phone-pad, card number → number-pad.
Autofill hints. textContentType="emailAddress" on iOS, autoComplete="email" on RN. Both required for OS autofill to fire.
Focus chain. returnKeyType="next" + onSubmitEditing + refs to the next input.
Password fields. secureTextEntry + textContentType="password" (or newPassword on signup) so iOS offers to save/generate a password.
Keyboard avoidance. KeyboardAvoidingView with different behavior per platform, wrapped around a ScrollView with keyboardShouldPersistTaps="handled".

These are the kind of details that get skipped when a human is tired. They're the kind of details that never get skipped by a generator, because they're pattern-heavy and well-documented.

Where AI Generation Still Needs You

Being honest: not everything is a slam dunk.

Very domain-specific validation (tax IDs, national ID formats, complex phone number rules) — you'll want to review or specify these explicitly.
Custom UX flows where the "correct" pattern is a design choice, not a technical one, still benefit from a human eye.
Integration with your existing backend — the generator produces a placeholder fetch you replace with your actual endpoint. Not automatic magic, but a two-line edit.

Iteration Wins

The real unlock isn't the first-generation speed — it's how fast you can iterate. Tap a field in the preview, say "make this a dropdown with 4 options," and only that field changes. Say "the submit button should be disabled until the form is valid," and it wires it up.

Compare that to: open the file, find the TextInput, replace with Picker, update state binding, add options array, restyle, save, reload the preview. Forms live-edited with a chat interface are unreasonably fast.

Try It

Give it a shot: RapidNative. Free to start. Type in a form description and see what falls out.

What's the form screen that's eaten the most of your time? Drop a comment with what you're building.

Mobile App Analytics in React Native — What to Track in 2026

Jules Sarah — Tue, 30 Jun 2026 13:50:07 +0000

Most app teams track ~40 metrics. They review 4. The other 36 fill dashboards and never inform a decision.
The working set is 12 metrics across 5 layers: acquisition, activation, engagement, retention/monetization, technical.
Day-1 retention is the harshest single number in your dashboard, and the one most tightly correlated with everything downstream.
In React Native, 4 instrumentation failure modes make your numbers lie: deep-link sessions, app-state timeouts, offline-event flushing, and over-eventing.
Pick your core 8–12 metrics by stage. Give each one a named owner. Delete the rest.

The vanity-metric trap

A vanity metric is any number that goes up reliably but doesn't help you decide anything.

Total downloads is the classic example. Downloads only grow. An app with 1M downloads and 2% Day-30 retention is, by any honest measure, smaller than an app with 50k downloads and 35% Day-30 retention.

Three questions to run every metric through before you instrument it:

What decision will this number inform? If "we'll know how we're doing," it's vanity.
Who owns that decision? No owner → nobody acts on it.
How often will they review it? "Occasionally" means you built a screensaver.

A metric that survives all three is worth instrumenting. Almost nothing else is.

The 12 metrics that actually matter

Acquisition layer

1. Install conversion rate. Of every 100 people who land on your App Store listing, how many install? Baselines: 25–30% organic, 30–40% paid. Below 20% you have a creative problem, not a traffic problem.

2. CAC (by channel). Useful only as a ratio with LTV. Healthy LTV:CAC is ~3:1 for consumer subscription apps. Below that, growth is a tax on the business.

Activation layer

3. Day-1 retention. Of users who installed yesterday, how many came back today? Industry average 25–30%. Top decile clears 50%. This is the harshest number in your dashboard.

4. Time to first value (TTFV). How long until a new user does the thing your app is for? Highest leverage on Day-1 retention.

Engagement layer

5. DAU/MAU stickiness. Healthy: 0.20. Daily habit: 0.50+. Productivity tools: 0.15–0.25. Ecommerce often under 0.10 (and that's fine if LTV supports it).

6. Session length + sessions per user. Watch them together. Length down + frequency stable = users achieving the goal faster (good). Frequency down + length stable = retention problem in disguise.

7. Key feature adoption rate. Pick 2–3 features that cause retention. Track the % of new users who reach each in their first week. This turns "improve onboarding" into a specific testable bet.

Retention and monetization layer

8. Day-7 and Day-30 retention. Day-1 = onboarding worked. Day-7 = value was real. Day-30 = value was recurring. Track as cohorts.

9. Churn rate. Healthy monthly: 5%. Trouble: 10%. Bucket has a hole: 15%+.

10. ARPU and LTV. LTV justifies CAC. Be honest about assumptions — if your "12-month LTV" comes from 3 months of data, you are projecting, not measuring.

Technical performance layer

11. Crash-free sessions. Google Play flags >1.09% crash rate as "bad behavior." Aim for 99.5%+ as the floor.

12. Cold start time. Cold-starts >2.5s correlate measurably with worse first-session retention. Most under-tracked, highest-leverage metric on the list.

Pick your core 8–12 by stage

Stage	Pre-launch (≤1k users)	Growth (1k–100k)	Scale (100k+)
Acquisition	Install conv rate	CAC by channel	LTV:CAC ratio
Activation	Time to first value	Day-1 retention	Day-1 by source
Engagement	Key feature adoption	DAU/MAU	Session length + freq
Retention/Money	Day-7 retention	Day-7, Day-30 cohorts	Churn, ARPU
Technical	Crash-free sessions	Cold start time	All + ANR rate

Rule: max 2 metrics per layer at any one time, each with a named owner. No owner → delete.

React Native instrumentation: the 4 failure modes

This is where most apps get the numbers wrong.

1. The deep-link problem

When a user opens your app from a push notification or marketing URL, your analytics SDK may register a fresh session before your deep-link handler decides which screen to show.

// ❌ Wrong: tracking from componentDidMount / useEffect on each screen
useEffect(() => {
  analytics.track('screen_view', { screen: 'home' });
}, []);

// ✅ Right: track from navigation library's listener
import { useNavigationState } from '@react-navigation/native';

const state = useNavigationState((s) => s);
useEffect(() => {
  const route = state?.routes?.[state.index];
  if (route) analytics.track('screen_view', { screen: route.name, params: route.params });
}, [state?.index]);

Otherwise your funnel will be off by one step on every deep-linked session, and you'll spend a quarter optimizing the wrong screen.

2. The app-state problem

A user backgrounds your app for 90 seconds to check a text, then comes back. Most SDKs default to a 30s session timeout, so your dashboard now reports 2 sessions where the user experienced 1.

// Be explicit about your session definition
import mixpanel from 'mixpanel-react-native';

mixpanel.init('TOKEN', {
  // Document this next to every "sessions" chart you publish
  trackAutomaticEvents: true,
  // Mixpanel defaults to 30s — bump to 5 min for habit apps,
  // keep tight for transactional flows
});

Decide your session definition explicitly and document it next to every "sessions" chart you publish.

3. The offline-events problem

A user logs a workout on the subway. Your analytics SDK queues the event and flushes it when connectivity returns — 30 minutes later.

// ❌ Wrong: using only event_timestamp
SELECT date_trunc('hour', event_timestamp), count(*)
FROM events WHERE name = 'workout_completed'
GROUP BY 1;

// ✅ Right: store BOTH timestamps, pick per query
analytics.track('workout_completed', {
  workout_type: 'cardio',
  client_timestamp: new Date().toISOString(), // when user did it
  // server adds event_timestamp on receipt
});

// Then query by client_timestamp for "when did users do this"
// and event_timestamp for "when did our system see it"

If you build dashboards off event_timestamp instead of client_timestamp, your "workouts per hour" chart will spike at the times people emerge from underground.

4. The over-eventing problem

It's tempting to track every tap. Don't.

// Start with this minimal schema, expand only when justified
analytics.track('screen_view', { screen });
analytics.track('feature_action', { feature_name, action });
analytics.track('conversion', { type, value });

Each unnecessary event adds payload, drains battery, costs money at scale (most tools charge per event), and dilutes the events that matter. Start tight. Add events only when you can answer "what decision will this inform."

The default RN stack in 2026

For most React Native apps:

Firebase Analytics for free baseline + Crashlytics for crash reporting
One product-analytics tool: Mixpanel, Amplitude, or PostHog (pick one, instrument it well)
Attribution SDK (AppsFlyer, Adjust) only if running paid acquisition

Don't run three product-analytics tools at once. Pick one and instrument it well.

The point

The best mobile app analytics setup isn't the one with the most dashboards. It's the one with the fewest dashboards that drive real decisions.

Pick the 12 metrics above as a starting menu. Narrow to the 8–12 that match your stage. Give each one an owner. Instrument them carefully enough that the numbers your team argues over are actually the numbers your users experienced.

For the longer write-up — including the full FAQ and the "why AI-built apps make analytics non-optional from day one" angle — see the RapidNative blog.

What's the metric you removed from your dashboard that you should have removed sooner? Drop it in the comments — I'm collecting the screensaver metrics indie devs ship by default for a follow-up.