Apple & Google Play Developer Accounts: Tracking App Store Renewals for Web Agencies

Article image
Apple & Google Play Developer Accounts: Tracking App Store Renewals for Web Agencies
When web design and development agencies expand into Progressive Web Apps (PWAs), hybrid builds, or dedicated companion apps, they take on an entirely new operational domain. Domains, hosting, and SSL certificates are no longer the only assets on the clock. To publish anything to the Apple App Store or Google Play Store, an agency has to operate inside two proprietary developer ecosystems, each with its own billing cadence, ownership rules, and failure modes.

The Apple Developer Program costs $99 USD per year. Google Play charges a one-time $25 USD registration fee. Because these are billed separately from web hosting and DNS, they're easy to lose track of during a routine agency audit — and the consequences of missing one are different for each platform. This guide breaks down what actually happens when each account lapses, the account-ownership model Apple's guidelines require, and how to build a tracking system that catches both before they become a client emergency.

1. Two Asset Classes: Web Infrastructure vs. Mobile Developer Accounts Web agencies are used to managing domains, managed WordPress hosting, and transactional email. Native or packaged web apps add a second, largely unrelated asset class:

Traditional Web Assets Mobile & App Store Assets
Domain registrations Apple Developer Program ($99/yr)
DNS management (Cloudflare, etc.) Google Play Console ($25 one-time)
Web hosting & VPS servers iOS Distribution Certificates & Provisioning Profiles
SSL/TLS certificates APNs keys / Website Push IDs (native or Safari push)
The Apple Developer Program: what actually happens when it lapses
Cost: $99/year for the standard Individual or Organization membership. Apple also runs a separate $299/year Enterprise Program for internal, non-App-Store distribution to a company's own employees — that's a different product, not a discount tier. Apple does offer a membership fee waiver for qualifying nonprofits, accredited educational institutions, and government entities publishing free apps, which is worth checking before assuming every client owes the full fee.

Consequence of lapsing: This is where a lot of write-ups overstate things. According to Apple's own account-renewal documentation, once a membership expires, the app becomes unavailable for new downloads and can't be updated or resubmitted — but it does not vanish from users' devices. Apps already installed keep working. Apple also gives Account Holders a window around the expiration date (commonly cited as roughly 27–30 days in current developer reports) to renew before the listing is pulled from the Store, and enterprise in-house apps specifically continue running for existing installs for up to 90 days past expiration as long as their certificates and provisioning profiles are still valid. So the realistic failure mode isn't "the app disappears from every phone the instant the invoice is missed" — it's "the app stops being discoverable and installable, and current users are frozen on whatever version they already have."

Certificates are a separate risk from the membership itself. This distinction matters for how you build a tracking SOP: if an app is already live on the App Store, an expired or revoked iOS Distribution Certificate does not pull the app down or break it for existing users — Apple re-signs App Store builds with its own signing identity at submission time, so your certificate only needs to be valid at the moment you upload a new version. What an expired certificate blocks is your ability to submit the next update. Provisioning profiles and distribution certificates typically run on their own one-year clocks, independent of the account's annual renewal date, which is exactly why they need to be tracked as a separate line item rather than assumed to renew alongside the membership.

The Account Holder bottleneck is real. Only the Account Holder — the Apple ID that completed enrollment — can pay the renewal or accept updated license agreements. Full Admin access in App Store Connect doesn't grant that ability. If the Account Holder is a former employee or an unresponsive client contact, that's the actual risk to track, more than the calendar date itself.

The Google Play Console: what actually happens when it lapses
Cost: A one-time $25 registration fee — no annual renewal. This is the single biggest structural difference from Apple's model, and it's why many small businesses launch on Android first.

Google doesn't charge annually, but it does prune accounts. According to Google's current Play Console policy, an account is marked for closure due to inactivity if it meets either of two conditions: it has never used Play Console in the last 180 days (combined with under 1,000 lifetime installs across all its apps and an unverified account phone number/email), or the account is over a year old and has never submitted an app at all. Google sends reminder emails at 60, 30, and 7 days before closure, and the $25 fee is not refunded if the account is closed. This is a materially longer and more specific window than the vague "60–90 days of any inactivity" some guides describe — the actual trigger is 180 days of Play Console inactivity plus the install/verification conditions, not a blanket short inactivity timer.

