PWABuilder Gave You an Xcode Project — Ship It With No Mac

You ran your PWA through PWABuilder, clicked the iOS package, and got a zip containing a Swift Xcode project — not an app. There are two real ways forward without buying a Mac: rent Mac time in the cloud and compile that project yourself, or set the Xcode project aside and use a cloud build service — like ours at code2native — that wraps your deployed PWA URL and compiles the IPA on Apple silicon for you. This article walks through both, with real costs and the catches nobody puts in the pitch.

The Mac requirement is not a misreading on your part. PWABuilder's own documentation says it plainly: to build the iOS project, you need a Mac with Xcode installed. Their Android and Windows platforms hand you store-ready packages, but iOS hands you source code. The feature request to close that gap — issue #2436 on the pwa-builder/PWABuilder GitHub repository, titled "[iOS] Build the iOS project for the user" — is still open, and their iOS FAQ has long said the team "may automate the build process" in the future. Until that ships, the build step is yours. Search for a workaround and you will mostly find two things: Mac rental services, and community GitHub scripts that compile the project on CI runners but leave you with an unsigned build and the whole signing problem still unsolved.

Option A: rent a Mac and build it yourself

This is the honest baseline, and for some people it is the right call. MacinCloud's managed plans currently start at about $25 to $29 per month depending on the hardware tier (M1 through M4), with pay-as-you-go options, and the machines come with developer tools preinstalled. You upload the PWABuilder zip, open it in Xcode over a remote desktop session, and follow PWABuilder's own publishing guide.

The friction is real, so budget for it: a remote macOS desktop is laggy compared to a local machine; you will create a certificate, an App ID, and a provisioning profile in the Apple Developer portal; you will archive and upload through Xcode; and every future update to the wrapper means repeating the session. A cheaper variant is a hosted macOS CI runner (for example GitHub Actions) driven by community scripts — that removes the rental fee but typically produces an unsigned IPA, and signing plus upload remain your problem.

When is Option A actually the better choice? If you have modified the PWABuilder Xcode project itself — custom Swift code, special entitlements, a tweaked shortcut configuration — renting a Mac is the only route that compiles your project. Everything below replaces PWABuilder's template rather than building it.

Option B: wrap the PWA URL and build in the cloud

Our route at code2native does not compile PWABuilder's Xcode project — we want to say that plainly up front. Instead, you paste the URL where your PWA is already deployed, and we generate our own iOS wrapper around it: a WKWebView shell with native push notifications, native navigation, and a splash screen, compiled into an IPA on real Apple silicon in our cloud. No Mac, no Xcode, no remote desktop. Your first build is free with a watermark, so you can see the result before paying anything, and failed builds auto-refund their credits.

The trade-off follows directly from the design: any customization you made inside the PWABuilder-generated Xcode project does not carry over, because that project is set aside entirely. For most PWABuilder users this costs nothing — the project was generated from your manifest and URL in the first place, and our wrapper is generated from the same URL. Since a PWA is by definition a deployed web app, there is no export step to worry about: the URL is the input.

One thing we cannot do, and neither can anyone else: Kotlin or Android code does not convert to iOS. If you also built an Android package, the iOS app is always a wrap of the web app, not a translation of the Android one.

Push notifications: web push vs native push

This is the detail most PWABuilder-to-iOS guides get wrong, so here is the precise picture. Since iOS 16.4, a PWA installed to the home screen through Safari can receive standard web push. But a store app built around WKWebView is a different animal: web push does not work inside WKWebView — Apple's own engineers have confirmed on the developer forums that an app with a WKWebView must use native push, not Web Push. Consistent with that, PWABuilder's stock iOS template ships without push notifications wired up at all; adding push support is a separate open request in their repository.

So if notifications matter to your app, compiling the PWABuilder project as-is gets you an app that cannot notify anyone. Our wrapper takes the native path: the wrapped app registers for push through Apple's APNs pipeline, which is the only kind of push a WKWebView app can receive. The honest caveat is that your existing web push subscriptions and VAPID setup do not transfer into the wrapped app — native push is a different delivery channel than the web push your PWA uses in the browser. You gain notifications that actually work in a store app; you do not get to reuse the browser-side subscription list.

