For years the received wisdom was simple: if you want to build for iPhone, buy a Mac. That is no longer true. The only part of the iOS pipeline that genuinely requires macOS is the final compile and code-signing step — and that can now be handed off to a cloud service while you do everything else from a Windows machine: write the code, design the interface, build and test your backend, manage releases, and submit to the App Store.

This guide walks through the practical options and the websites that make them work, sets out a recommended end-to-end process, and covers the backend and security work that turns a weekend demo into a real product.

The one real constraint

Apple’s build toolchain — Xcode and the iOS SDK — only runs on macOS. Compiling your app (whether that is Swift, or the native output of a cross-platform framework) and signing it with your Apple certificates must happen on a Mac. There is no legitimate way around that single step.

Everything else, though, is platform-agnostic. Writing your app, previewing it, building and testing your API, and submitting through App Store Connect (which is just a website) all work fine on Windows. So the whole “iOS on Windows” question reduces to one practical problem:

Your options at a glance

Pick the row that matches your skills and how much control you want. The column that matters most for this article is the third one — how painlessly you can produce a signed iOS build from Windows.

Code-first: React Native + Expo (the pragmatic winner)

Write your app once in JavaScript or TypeScript and get genuinely native iOS and Android binaries — not a web page in a wrapper. The reason it tops the table is EAS Build: Expo’s hosted service compiles and signs your iOS app on Apple hardware in their cloud, so you never touch a Mac. For “native apps, easily, from Windows,” this is the cleanest answer there is, and you keep full ownership of the code. See reactnative.dev and expo.dev.

Flutter

Google’s framework, written in Dart, with excellent UI fidelity and performance. It develops happily on Windows for the Android side, but the iOS build still needs macOS. The usual fix is Codemagic, a CI service built around Flutter that compiles your iOS app in the cloud, or a rented cloud Mac. See flutter.dev and codemagic.io.

.NET MAUI

The natural choice if your shop already lives in C# and Visual Studio. MAUI produces native apps for iOS, Android, Windows and macOS from a single C# codebase. The honest caveat: even from Windows, the iOS build requires a networked Mac (“Pair to Mac”) or a cloud Mac — there is no fully Mac-free local iOS build. So despite being the most comfortable language-wise for .NET teams, it is the weakest option on this specific axis. See dotnet.microsoft.com/apps/maui.

Visual and AI builders

If you would rather not write much code, the visual builders run entirely in the browser and build in their own cloud, so the operating system on your desk is irrelevant. FlutterFlow (Flutter under the hood, with exportable code), Adalo (the simplest true-native drag-and-drop path) and Thunkable (block-based, beginner-friendly) are the established names. A newer category — AI-first builders such as Newly, Rork, RapidNative and a0.dev — lets you describe the app in plain English and hands back a React Native/Expo project you own. Quality varies and generated code usually wants a developer’s eye before production, but they are a fast starting point. Of these, Newly is the one built specifically around shipping native iOS from a Windows machine, so it’s worth a closer look — see the spotlight below.

Spotlight: Newly

One tool is worth singling out for this particular brief. Most of the options above are general-purpose; Newly (newly.app) is built specifically around the problem this article is about — getting a genuinely native iPhone app from idea to the App Store without a Mac anywhere in the loop. It is the most managed and most end-to-end of the AI-first builders, which is why it earns its own section rather than a line in a list.

Solving the Mac-only build step

This is the linchpin of the whole exercise. Here are your routes, ordered from least to most effort:

• Expo EAS Build — if you are on React Native, this is the simplest by far. eas build --platform ios queues a build on Apple hardware and returns a signed .ipa. Free tier for low volume; paid plans for priority and throughput. (expo.dev/eas)
• Codemagic — CI/CD built for Flutter (and capable with React Native and native projects). Connect your repository and it builds and signs iOS in the cloud, with free monthly build minutes to start. (codemagic.io)
• GitHub Actions with macOS runners — if your code already lives on GitHub, you can run the iOS build on a hosted macOS runner. Very flexible; note macOS minutes bill at a higher multiplier on private repositories. (github.com/features/actions)
• Bitrise — a mobile-focused CI/CD platform with strong, opinionated iOS code-signing management. (bitrise.io)
• Cloud Mac rental — MacStadium, MacinCloud or AWS EC2 Mac instances. You remote into a real Mac and run Xcode directly. More hands-on and more expensive, but it gives you the full toolchain for debugging signing problems or using Xcode features the abstractions don’t expose.

The recommended process, end to end

This is the order I’d follow for a no-Mac React Native build. The same shape applies to the other frameworks; only steps 2–4 change.

1. Enrol in the Apple Developer Program

   Do this first — you can’t sign or submit anything without it. Budget the annual fee and allow a day or two for verification (longer for an organisation account).

2. Set up your framework on Windows

   For the no-Mac path: install Node.js, add the Expo tooling, scaffold a React Native project, and confirm it runs in the Expo preview on your own iPhone.

3. Build the app

   Develop and iterate entirely on Windows, previewing on your physical iPhone over the local network. None of this requires a Mac.

4. Wire up cloud build & signing

   Connect EAS (or Codemagic) and let it manage your certificates and provisioning profiles. Run your first cloud iOS build and install it on a device via TestFlight.