New personal developer accounts face a closed-testing gate, not an old registration hurdle. Any personal Google Play account created after November 13, 2023 must run a closed test with a minimum of 12 continuously opted-in testers for 14 consecutive days before Google will grant production access. That number was originally 20 testers when the policy launched, and Google lowered it to 12 in December 2024 — so if an agency is scoping timeline for a client's first Android submission, 12/14 is the current bar, not 20. Organization accounts verified with a D-U-N-S number are exempt from this testing requirement, which is one more reason to push clients toward properly verified organization accounts rather than personal ones.

1. PWA Store Packaging: Where the Real Fragility Lives Progressive Web Apps let agencies ship cross-platform experiences using standard web technology, but "Add to Home Screen" alone limits reach. To get store placement, PWAs need to be packaged — and the two platforms are not symmetrical in how well-supported or how risky that packaging is.

Android has a genuinely supported path. Google's own path is the Trusted Web Activity (TWA) — an Android wrapper that renders your PWA using the full Chrome engine rather than a stripped-down WebView. The standard tools are Bubblewrap (Google Chrome Labs' CLI) or PWABuilder, which uses Bubblewrap under the hood for its Android output. Setup requires a valid web manifest served over HTTPS and a Digital Asset Links file (.well-known/assetlinks.json) hosted on your domain, which cryptographically proves the Android package and the website belong to the same owner. If that domain's DNS changes or the domain lapses, the verification breaks and the TWA falls back to showing browser chrome instead of behaving like an installed app.

iOS packaging is not the same kind of path, and treating it as parallel to Android is where agencies get burned. PWABuilder can also generate an iOS package, but it does so via a WKWebView wrapper — essentially a native shell that just displays your website. Apple's App Review Guideline 4.2 (Minimum Functionality) exists specifically to catch apps that are "merely a website" with no native functionality layered on top, and WKWebView wrapper submissions are a known rejection risk unless real native features are added. This isn't a minor technical footnote — it means an agency can't quote "wrap the PWA for both stores" as a symmetric line item. The Android build is a supported, low-risk path; the iOS build is a submission gamble that needs its own scoping conversation with the client.

A correction worth making explicitly to clients: iOS web push does not require an Apple Developer account at all — for a browser-installed PWA. Since Safari 16 / iOS 16.4, Apple supports the standards-based Web Push API (the same Push API, Notifications API, and Service Worker stack used on Android and desktop browsers), and Apple has stated directly that developers do not need to be an Apple Developer Program member to implement it. The catch is that the user has to install the site via "Add to Home Screen" first — there's no install prompt or app-store discovery step. Where the $99/year account genuinely does become a dependency is the older, proprietary Safari Website Push ID mechanism, and separately, true native push (APNs) inside a wrapped App Store app that's been through App Review. So: a plain home-screen PWA's push notifications survive an Apple Developer Program lapse just fine; a wrapped, App-Store-distributed app's native push does not. Agencies should track which architecture each client is actually running before promising push notification uptime guarantees tied to the developer account renewal.

Domain association files still matter for deep linking regardless of packaging path. Both .well-known/assetlinks.json (Android) and .well-known/apple-app-site-association (iOS universal links) need to keep resolving on the production domain. If the underlying domain lapses or DNS changes, deep-linking breaks even while the developer account itself is perfectly current — one more reason domain tracking and app-store-account tracking need to live in the same system rather than two disconnected spreadsheets.

1. Account Ownership Architecture A recurring question for agencies building companion apps: should the app live under the agency's own developer account, or the client's?

Agency-Owned (Umbrella) Client-Owned (Delegated Access)
Risks conflict with Apple's IP-ownership guideline Complies with Apple's ownership requirement
Single point of failure across all clients Risk isolated to one client's account
Harder to transfer the app later Clean asset ownership and billing
The relevant Apple rule is Guideline 5.2.1 (Legal — Intellectual Property), not "5.2.2." Apple's language is that apps must be submitted by the person or legal entity that owns or licenses the intellectual property and other relevant rights — in practice, an app built for a business should be published under that business's own Apple Developer account, not an agency's shared account. Getting the guideline number right matters if you're citing it to a client's legal or compliance team.

