Building Production-Ready iOS Apps with Rork

Testing Strategy

@MainActor
class ProductListViewModelTests: XCTestCase {
    var viewModel: ProductListViewModel!
    var mockService: MockProductService!
    
    override func setUp() {
        super.setUp()
        mockService = MockProductService()
        viewModel = ProductListViewModel(service: mockService)
    }
    
    func testLoadProducts() async {
        mockService.products = [
            Product(id: 1, name: "Product 1")
        ]
        
        await viewModel.loadProducts()
        
        XCTAssertEqual(viewModel.products.count, 1)
    }
}

Network Management

class ProductService {
    func fetchProducts() async throws -> [Product] {
        var request = URLRequest(url: URL(string: "https://api.example.com/products")!)
        request.timeoutInterval = 10
        
        let (data, response) = try await URLSession.shared.data(for: request)
        
        guard let httpResponse = response as? HTTPURLResponse,
              httpResponse.statusCode == 200 else {
            throw NetworkError.invalidResponse
        }
        
        return try JSONDecoder().decode([Product].self, from: data)
    }
}

Local Storage

class DataPersistence {
    static let shared = DataPersistence()
    
    func save<T: Codable>(_ object: T, for key: String) {
        if let encoded = try? JSONEncoder().encode(object) {
            UserDefaults.standard.set(encoded, forKey: key)
        }
    }
    
    func load<T: Codable>(_ type: T.Type, for key: String) -> T? {
        guard let data = UserDefaults.standard.data(forKey: key) else {
            return nil
        }
        return try? JSONDecoder().decode(T.self, from: data)
    }
}

Rork Generates Expo / React Native Apps

The code above is native Swift/SwiftUI, but what Rork actually outputs is an Expo-managed React Native app. Most apps ship without writing any of that Swift. The native patterns matter when you reach for expo prebuild or a config plugin to add a native module, or rebuild a hot path natively.

In practice, the first thing you trip over in production isn't your Swift architecture — it's the operations and review specifics of an Expo app. The sections below cover what the intro guides skip, learned from actual round-trips between App Review and user bug reports.

Making Crashes and White Screens Visible in Production

The scariest thing in solo development is a crash that only happens on a user's device and never reproduces on yours. Your simulator launches fine every time, yet the review says "opens and immediately closes." Crash monitoring in production is what closes that distance.

In Expo, adding Sentry's official plugin to app.json collects both native crashes and JavaScript exceptions.

{
  "expo": {
    "plugins": [
      [
        "@sentry/react-native/expo",
        {
          "organization": "your-org",
          "project": "your-app"
        }
      ]
    ]
  }
}

Initialize it once at the app entry point. Leaving tracesSampleRate at 1.0 in production gets noisy fast, so it's realistic to dial it down.

// App.tsx / app/_layout.tsx
import * as Sentry from "@sentry/react-native";
 
Sentry.init({
  dsn: process.env.EXPO_PUBLIC_SENTRY_DSN,
  // Keep production around 0.1–0.2; only crank to 1.0 while developing
  tracesSampleRate: __DEV__ ? 1.0 : 0.2,
  enableNativeCrashHandling: true,
});
 
export default Sentry.wrap(App);

The infamous "blank white screen" in React Native is usually an exception thrown mid-render that wipes the view. An Error Boundary catches it, gives the user a retry button, and sends the report to Sentry for you.

import React from "react";
import { View, Text, Pressable } from "react-native";
import * as Sentry from "@sentry/react-native";
 
class AppErrorBoundary extends React.Component<
  { children: React.ReactNode },
  { hasError: boolean }
> {
  state = { hasError: false };
 
  static getDerivedStateFromError() {
    return { hasError: true };
  }
 
  componentDidCatch(error: Error, info: React.ErrorInfo) {
    // Don't leave the white screen alone — always ship it upstream
    Sentry.captureException(error, { extra: { componentStack: info.componentStack } });
  }
 
  render() {
    if (this.state.hasError) {
      return (
        <View style={{ flex: 1, alignItems: "center", justifyContent: "center", padding: 24 }}>
          <Text style={{ fontSize: 16, marginBottom: 16 }}>
            Something went wrong loading this screen
          </Text>
          <Pressable onPress={() => this.setState({ hasError: false })}>
            <Text style={{ color: "#2563eb" }}>Try again</Text>
          </Pressable>
        </View>
      );
    }
    return this.props.children;
  }
}
 
export default AppErrorBoundary;

The key point: if the crash is on the JavaScript side, you can patch it the same day over OTA (expo-updates). Once Sentry shows you the failing line, fix the JS and run eas update — no native rebuild or review wait, and you rescue the users who are crashing. Crash monitoring and OTA only become powerful together.

Building List Screens That Don't Stutter

