Windows-Only Founder Who Shipped iOS and Android Apps Without Touching a Mac
Cloud services let Windows developers build and ship iOS apps without owning a Mac.
A Windows-only founder can publish an AI-built iOS and Android app to the App Store and Google Play without owning a Mac or installing Xcode locally. A visual app platform or cloud build service does the Mac-only work on a remote machine. Matt Busel’s account of his pipeline shows how this works and where it can get stuck, from signing and backend setup to Apple’s review process.
Why a Windows-only founder shipping iOS and Android apps is a story worth telling in 2026
“You need a Mac to make an iPhone app” is still repeated because it contains a narrow technical truth. Apple’s tools run on macOS, including Xcode, code signing, and the iOS Simulator. But that does not mean the founder’s computer must run them. The hardware requirement belongs to the build process. In 2026, cloud services let a founder use that hardware without buying it or sitting in front of it.
Android never imposed this Apple-specific constraint, so getting an iPhone app through Apple’s system is harder for a Windows-only founder. Busel’s guide on a developer community site documents 21 iPhone apps sent to App Store Connect from a Windows PC between September 10 and September 27, 2026, with eight live on the US App Store. Uploading a working build shows that the pipeline works, but the app must also pass App Review to be published.
How can you publish an iOS app without owning a Mac or installing Xcode?
An iOS build must still be created on a Mac, but that Mac can be running in a data centre. A founder can invoke it from a Windows terminal through a cloud service. Think of writing a book versus printing it. The author can use whatever computer is at hand, while the print shop has the equipment to turn the book into a printed copy.
The same split applies to mobile development. Writing code, editing project files, managing store listings, uploading screenshots, and handling in-app purchases involve work that can run on any operating system. The Mac-only build stage compiles the app, signs it, and handles the binary’s journey toward submission. That is the stage the cloud takes over. React Native with Expo is the code layer, while EAS, short for Expo Application Services, compiles the iOS app on a remote machine.
Since the April 28, 2026 App Store gate change, some cheaper configurations once recommended online can no longer make builds that the store accepts. A service needs a compliant build environment. That distinction becomes important when choosing the pipeline, because the founder depends on the provider to maintain it.
Matt Busel's pipeline: what 21 apps shipped from Windows actually looked like
Busel’s guide describes a pipeline built around GitHub Actions running on macOS workers, Fastlane for signing through an API, and EAS Submit for the final upload to App Store Connect. GitHub supplies the remote Mac. There is no charge to use those workers for public repositories. Private repositories pay by the minute, which makes the duration of each build part of the cost.
On a successful run, the macOS worker picks up Xcode and compiles the app quickly, then imports the signing certificate almost instantly. Fastlane does the build and signing work in the submission pipeline. Total elapsed time was well under five minutes. Getting there took more effort than running it afterward, though, with the first app requiring 13 failed continuous integration runs.
The App Store Connect API returned a 403 when Busel tried to create the initial app record, so he created it in a browser. That took about a minute per app and did not require a Mac. Automating compilation does not remove every administrative task, and uploading all 21 apps did not guarantee that Apple would publish them.
The three real paths a Windows-only founder can take, and how to choose between them
The first path is a no-code platform with server-side iOS compilation, which best fits non-developer business owners. Its backend starts a Mac build agent, compiles and signs the app, and returns an IPA, the iOS app package. The founder never sees a terminal. FlutterFlow offers visual building for iOS, Android, and web, with AI features that generate screens, components, and full apps from prompts or Figma designs.
Thunkable offers AI-assisted app generation within a visual mobile workflow, making it useful when generated work is a starting point the founder wants to refine. Bravo Studio turns tagged Figma designs into native mobile apps and links them to data sources such as Airtable, REST APIs, or JSON. These are real app-building paths, not just mockup tools. Their shared trade-off is dependence on the platform’s editor and build service. Unsupported features remain out of reach, and a platform shutdown takes its build pipeline with it.
The second path is to rent a cloud Mac from a service such as MacInCloud or MacStadium. A developer connects from Windows through remote desktop and works on a real Mac that has Xcode. This works well for someone who already knows how to build iOS apps. It is a poor starting point for a first-time builder because remote-desktop latency makes visual work slower, and access to Xcode does not teach someone how to use it.
The third path is a cross-platform framework plus cloud continuous integration, or CI, as in Busel’s setup. A technical founder writes React Native or Flutter code on Windows and pushes it to GitHub. GitHub Actions macOS runners, Codemagic, or Bitrise then compile on a Mac instance, sign the IPA, and upload to TestFlight. The founder owns the code and can build a professional pipeline. Busel’s early failed runs show the price of that control in learning time.
What building this way actually costs, line by line
The fixed entry cost on the Apple side is $99 per year for the Apple Developer Program. That fee covers testing on a real iPhone, submitting to TestFlight, and publishing to the App Store. A Mac purchase is not part of that minimum. The next cost depends on whether the founder uses a visual platform, pays for cloud builds now and then, or keeps access to a remote computer.
Expo’s EAS Build pricing as of October 2026 includes a free plan with a limited number of Android and iOS builds each month in a low-priority queue. Expo warns that peak-time waits can be substantial. Its Starter plan charges a low monthly fee with build credit, while a higher-priced plan charges more and includes a larger credit. Builds beyond the included credit incur additional charges based on platform and machine size.
GitHub Actions offers another cost pattern, with free macOS workers for public repositories and per-minute charges for private ones. Busel’s median release used only a few minutes of Mac time, putting each release at a fraction of a dollar. Renting a cloud Mac for light use costs roughly $30 to $60 per month, while heavy use costs much more. That spend is justified when persistent Xcode access is needed beyond a short build.
The larger expense is often developer time. A lean stack using Cursor Pro, Supabase’s free tier, and Railway’s starter offering can cost less per month than one hour of freelance development. The right tool choice can avoid work a founder would otherwise pay someone to do. Mobile subscriptions add a separate business constraint, because Apple and Google take a significant percentage compared with Stripe’s pay-as-you-go web payment model.
The backend layer every mobile app needs — and what Windows founders typically underestimate
A finished IPA is not a running business. Authentication, storage, subscriptions, notifications, and email sit outside the compilation pipeline. A successful cloud build says nothing about whether those services are ready. This is where a founder who has secured the hardware needed to build an app can still find a launch stalled by less visible infrastructure.
In a standard Expo and React Native stack, the app framework handles the interface, navigation, and native device features. Supabase Auth provides sign-up, login, and social authentication, while Supabase PostgreSQL stores data with row-level security. RevenueCat manages subscriptions and validates receipts. EAS handles cloud builds, App Store submissions, and over-the-air updates.
Those integrations can also affect approval. Apple says an app must have Apple Sign-In if it has another third-party sign-in method. Missing it can cause App Review rejection.
Where the Mac-free path still has genuine friction in 2026
The April gate change exposed a dependency that Windows-only founders cannot control directly. The cloud provider must keep its build environment compliant with App Store requirements. Some previously usable configurations no longer qualify. Remote hardware removes the purchase, but it does not remove Apple’s rules about what can produce an accepted build.
Platform choice creates a different limit. Native SwiftUI can do more than a cross-platform wrapper, although that gap rarely becomes decisive in the first year for a non-technical founder building a business app, with consumer games and AR experiences outside that scope. The intended product determines the risk. The share taken from subscriptions can also change whether mobile-first is right for the business, even when the app is easy to publish.
App Review was the larger obstacle in Busel’s release record. His guide reports that 13 of the 21 apps never reached the App Store, all 21 received at least one rejection, and none were approved on the first submission. Even with a fast build, he could not count on an approval date. This is not an argument against Windows, because a developer using a Mac faces the same review process.
What a second documented founder's revenue shows about the model's commercial viability
Paul Waweru built and sold a React Native boilerplate originally combining Expo, Supabase, and Stripe. The product later expanded beyond its original foundation to include tRPC, Prisma/Postgres, and additional payment providers. His TrustMRR dashboard showed strong all-time Stripe revenue as of September 1, 2026, with approximately 80 users and one-time pricing per licence.
The example extends the business case in a specific way. The tools and integrations used to make an app can themselves become something customers buy. In Waweru’s case, the product was the reusable starting point. The pipeline became part of the product. His stack overlaps with the Mac-free route described here, showing commercial value in the same building blocks without making revenue a guarantee for every app built with them.
The practical starting point for a Windows-only founder who wants to ship this week
The first decision is the kind of app and the level of ownership needed. For a business tool or internal app built around a spreadsheet or data layer, the practical starting point is FlutterFlow or Thunkable with server-side compilation. That route avoids the terminal and ships fastest for this profile. The work begins in a visual editor rather than with remote-desktop setup or build scripts.
For a consumer app where owned code and rapid iteration are priorities, the starting point is React Native with Expo and GitHub Actions macOS runners. The $99 Apple Developer account is the only required purchase on day one for this route. The time commitment is different from the visual path, though. Busel’s first app shows why the launch plan needs time to learn the pipeline before the final upload.
Before setting a launch date, check that the chosen service makes builds the App Store accepts now. That is the most important due-diligence step because compliant cloud infrastructure is now a dependency of the release. A founder aiming to ship this week should choose the route that fits the app and the available technical confidence, then establish that valid build path. Start with the service that will produce the app, not with shopping for a Mac.