Signing: the certificate split, and why we never ask for your Apple ID

One fact no service can wave away: shipping to the App Store requires an Apple Developer Program membership at $99 per year. That is Apple's fee, separate from anything we or a Mac rental charges, and there is no legitimate route around it.

What a build service can control is how signing is handled, and here is our split. If you export your Apple distribution certificate as a .p12 file and upload it with your build, the IPA we return is signed and store-ready. If you prefer not to hand a certificate to anyone, we return an unsigned IPA and you re-sign it with your own tooling. Both are legitimate; the first is convenient, the second keeps your key material entirely in your hands. What we never ask for is your Apple ID or password — a service that wants your account login should worry you, because that is your whole developer identity, not just one app's signature.

The last mile deserves honesty too: the standard tools for uploading a signed IPA to App Store Connect are Xcode and Apple's Transporter app, both Mac software. Without any Mac at all, people use third-party upload tools or a few minutes of a hosted macOS CI runner for that single step. It is a smaller problem than building, but it is not zero.

Guideline 4.2: the rejection risk both routes share

Apple's App Review Guideline 4.2, "Minimum Functionality," is the rule that rejects apps which are just a website in a frame. It applies with exactly equal force to an app compiled from PWABuilder's template on a rented Mac and to an app wrapped by us — the reviewer sees a finished binary either way, and anyone who tells you their wrapper is immune is selling something.

What you can do is give the reviewer app-like behavior to point to. Our wrapped apps ship with the three defenses we consider the minimum: native push notifications (something a Safari tab cannot do in a store context), native navigation instead of browser chrome, and a proper splash screen. These raise your odds; they do not guarantee approval. If your PWA is essentially a brochure — static pages a browser serves just as well — expect trouble under 4.2 no matter who builds the wrapper, and consider whether the App Store is worth the fight at all. Apps with accounts, workflows, offline behavior, or messaging tend to have a much easier review conversation.

If a 4.2 rejection does land and the store turns out not to be essential, the next section is your exit.

The zero-signing escape hatch: an iOS Web Clip

There is a third route that skips Apple's review, Apple's $99 fee, certificates, and Macs simultaneously: a Web Clip. It is a small .mobileconfig configuration profile that installs your PWA as a full-screen icon on the iOS home screen. We generate these too, and the trade is stark in both directions.

What you get: an installable home-screen app in minutes, with no Apple Developer account, no signing, no store review, and nothing to build. What you give up: there is no push notification support, the app is not on the App Store (so no discoverability and no store listing to link), and installation requires the user to open the profile and approve it in Settings — a couple more taps than an App Store install, and unfamiliar to some users.

In practice Web Clips fit internal tools, client pilots, kiosk-style deployments, and any audience you can hand a link directly. They also serve as the fallback if Guideline 4.2 rejects your wrap: the same PWA URL that fed the wrapper feeds the Web Clip, so switching costs you nothing but the store presence.

The whole route, start to finish

Here is the no-Mac path condensed, assuming your PWA is already live. First, set the PWABuilder zip aside — you will not need it on this route. Second, paste your deployed PWA URL into code2native and configure the app name, icon, splash screen, navigation, and push. Third, run the free first build (it carries a watermark) and check the result. Fourth, decide your signing posture: upload your .p12 distribution certificate for a store-ready signed IPA, or take the unsigned IPA and re-sign it yourself. iOS builds are part of our Pro plan at $99 per month for 30 build credits; Android-only starts at $29 per month for 10 credits, and a Single App option is $149 one-time for one app with lifetime updates. Any failed build refunds its credits automatically. Fifth, upload the signed IPA to App Store Connect and submit for review with your 4.2 defenses — push, native navigation, splash — enabled and mentioned in your review notes.

And keep the honest ledger in view: Apple's $99 per year developer fee applies regardless of tooling, review approval is never guaranteed for any wrapped web app, and if the store stops being worth it, the Web Clip route ships the same PWA to home screens with none of the above.

Ship the PWA this week

Paste your PWA's URL into the build wizard and pick iOS — the IPA compiles on cloud Apple silicon, signed with your certificate or unsigned for re-signing. The full no-Mac reference lives in our iOS-without-a-Mac guide, and the App Store checklist covers the submission itself.