Most apps that get "janky" or "freezes when scrolling" reviews are tripping over a list screen. For long lists in React Native, use FlatList instead of mapping into a ScrollView, and keep re-renders and image loads in check.

import { FlatList } from "react-native";
import { Image } from "expo-image";
import { memo, useCallback } from "react";
 
// Memoize the row so unrelated updates don't repaint it
const ProductRow = memo(function ProductRow({ item }: { item: Product }) {
  return (
    <Image
      source={item.imageUrl}
      // expo-image has a built-in disk cache: faster re-display, stable memory
      cachePolicy="memory-disk"
      style={{ width: "100%", height: 200 }}
      contentFit="cover"
      transition={150}
    />
  );
});
 
export function ProductList({ products }: { products: Product[] }) {
  const renderItem = useCallback(
    ({ item }: { item: Product }) => <ProductRow item={item} />,
    []
  );
 
  return (
    <FlatList
      data={products}
      keyExtractor={(item) => String(item.id)}
      renderItem={renderItem}
      // Drop off-screen rows to keep memory down
      removeClippedSubviews
      initialNumToRender={8}
      maxToRenderPerBatch={8}
      windowSize={7}
    />
  );
}

Three things matter here. Wrap the row in memo so it's decoupled from parent updates, hand images to expo-image so caching and decoding are optimized, and use initialNumToRender and windowSize to cap how many rows you hold at once. For an image-heavy list like a wallpaper app, those three alone visibly change how smooth scrolling feels.

If your rows are a fixed height, adding getItemLayout skips scroll-position math and shaves off more. If the height varies, don't force it — let removeClippedSubviews do the work instead.

Cutting eas submit and App Store Connect Round-Trips

A build that's done can still eat a day if it stalls at submission. Pin your eas submit settings in eas.json so one command gets you to TestFlight.

{
  "submit": {
    "production": {
      "ios": {
        "appleId": "you@example.com",
        "ascAppId": "1234567890",
        "appleTeamId": "ABCDE12345"
      }
    }
  }
}

# Build, then submit straight through
eas build --platform ios --profile production
eas submit --platform ios --profile production --latest

A common snag on the App Store Connect side is the encryption declaration (Export Compliance). Even if you only use HTTPS, the dialog appears every time — but one line in app.json removes that manual step at each submission.

{
  "expo": {
    "ios": {
      "config": {
        "usesNonExemptEncryption": false
      }
    }
  }
}

Add yourself as an internal TestFlight tester so you can do a final on-device check right after submitting. Before sending anything to review, I always go through TestFlight once just to watch the first launch and the push-notification permission dialog. Permission strings that never appear in the simulator are sometimes empty on a real device — and that's where you catch it.

Pre-Submission Checklist

Before pressing submit, walk through these one at a time, out loud. Cutting even one round-trip makes the release rhythm noticeably lighter.

iOS-Specific Pitfalls to Clear Before Submission

A bit more on the four from the checklist that trip people up most.

1. AdMob needs an ATT purpose string

If you add ads (AdMob), App Store review will block you without an App Tracking Transparency purpose string (NSUserTrackingUsageDescription). In Expo you set it directly in app.json under ios.infoPlist.

{
  "expo": {
    "ios": {
      "infoPlist": {
        "NSUserTrackingUsageDescription": "We measure usage only with your permission, to improve ad relevance."
      }
    }
  }
}

An empty or placeholder string often gets bounced under Guideline 5.1.1. Write a real, localized sentence for each market you ship to.

2. Permission strings are auto-added but left empty

When you use the camera or photo library through expo-image-picker and similar, the required NS...UsageDescription keys are added to Info.plist automatically — but not their text. Submitting with empty strings is a common rejection. Add one sentence per permission explaining why you need it.

3. Know what OTA (expo-updates) can't ship

JavaScript fixes go out instantly over OTA, but adding a native module or bumping the Expo SDK major version cannot. If runtimeVersion isn't set to { "policy": "appVersion" }, new JS can land on an old native binary and crash on launch. Treat OTA as "JS-only fixes."

4. Split your EAS Build profiles

Separate development / preview / production in eas.json, and let production auto-increment the build number so you never hand-bump it at submission time.

{
  "build": {
    "production": {
      "ios": { "autoIncrement": true },
      "channel": "production"
    }
  }
}

I've run wallpaper and relaxation apps as a solo developer since 2014, and AdMob is still the revenue backbone. That's exactly why forgetting the ATT purpose string once — and earning a review round-trip for it — was an expensive lesson. On iOS, a single line in Info.plist can stop a perfectly good build.

Next Step

Before your next eas build for production, walk the checklist above from top to bottom. Then, for the first few days after release, make a habit of opening the Sentry dashboard first thing in the morning — you'll catch white-screen reports before they pile up in your reviews. One fewer review round-trip, and a day faster on crash response, makes a solo release a much calmer thing.