The recommended model is still client-owned accounts with delegated access. The client enrolls in their own Apple Developer Program and Google Play Console accounts; the agency receives Admin or Developer-level access inside App Store Connect and Play Console. This keeps risk isolated — if one client's app gets flagged, it doesn't jeopardize any other client sitting under the same umbrella account — and it keeps the legal ownership of the listing, reviews, and analytics squarely with the client, which matters if the agency relationship ever ends.

The trade-off is operational, not legal. Client-owned accounts are correct on paper but they hand renewal responsibility to whichever person at the client controls the billing card and monitors the [email protected]-style inbox Apple's renewal notice lands in. That's the actual gap an agency needs to plug — not by taking ownership back, but by tracking the renewal date independently of whether the client is watching it.

1. A Renewal-Tracking SOP for Agencies Step 1 — Inventory every developer entity you touch. For each client with a published or in-progress app, record: legal account name, Account Holder's Apple ID / Google account email, current membership status and renewal date, auto-renewal on/off, and the associated certificates, provisioning profiles, and keystores.

Step 2 — Build in a real buffer before the actual cutoff. Apple typically starts surfacing renewal reminders around 30 days out and gives a further post-expiration window (commonly reported in the high-20-days range) before pulling a listing — but because Account Holder access is often the actual blocker, not the calendar date, start the client conversation well before that, ideally 60 days out, so there's time to resolve access problems rather than just pay an invoice.

Step 3 — Track certificates and profiles as their own line item. Because a distribution certificate's expiration doesn't affect an already-published app (only the next submission), don't let cert renewal alerts get confused with membership renewal alerts in your reporting — they represent different risks with different urgency.

Step 4 — Separately track Google Play's inactivity clock if a client's app goes quiet. An app with low installs that hasn't touched Play Console in 180 days is a real, if slower-moving, risk — worth a periodic check even though there's no annual invoice to trigger a reminder.

1. Where InstaRenewal Fits Scattershot spreadsheets tend to fail here for a simple reason: nobody remembers to update them once an asset is live and "working." What agencies actually need is a single place that holds every renewal date and every ownership record — domains, SSL certificates, and app store accounts alike — so nothing falls through the cracks between departments or between an agency's own team and a client's billing contact.

InstaRenewal is built for exactly that: a renewal-date tracker and asset-ownership record-keeping system, not a live monitor or an automated scanner. You enter the dates and ownership details yourself — who holds the Apple ID, who owns the Google Play account, when each membership is due — and InstaRenewal keeps that ledger organized and reminds you against the dates you've logged.

Asset Type Resource Renewal / Expiration Who's Responsible
Domain app.client.com Oct 15, 2026 Client (direct)
SSL Certificate Let's Encrypt Nov 2, 2026 Agency (care plan)
Apple Developer Program Acme Corp account Dec 1, 2026 Client (tracked by agency)
Google Play Console Acme Corp account One-time — no renewal Client (tracked for inactivity)
What this gives an agency in practice:

A "who owns it" vs. "who's watching it" record. You can note that the client owns and pays for the $99/year Apple account while the agency is the one tracking the renewal date and flagging it before it becomes a crisis — which avoids both unbilled surprise expenses and the "why didn't anyone tell us" conversation when a listing drops.
Renewal reminders tied to the dates you've entered. Configure alerts ahead of a logged expiration date so a lapse doesn't get discovered the day an app disappears from search.
Records linked across related assets. Log the Apple Developer account, the domain it depends on for apple-app-site-association, and the SSL certificate on the same web property together, so when one changes, you have a reason to check the others.
A place to log certificate and provisioning profile dates alongside the account-level renewal, so the two risks stay visibly separate instead of getting conflated in a single "app store stuff" reminder.

1. Conclusion Expanding into PWAs and mobile distribution opens a real revenue line for web agencies, but it also imports two billing relationships and one genuinely fragile technical path (iOS PWA wrapping) that a purely web-focused ops process isn't built to catch. The failure modes are more specific than "the app disappears the moment a bill is late" — Apple gives a renewal window and keeps existing installs running, Google's account-pruning clock runs on 180 days of inactivity rather than a short timer, and a lapsed distribution certificate is a very different problem from a lapsed membership. Getting those distinctions right — and logging the actual dates and ownership records in one place rather than across scattered inboxes — is what keeps a client's app store presence from becoming the thing that quietly breaks while everyone's watching the domain and SSL renewals instead.