How far Rork Companion's free device testing goes — and when to pay the $99 Apple Developer Program

Concrete triggers for paying the $99

If you decide "when to pay" by gut feel, you pay too early or too late. I treat the first time I hit any of these as the trigger. Paying too early leaves an annual fee idle; paying too late drops a review queue right after completion and kills momentum.

1. Your core revenue is push, IAP, or subscription — test ads cannot fully verify it, and you need the account from the design stage.
2. You want to hand it to testers other than yourself — Companion share links only go so far; TestFlight external testing requires the Program.
3. You need App Store-specific features at production parity — App Clips, widgets, Live Activities, and certain capabilities only render correctly on a signed build.
4. A launch date is now within one or two weeks — review round-trips need buffer days, so pay and clear the queue ahead of time.

Conversely, while you are still testing whether an idea becomes a real app, or polishing UI and raw feel, there is no reason to pay the $99. Buying more cheap iterations on the free path gets you closer to a good app. Rork itself starts free with paid plans from $25/month, and Rork Max is a separate track at $200/month — but the $99/year Apple Developer Program is best understood as an independent "toll on Apple's side," separate from any of those.

A pre-payment checklist to stage first

To avoid scrambling on your first signed build, a few things pay off if you finish them while still on the free path. Defer them and you will burn that precious first review cycle on configuration fixes right after paying.

1. Storage and assets

What the live simulator hides well is the weight of the first launch on a real device. For image-heavy apps especially, sort out density buckets and lazy loading while you are still unsigned. I once shipped a wallpaper app where I missed a density-split case and resources dropped out on low-density devices — exactly the kind of problem to kill before you reach a signed build.

2. Permission prompt order

Permission dialogs — ATT (App Tracking Transparency), notifications, photo library — feel completely different depending on order and timing. As a baseline, do not fire them all at first launch; show each one in context, just before the feature uses it, and bake that into code while you are still on the free path. For ordering SDK init against permission requests, see cold-start SDK orchestration.

3. An instrumentation base

If your first encounter with a crash happens on a signed build, isolating the cause takes time. While unsigned, put in at least a minimal crash-report and event base so verification after paying goes faster. Below is an app.json (Expo) template gathering the identifiers and permission strings worth locking in before you pay.

{
  "expo": {
    "name": "MyApp",
    "slug": "my-app",
    "ios": {
      "bundleIdentifier": "design.dolice.myapp",
      "buildNumber": "1",
      "infoPlist": {
        "NSUserTrackingUsageDescription": "Used to tailor ads to your interests.",
        "NSPhotoLibraryAddUsageDescription": "Used to save wallpapers to your photo library.",
        "ITSAppUsesNonExemptEncryption": false
      }
    },
    "android": {
      "package": "design.dolice.myapp",
      "versionCode": 1
    }
  }
}

Lock bundleIdentifier and package to their production values while still free — changing them later means redoing distribution. Declaring ITSAppUsesNonExemptEncryption up front keeps you from stalling on the export-compliance question at submission.

4. A pre-signing self-audit

The classic rejections are missing Info.plist permission strings and version mismatches. Running a small static check before you enter a signed build cuts down on first-submission bounces. Here is a minimal audit you can write in Node.

// presubmit-audit.js — minimal check to run before a signed build
const fs = require("fs");
const cfg = JSON.parse(fs.readFileSync("app.json", "utf8")).expo;
 
const required = [
  "NSUserTrackingUsageDescription",
  "NSPhotoLibraryAddUsageDescription",
];
const info = cfg.ios?.infoPlist ?? {};
const missing = required.filter((k) => !info[k]);
 
if (missing.length > 0) {
  console.error("Missing permission strings:", missing.join(", "));
  process.exit(1);
}
if (!cfg.ios?.bundleIdentifier?.includes(".")) {
  console.error("bundleIdentifier is not finalized for production");
  process.exit(1);
}
console.log("Self-audit passed");

The check is only a few dozen lines, but it is insurance against wasting a round-trip on your first review for a config slip. Running six apps in parallel, I kept tripping on the same spots at every submission, so I froze this kind of small audit into the pre-build step.

What the live simulator structurally cannot reproduce

When you decide how far to stretch the free path, it helps to be concrete about how the live simulator is fast and convenient but not the real thing. The following simply cannot be reproduced in a cloud simulator:

• Frame drops from real-device thermal throttling (the stutter on long scrolls or video playback)
• The OS forcibly terminating your app under memory pressure (jetsam)
• The feel of real sensors and haptic feedback
• The actual variance of weak signal or offline transitions

Even if you polish the UI perfectly on the free path, these can only be confirmed on a physical device (a Companion transfer). In my case, the memory-pressure terminations in an image-heavy app always surfaced only after I transferred to a device. That is exactly why splitting responsibilities works: flush out the raw behavior on the free path, then send only this layer to on-device verification.

A workflow that bridges free and paid

Put it all together and the order is this: do all idea validation and UI polish on the free path, finish the four staging items while unsigned, and pay the $99 the moment revenue features, external distribution, or a launch date comes into view.

The advantage of this shape is that your time after paying goes entirely to verification. Companion confirms the raw behavior, the signed build confirms production entitlements and purchases, and TestFlight puts it on other people's devices — three tiers with cleanly separated responsibilities. On shortening the release side, pairing this with the two-click publish flow reduces the submission friction further.

The free path exists to erase the friction before you start building; it does not stand in for the production path of revenue and distribution. Hold that line from the start and you get to choose the day you pay the $99 yourself. Start by connecting one spare device to Companion and running the self-audit script above against your app.json once. Thanks for reading.