5. Stand up the backend

   Build your PHP/MySQL JSON API (covered next). Keep it in its own repository and version it independently of the app.

6. Connect the app to the API securely

   Talk to it over HTTPS with token-based authentication, and store tokens in the iOS Keychain — never in plain device storage.

7. Test on real hardware

   Distribute builds to yourself and beta testers through TestFlight. Always test on a real device, not just a simulator.

8. Submit to the App Store

   Upload through App Store Connect, complete the metadata and privacy details, and submit for review.

Integrating with a PHP + MySQL backend

A native app should never talk to a database directly. It talks to an API, and the API talks to the database. The clean, language-agnostic pattern is a RESTful JSON API written in PHP, sitting in front of MySQL (or MariaDB). If you already run a LAMP/LEMP stack, you are most of the way there.

Building the API

Vanilla PHP with PDO is perfectly sufficient — no framework required. Each endpoint validates the request, runs a prepared statement, and returns JSON. A typical “list items for the signed-in user” endpoint looks like this:

<?php
// Return the signed-in user's items as JSON
header('Content-Type: application/json');

require __DIR__ . '/db.php';     // returns a configured PDO instance as $pdo
require __DIR__ . '/auth.php';   // validates the Bearer token, sets $userId

try {
    $stmt = $pdo->prepare(
        'SELECT id, title, created_at
           FROM items
          WHERE user_id = :uid
          ORDER BY created_at DESC'
    );
    $stmt->execute([':uid' => $userId]);
    $items = $stmt->fetchAll(PDO::FETCH_ASSOC);

    echo json_encode(['ok' => true, 'items' => $items]);
} catch (Throwable $e) {
    http_response_code(500);
    echo json_encode(['ok' => false, 'error' => 'Server error']);
}

On the app side, you call it with a standard fetch(), passing the user’s token in an Authorization header:

const API_BASE = 'https://api.example.com';

export async function getItems(token) {
  const res = await fetch(`${API_BASE}/items.php`, {
    method: 'GET',
    headers: {
      'Accept': 'application/json',
      'Authorization': `Bearer ${token}`,
    },
  });

  if (!res.ok) {
    throw new Error(`Request failed: ${res.status}`);
  }
  const data = await res.json();
  return data.items;
}

Authentication

Use token-based authentication. On login, the API verifies credentials with password_verify() against a password_hash() column, then issues a token — either a signed JWT or an opaque random token stored server-side. The app sends that token as a Bearer header on every subsequent request. Do not use a long-lived API key baked into the app: anything shipped inside the binary can be extracted by anyone who downloads it.

Security considerations

This is where a side-project becomes a liability if you skip it. None of the following is optional for an app that handles real user data.

• Parameterise every query. Use PDO prepared statements for all database access and never concatenate user input into SQL. This is your first and most important line of defence against SQL injection.
• Short-lived tokens. Issue short-lived access tokens with a refresh mechanism, verify them on every request, and be able to revoke them server-side.
• Store secrets in the Keychain. On the device, keep tokens in the iOS Keychain — not in UserDefaults, AsyncStorage, or a plain file.
• Never embed secrets in the app. API keys, signing secrets and database credentials live server-side only. Assume the shipped binary is readable.
• Validate on the server. Treat all client input as hostile — check types, lengths and ranges server-side regardless of any validation the app already does.
• Rate-limit and throttle. Protect login and write endpoints against brute-force and abuse.
• Consider certificate pinning. For sensitive apps, pin your server’s certificate or public key to resist man-in-the-middle attacks on hostile networks.
• Protect your CI secrets. Your Apple signing certificate and provisioning profiles held in EAS, Codemagic or GitHub are high-value targets. Keep them in the platform’s encrypted secret store, restrict who can access them, and rotate immediately if exposed.
• Lock down the database. Give the app’s database user least privilege, keep the database off the public internet, and encrypt your backups.
• Mind the data-protection rules. If you handle personal data, UK GDPR applies: declare what you collect in the App Store privacy labels and make sure you have a lawful basis for it.

Where AI helps (and where to be careful)

AI can compress a lot of this work, with one firm rule: review anything security-sensitive yourself.

• Coding assistants. Tools like Claude Code, Cursor or GitHub Copilot are excellent for scaffolding React Native screens and generating the repetitive PHP API boilerplate — endpoints, PDO wrappers, input validation. Let them write the plumbing; you own the auth and data-handling logic.
• AI app builders. For a head start on the UI, FlutterFlow’s AI features or the AI-first builders (Newly, Rork, RapidNative, a0.dev) can generate a working React Native/Expo project from a prompt that you then refine by hand.
• Where to slow down. Don’t ship AI-generated authentication, cryptography, or SQL without reading it line by line. Generative models will happily write code that concatenates input into a query or stores a token insecurely. Treat anything generated as a first draft to audit — never a finished product.

The websites, in one place

The bottom line

For most people the answer is React Native + Expo with EAS Build: native iOS apps, written and shipped entirely from Windows, no Mac required, and no vendor lock-in. Choose Flutter if you want its UI polish and don’t mind Codemagic doing the build. Choose .NET MAUI only if your team is already a C#/.NET shop and you’re willing to keep a Mac in the loop for the iOS leg.

Put a clean PHP/MySQL JSON API behind whichever you pick, lock down the security basics, and you have a real product — built on the machine you already own.