How We Enrolled in the Apple Developer Program from India Without Owning a Mac

Getting an Apple Developer Program membership normally starts with an Apple device. In our case, we were working from a Windows PC and did not own an iPhone, iPad, or Mac that we wanted to dedicate to the enrollment process. Instead of buying Apple hardware just for this one job, we explored whether a real Mac could be accessed remotely through the cloud.

The solution we ended up using was Amazon EC2 Mac. What follows is the complete journey: allocating an Apple-silicon Mac in AWS, getting a remote macOS desktop working from Windows, fixing the problems we hit along the way, and completing the Apple Developer enrollment.

The problem: we needed a Mac, but didn't own one

The goal was simple: create an individual Apple Developer membership so we could use App Store Connect and Apple's development tools, without first purchasing a physical Mac.

Apple's current enrollment documentation says individuals can enroll through the Apple Developer app on a compatible iPhone, iPad, or Mac, and the same device is used throughout the enrollment process. India is also one of the regions where enrollment is handled through the Apple Developer app. That made a genuine Mac environment the most straightforward remote option for our situation.

Why Amazon EC2 Mac?

Amazon EC2 Mac is different from a normal cloud virtual machine. AWS provides Mac instances as bare-metal Apple hardware on Dedicated Hosts. We chose the mac2.metal family, which is an Apple M1 Mac mini configuration.

The trade-off is that Mac instances use a Dedicated Host and have a minimum 24-hour host allocation. The host is the important billing unit here, so this is not a service you treat like a tiny VM that can be switched on for five minutes and immediately released.

Getting the Mac host allocated

Our first obstacle appeared before the Mac even existed: the AWS account had a mac2 Dedicated Host quota of zero.

We requested a quota increase for Running Dedicated mac2 Hostsand waited for AWS Support to approve it. Once the quota became available, we allocated a Dedicated Host in us-east-1 and launched a mac2.metal instance directly onto that host.

Getting from Windows into macOS

The AWS Mac was running, but we still needed a practical way to control it from our Windows machine. We started with SSH.

ssh -i "apple-dev-mac-key.pem" ec2-user@<public-dns>

We created a fresh ED25519 key pair in EC2 and downloaded the private.pem file. On Windows, OpenSSH initially rejected the key because the file permissions were too open. We fixed the ACL so only our Windows user could read the key.

That gave us a working terminal on the Mac. The next challenge was the graphical desktop.

First GUI: Screen Sharing over an SSH tunnel

AWS documents using macOS Screen Sharing with an SSH tunnel for EC2 Mac. We enabled the Screen Sharing service and forwarded the Mac's VNC port to our Windows machine.

ssh -L 5900:localhost:5900 -i "apple-dev-mac-key.pem" ec2-user@<public-dns>

We then connected a VNC viewer to localhost:5900. This worked: we could see the actual macOS login screen and eventually reach the desktop.

But the experience was not especially smooth. Window changes and clicks could feel delayed, which led us to look for a better remote-desktop path.

Switching to Amazon DCV

AWS also supports Amazon DCV on EC2 Mac. DCV is designed for remote graphical sessions and gave us a better fit than continuing with the basic VNC route.

We installed the Apple-silicon DCV server package, verified that the installer was properly signed and notarized, and then configured the macOS privacy permissions required by DCV.

On the Mac, the relevant permissions were:

After granting those permissions, we rebooted the Mac as required by the setup process.

The DCV licensing problem

This was the most interesting AWS-specific problem we encountered. Creating a DCV console session initially failed with:

Could not create session.
No license available: AWS S3 bucket is unreachable

At first that looked like an internet problem, but the Mac could already reach the public internet and download the DCV installer. We tested S3 separately and confirmed that the instance could reach the regional S3 endpoint.

The missing piece was IAM. The EC2 Mac did not have an instance role that gave DCV permission to access the AWS-managed license object.

We created a small IAM role specifically for the Mac and granted only the required s3:GetObject permission for the regional DCV license bucket.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::dcv-license.us-east-1/*"
    }
  ]
}

After attaching the role, restarting the DCV service, and creating the session again, it finally succeeded.

Session: 'console' (owner:ec2-user type:console)

Setting up the Apple Account

With the remote macOS desktop working, we signed into the Apple Account we planned to use for the Developer membership and completed the initial macOS setup.

We used our real personal information for the individual enrollment. Apple requires the legal name for an individual membership, and that name is used as the seller name on the App Store.

Completing Apple Developer enrollment

We opened the Apple Developer app on the Mac and started the enrollment flow from the Account tab.

Apple Developer app
    ↓
Account
    ↓
Enroll Now
    ↓
Individual
    ↓
Personal information
    ↓
Developer Program agreement
    ↓
Purchase

In our particular enrollment flow, Apple did not ask us to upload a government ID. That is worth documenting because it was part of our actual experience, but it should not be treated as a guaranteed outcome: Apple's current documentation says identity verification and a government-issued photo ID can be required.

The membership purchase itself was successful. Initially, the Developer account showed Enrollment Pending, and the purchase also appeared as pending in Apple purchase history.

Pending to active

The waiting period turned out to be part of the process rather than a failed payment. Apple subsequently sent an email confirming access to App Store Connect.

When we checked the Developer account again, the previous membership status was pending. The full Developer Program resources became available, including App Store Connect and Certificates, Identifiers & Profiles.

What did it cost?

The Apple Developer membership was a normal paid Apple subscription. The AWS side was separate: the EC2 Mac generated normal AWS usage charges, but we already had promotional AWS credits available on the account, so the cloud infrastructure did not require a new out-of-pocket AWS payment during this experiment.

The important distinction is that AWS usage was not magically free. The Dedicated Host still accumulated the normal Mac infrastructure charge; our credits were simply applied against eligible AWS usage.

What we learned

The biggest takeaway was that the physical hardware requirement did not necessarily mean we had to own Apple hardware ourselves. By combining a real EC2 Mac with remote desktop access, we were able to complete the enrollment process from a Windows PC.

What this does not mean

This should not be interpreted as a universal way to avoid Apple hardware checks or identity verification. Apple can change its enrollment flow, request identity documents, or place an enrollment under additional review.

AWS also has its own account quotas, Mac availability, pricing, and Dedicated Host requirements. The approach is practical when temporary remote access to genuine Apple hardware is more useful than buying a Mac, but it is not necessarily the cheapest option for long-term iOS development.