Skip to main content
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

1

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.
2

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).
3

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.
4

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.

​
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

SituationUse
Editing UI, building features, normal iterationAndroid simulator
Quick visual / layout checkWeb preview
Verifying Apple sign-in, Apple Pay, iOS-specific bugiOS preview
Pre-TestFlight smoke testiOS build via Deploy tab
Daily dev on an iOS-only featureiOS preview (no shortcut here)