> ## Documentation Index
> Fetch the complete documentation index at: https://docs.newly.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Recommended dev loop

> Build on Android day-to-day, use iOS for verification – this saves you time, credits, and most platform-side headaches.

Most of the friction Newly builders run into during iteration comes from the iOS preview pipeline. iOS goes through more layers (Expo, EAS, Apple credentials, dev-client versions) than Android does, and each layer has its own failure modes. If you're testing every change on iOS, you'll hit those layers often enough to slow you down.

The shorter route: do daily building on Android, then check on iOS occasionally and when you're ready to ship.

## The pattern

<Steps>
  <Step title="Open the Android simulator as your default preview">
    In the preview panel, switch to the **Android** tab and use the Android simulator (or Expo Go on an Android phone) for everyday testing.

    Android doesn't go through Expo's build pipeline, so the simulator spins up faster and has fewer steps that can fail between you and a working app.
  </Step>

  <Step title="Keep using Newly's web preview for layout checks">
    The web preview is great for quick visual feedback – colors, spacing, copy. It re-bundles your JS as you save, so visual changes show up live.

    Just know that the web preview wraps your app in an iframe, which affects a few auth-heavy flows (more on that in [Preview vs builds](/guides/preview-vs-builds)).
  </Step>

  <Step title="Trigger an iOS build when you need to verify something iOS-specific">
    Examples: Apple sign-in, layout quirks that look different on iOS, App Store metadata, or pre-TestFlight smoke tests.

    Not every prompt iteration. Once per feature, or once per session, is a healthy cadence.
  </Step>

  <Step title="Run a full iOS build before TestFlight submission">
    When you're ready to ship, trigger a fresh build from the Deploy tab. This is the build TestFlight will use, so do this right before you upload.
  </Step>
</Steps>

## Why this works

The iOS preview pipeline has more moving parts than the Android one:

* *Expo + EAS* handles iOS builds. Each EAS build is a new compile with its own credentials prep step.
* *Apple credentials* (ASC API key, provisioning, bundle ID) need to be in sync with your project.
* *dev-client version* on iOS must match your SDK version. A small mismatch produces native errors.

Android skips most of that. Its simulator boots from a Gradle build that lives entirely in our infrastructure, with no Apple-side dependencies. You can do hundreds of Android iterations without touching any of the iOS-specific layers.

## When iOS-primary is the right choice

If you're building something iOS-specific (HealthKit, Apple Pay, iOS-only widgets, an iPad-first layout), Android-primary doesn't help you. Use iOS preview from the start in that case.

Same if you're days away from App Store submission – keep iOS in the loop so you catch any submission-blocking issues before they hold you up.

## Quick comparison

| Situation                                            | Use                            |
| ---------------------------------------------------- | ------------------------------ |
| Editing UI, building features, normal iteration      | Android simulator              |
| Quick visual / layout check                          | Web preview                    |
| Verifying Apple sign-in, Apple Pay, iOS-specific bug | iOS preview                    |
| Pre-TestFlight smoke test                            | iOS build via Deploy tab       |
| Daily dev on an iOS-only feature                     | iOS preview (no shortcut here) |

## Related

* [Preview vs builds](/guides/preview-vs-builds) – the three runtime layers (web preview, simulator, production build) and what changes between them.
* [How to save AI prompts](/guides/save-prompts) – getting more out of each credit.
* [My Project is Stuck on Loading Preview](/guides/preview-troubleshooting) – fixes for when the preview itself misbehaves.