DEV Community: Preciousky

Google's Play Billing v8 deadline and Apple's 7-day subscription rule — two IAP gotchas costing real rejections

Preciousky — Tue, 22 Sep 2026 05:23:27 +0000

If you added Google Play Billing or Apple StoreKit to your app a year or two ago, there are two rules worth re-checking today — one has a hard deadline that already passed, the other is easy to miss entirely.

Android: Google now requires Play Billing Library v8 for every update

Since 31 August 2026, Google requires every new app and every update to an existing app to use Play Billing Library version 8 or later (source). This isn't limited to apps that are adding a new in-app purchase — any update at all gets bounced if the app is still wired to an older Billing Library version. A one-time extension to 1 November 2026 is available on request, but after that there's no more slack.

If your app has had Play Billing sitting untouched since v4/v5/v6, your next routine update — a bug fix, a UI tweak, anything — fails review unless the library is upgraded first.

We integrate Google Play Billing, or upgrade an existing integration to v8+, for a fixed ₹7,999 in 5-7 working days: https://zoopcoder.com/services/in-app-purchase-integration.php

iOS: subscriptions have a 7-day floor, and purchased credits can never expire

Two things people miss in Apple's App Store Review Guidelines when wiring up StoreKit:

Guideline 3.1.2(a) — an auto-renewable subscription must last at least seven days and work across all of a user's devices. A one-day or one-hour "pass" cannot be sold as a subscription; it has to be a consumable purchase instead.
Guideline 3.1.1 — any credits or in-game currency sold via in-app purchase may not expire. If you're building a coin or credits economy, design for that from day one; retrofitting non-expiry later usually means a data migration.

Both are straight from developer.apple.com/app-store/review/guidelines — easy to miss because they read as review rules, not technical requirements, but App Review enforces them at submission.

We do the iOS side too — StoreKit 2, server-side receipt verification (not just on-device, since a jailbroken client can fake a local check), and the Restore Purchases flow Apple's review specifically checks for — fixed ₹7,999, 5-7 working days: https://zoopcoder.com/services/ios-in-app-purchase-integration.php

Disclosure: I work at ZoopCoder, an Indian dev studio — sharing this because both the deadline and the guideline text cost real teams real rejections this year, not just as a pitch.

Cloudflare's "Flexible" SSL trap, and the real DNS wait time for a hosting migration

Preciousky — Mon, 21 Sep 2026 22:23:29 +0000

Two mistakes come up constantly when small businesses move hosts or put Cloudflare in front of a WordPress site. Both are documented, both are avoidable, and neither gets explained clearly enough in the usual how-to posts.

The Cloudflare redirect loop nobody expects

If your web server already redirects HTTP to HTTPS (most do, by default, on any half-decent host), and you set Cloudflare's SSL/TLS mode to "Flexible", you get an infinite redirect loop. Cloudflare's own docs say it plainly:

"If your origin forces HTTPS by automatically redirecting HTTP requests to HTTPS, do not use Flexible mode. Because Cloudflare connects to your origin over HTTP, this creates a redirect loop that makes your site inaccessible."

Source: developers.cloudflare.com/ssl/origin-configuration/ssl-modes/flexible

The fix is one dropdown: switch to Full or Full (strict) mode so Cloudflare validates against your origin's real certificate instead of connecting over plain HTTP. It's the single most common reason a DIY Cloudflare setup takes a working site down within minutes of flipping the nameservers — ERR_TOO_MANY_REDIRECTS in the browser, no obvious cause in the Cloudflare dashboard.

How fast does a DNS change actually happen?

Worth knowing precisely, since "up to 48 hours" gets thrown around vaguely everywhere: Cloudflare's proxied (orange-cloud) DNS records carry a fixed TTL of 300 seconds that you cannot lower. Plain DNS-only (grey-cloud) records can go as low as 60 seconds on any paid plan, 30 seconds on Enterprise.

The catch: a low TTL only controls how long compliant resolvers cache a record. Some ISP-level resolvers ignore the TTL you set and hold onto the old address for up to 24-48 hours regardless. That's why a careful migration or Cloudflare cutover is planned around that worst case — test on a temporary address first, switch DNS last — rather than promising an instant cutover.

If the domain name itself is changing too (not just the host), that's a different problem entirely: Google's Change of Address tool in Search Console needs 301 redirects held live for at least 180 days before Google stops crediting the old domain. After that window, Google treats the old site as unrelated.

Disclosure: I work with ZoopCoder, where we run this exact process for clients — Cloudflare setup for a fixed ₹1,499, and website migration to new hosting for a fixed ₹1,999, usually 1-2 working days. Sharing the underlying facts here in case they save someone else a redirect-loop debugging session.

PWA cost in India, and the Play Store ASO myth that wastes founders' money

Preciousky — Mon, 21 Sep 2026 01:20:45 +0000

Two founder questions I keep getting asked lately, so here are the honest, sourced answers instead of the usual agency folklore.

1. What does it actually cost to turn a website into an installable PWA?

A Progressive Web App needs exactly three things: HTTPS, a web app manifest, and a service worker. With those in place, Chrome on Android offers "Install app" and the site opens full-screen from the home screen — no Play Store account, no review, no store fee.

At ZoopCoder we ship this as a fixed-price add-on for an existing website: ₹3,999, 2-4 working days. It is not the same product as converting a website into a real Play Store app (that's a separate ₹4,999 service) — a PWA never shows up in Play Store search, it only installs from the browser.

One underrated fact for iPhone owners worried about "will my PWA lose its data if I don't open it for a while": Apple's WebKit engine normally wipes all script-writable storage (localStorage, IndexedDB, service worker caches) for any site you haven't interacted with in 7 days — that's Intelligent Tracking Prevention (ITP), in Safari since 13.1. But WebKit explicitly documents an exemption for installed apps:

"The first-party domain of home screen web applications is exempt from ITP's 7-day cap on all script-writeable storage."
— webkit.org/tracking-prevention

So a PWA installed on an iPhone home screen keeps its offline data even after weeks of not being opened — a bookmarked Safari tab would not.

2. The Play Store ASO myth that wastes money: stuffing keywords into your listing does not help

This one costs founders real money because it's intuitive and wrong. Google's own Play Console guidance on unnecessary keywords in store listing text is blunt:

"It will not impact ranking and provides a bad user experience."
— support.google.com/googleplay/android-developer/answer/9866151

And on what actually drives ranking, Google states plainly that apps are ranked on "a combination of ratings, reviews, downloads, and other factors" that are "a proprietary part of the Google search algorithm" — support.google.com/googleplay/android-developer/answer/4448378. A rewritten title and description move relevance, not the whole outcome. Nobody — including us — can honestly promise a rank position.

What actually works: a title within Play's 30-character limit that says what the app does (not just the brand name), a short description within 80 characters, and a full description written for humans first, keywords second. Google's policy also caps repetition — using the same keyword more than 5 times across your metadata reads as spam, not optimization.

We do this as a fixed ₹2,499 listing rewrite with keyword research included, 3-4 working days — no rank guarantee, because nobody can honestly give you one.

Disclosure: I work at ZoopCoder, an Indian dev shop. These are our real, currently-listed prices, not hypotheticals. Service pages if useful: PWA conversion and Play Store ASO.

Google Play vs Apple Developer Accounts in India: Real Costs, the D-U-N-S Trap, and When You Can't Choose Personal

Preciousky — Thu, 17 Sep 2026 05:23:24 +0000

Setting up your own developer account is the very first step before you can publish anything on Google Play or the Apple App Store, and most guides skip the parts that actually cost people days: the account type you are allowed to choose, and how long identity verification really takes.

Disclosure: I work with ZoopCoder, an Indian dev studio that offers these as fixed-price setup services — Play Console at ₹999, Apple Developer at ₹1,999. Everything below is sourced straight from Google's and Apple's own developer documentation, linked inline.

What each one actually costs

Google Play: a one-time US$25 registration fee, ever. Google's own account creation guide confirms it is a single payment, not a subscription.
Apple: US$99 every year, and it does not lapse quietly — when the membership expires, your apps come off the App Store. Apple confirms the fee is recurring here.

The account-type trap nobody mentions

Both stores let you pick Personal/Individual or Organisation — but Google's documentation says the choice is not actually optional for everyone. Straight from Google's account-type page:

"You should choose an organization account if you provide any of the following services: Financial products and services, including but not limited to banking, loans, stock trading, investment funds, cryptocurrency software wallets, and cryptocurrency exchanges... Health apps... Apps approved to use the VpnService class... Government apps"

So if you are building a lending app, a health app, a VPN, or anything government-facing, Google requires the Organisation account type regardless of team size — Personal is not an option for you.

The D-U-N-S number timeline that blows up launch dates

An Organisation account (either store) needs a D-U-N-S number from Dun & Bradstreet. It is free, but Google's own setup requirements page says plainly: "This process can take up to 30 days, so you should plan ahead." People assume it is instant because the number itself is free — it is not, and if your org does not already have one, that is a month added to your timeline before you can even start creating the account.

What breaks accounts after they are already live

One thing almost nobody warns you about: your payments profile (legal name + address) has to keep matching your D-U-N-S record exactly. If it drifts — say your company's registered address changes — Google shows a "your organization name or address is no longer verified" banner and restricts the account, which removes your apps from Google Play, until the mismatch is fixed.

Quick reference

	Google Play	Apple App Store
Fee	US$25 one-time	US$99/year, recurring
Org account requires	D-U-N-S number (up to 30 days to get)	D-U-N-S number
Personal account extra step	12 testers, 14-day closed test (accounts opened after 13 Nov 2023)	none
Consequence of lapse	none — one-time fee	apps pulled from the App Store

If you would rather have someone walk you through the forms instead of hitting these gotchas cold: ZoopCoder does the Google Play side for a fixed ₹999 (Play Console Developer Account Setup) and the Apple side for a fixed ₹1,999 (Apple Developer Account Setup) — both done on a screen share, D-U-N-S filing included where needed.

Website to Android App in 2026: Two Play Store Rules That Silently Reject Free Converter Output

Preciousky — Tue, 15 Sep 2026 22:23:14 +0000

Free website-to-app converters export something. Whether Google Play will accept it is a different question. Disclosure up front: I work with ZoopCoder, an Indian shop that builds and submits these apps for a fixed fee, so I have a commercial interest in this answer — but the two rules below are Google's own, not ours, and are worth knowing before you spend a rupee anywhere.

Rule 1: Play has not accepted a plain APK for a new app since August 2021

Google Play requires new apps to be submitted as a signed Android App Bundle (.aab), not a raw APK. This has been true since August 2021, so it isn't new — but a lot of free "website to app" converter tools still hand you a bare .apk file, because building an AAB means the tool has to manage a proper signing keystore for you, which is more than a wrapper script usually does.

If your converter's output is a .apk and not a .aab, you cannot upload it as a new app. Full stop.

Rule 2: every app must target API level 36 (Android 16) — enforced from 31 August 2026

Since 31 August 2026, Google requires new apps and app updates to target API level 36 (Android 16) to be submitted to Play at all. A converter built even a year ago, targeting an older API level, produces a bundle Play will now reject outright — not "flag for review," reject at upload.

There was a one-off extension available (to 1 November 2026) for developers who filed for more time through Play Console, but it does not renew, and a brand-new project has no reason to ask for it — it should just target 36 from the start.

What this means practically

If you already have a website and want it on Google Play, the wrapper approach (website content shown inside a native Android shell, with an icon, splash screen, offline handling, and native link handling for things like WhatsApp/phone/maps links) is still the fastest, cheapest route to an app — usually far cheaper than a full native rebuild. But the deliverable has to actually be:

a signed .aab, not an .apk
targeting API 36, not whatever the tool defaulted to a year ago
built with an upload keystore you're handed, not one locked inside someone else's tool, because you need it for every future update

None of that is exotic to build correctly — it's just two checkboxes a lot of free tools skip because their business model is "generate once," not "keep apps updatable and compliant."

For reference, I do this at fixed prices: wrapping an existing website into a Play-ready Android app (signed AAB, API 36, keystore handed over) is ₹4,999, and the separate Play Console submission — store listing, content rating, Data safety form, and actually sending it for review — is ₹1,999 on top of Google's own one-time US$25 developer fee. Details: https://zoopcoder.com/services/website-to-android-app.php and https://zoopcoder.com/services/play-store-app-publishing.php

Either way — DIY, a free tool, or paying someone — check the AAB format and the API level before you assume the app is ready. Those two checks catch almost every "why was my upload rejected" surprise before it happens.

WooCommerce vs Shopify for an Indian store: what actually shows up on the bill

Preciousky — Tue, 15 Sep 2026 09:27:07 +0000

Every Shopify-vs-WooCommerce cost comparison you will find is written for a merchant in the United States. If you are selling from India, one of the biggest line items in that comparison does not exist for you and another one does not exist for them. Here is what is actually on the bill, with the numbers each company publishes.

The software itself

WooCommerce is free. Not freemium-with-a-catch — its makers state it plainly on their own pricing page:

WooCommerce is the free, open-source ecommerce platform for WordPress. Build a custom online store and only pay for the added features you use — no platform fees, no revenue share.

Their own cost breakdown lists the core platform as "Free, with no monthly subscription", hosting at "$25 – $350/month for most stores", and paid extensions at "$29 – $299/year per extension". In their comparison table the monthly platform fee line is "$0 platform fee" and the revenue-share line is "None".

Shopify is a subscription. On the India price list (shopify.com/in/pricing), the monthly/yearly rates are:

Plan	Pay monthly	Pay yearly
Basic	₹1,994/mo	₹1,499/mo
Grow	₹7,447/mo	₹5,599/mo
Advanced	₹30,164/mo	₹22,680/mo
Plus	from ₹1,75,000/mo	—

Shopify's own FAQ confirms "There are no setup fees on any of our plans." One gotcha if you go check: the page shows the yearly rate by default on the plan cards, so if you read only the big number you will quote yourself a price you are not paying unless you commit for a year.

The fee Indian sellers usually discover after the first payout

Shopify Payments — Shopify's in-house card processor, the one that makes the "no transaction fee" claim work — does not operate in India. India is not on Shopify's own list of supported countries for Shopify Payments (the list runs to about 40 countries: Australia, Austria, Belgium, … the UK and the US; India is not among them).

That has a direct consequence. Every Indian Shopify store has to take payments through a third-party gateway — Razorpay, PayU, Cashfree — and Shopify's own FAQ says:

Third-party transaction fees may apply when you use a third-party payment provider (instead of Shopify Payments). The rate depends on your plan.

So an Indian merchant pays the gateway's percentage and Shopify's third-party transaction fee on top, on every order. A merchant in a Shopify Payments country pays one of those, not two. Worth noting honestly: Shopify no longer publishes the actual third-party percentages on the India pricing page — the comparison-table row is gone and the FAQ string in the page source is an unresolved template. So plan for the fee to exist; get the current rate from Shopify before you commit, not from a blog (including this one).

The gateway, which you pay either way

Razorpay's published headline on its pricing page is 2% platform fee on domestic payments, currently with a 0%-for-the-first-90-days promotion, and 2.15% + GST specifically for credit card on UPI. This one is not a Shopify-vs-WooCommerce difference — you pay it on both. It just makes the Shopify stack a fee on a fee.

So what repeats every month?

WooCommerce: hosting + gateway percentage. That's it. No licence, no plan, no cut of sales. What you are really buying with the missing monthly fee is a maintenance obligation — somebody has to keep WordPress, the theme and the plugins patched, and if that somebody is not you, it is a bill.

Shopify: plan + gateway percentage + Shopify's third-party transaction fee. In exchange, hosting, updates and security are not your problem at all.

The crossover

The honest version is that neither is "cheaper" in the abstract — it depends entirely on your sales volume, because one cost is fixed and the other is a percentage.

Below roughly ₹13 lakh a year in online sales, Shopify tends to win: ₹1,994/month is ₹23,928 a year and the transaction percentage on small volume is small, while a maintained WooCommerce store costs roughly the same in upkeep whether you sell ₹2 lakh or ₹20 lakh. Above that, the percentage keeps climbing and the maintenance bill doesn't.

And below about ₹2 lakh a year in expected online sales, the honest answer is neither — sell on Instagram and WhatsApp with a payment link and build the store when there is volume to justify it.

Sources

WooCommerce pricing — https://woocommerce.com/pricing/
Shopify India pricing — https://www.shopify.com/in/pricing
Shopify Payments requirements / supported countries — https://help.shopify.com/en/manual/payments/shopify-payments/shopify-payments-requirements
Razorpay pricing — https://razorpay.com/pricing/

Disclosure: I write for ZoopCoder, an Indian development studio that builds on both platforms and is paid either way — though not equally, so read the recommendation with that in mind. For reference, our fixed prices are ₹19,999 for a WooCommerce store with 30 products and Razorpay, and ₹14,999 for a Shopify setup; the platform fees above are billed to you by Shopify/Razorpay, never by us. The full crossover arithmetic at four revenue levels is in our e-commerce cost guide.

Why your Google Play app gets rejected again after you fixed it — two rules from Google's own docs

Preciousky — Tue, 15 Sep 2026 09:25:59 +0000

If you have shipped an Android app, you have probably lived this: Google rejects an update, you fix exactly the thing the notice named, you resubmit, and it comes back rejected again. Same policy, same wording, no new information. Most people conclude the review is arbitrary or that a human never looked at it.

It usually isn't arbitrary. There are two rules sitting in Google's own Play Console documentation that almost nobody reads, and between them they explain most repeat rejections.

1. You are not supposed to be waiting for a reply

A lot of developers send the appeal/contact form and then sit there for a week waiting for a human to write back before touching anything. Google's own instructions on preparing an app for review say the opposite, in plain words:

If your update is rejected or your app is removed, please follow the instructions below to resubmit your app for review. You can complete these steps without contacting or waiting for a reply from the policy support team.

So the loop is: read the enforcement message, fix the cause, push the corrected release, hit Send for review on the Publishing overview page. No ticket, no reply, no queue. If you are waiting on an email you are just burning days.

2. The corrected build has to land on every track — and the bad one has to be deactivated

This is the one that causes the "I fixed it and it got rejected again" loop, and it is the single most expensive thing I see people miss.

When you resubmit after a policy violation, Google does not only look at production. From the resubmission instructions:

Make the appropriate changes to your app and update all release types in addition to your production release (for example, the open, closed, and internal test track releases).

and then, flagged as Important:

If you fail to deactivate the non-compliant app bundle(s), your attempt to resubmit your app will fail, and live versions of your app bundle(s) may be removed from Google Play.

Read that second sentence twice. Leaving the violating bundle alive on an internal test track you forgot about in March does not just risk a rejection — Google says it can take your live production app down with it.

The practical checklist is therefore:

Upload the corrected bundle to production, open, closed and internal — every track that has a release.
Deactivate the non-compliant bundles on each of those tracks. If the offending release is still a draft, discard it.
Make sure the non-compliant version shows under "Not included" in the new release.
Roll the release to 100%, then send for review.

Most people do step 1 for production only and stop.

The causes worth checking before you resubmit

In my experience the actual root cause is nearly always one of six things, and the enforcement message names the policy but not the line:

What broke	What it looks like in the notice
Data safety answers don't match the app's real behaviour	Data safety / User data policy
Privacy policy missing, 404s, or is a Google Doc that needs sign-in	User data
Sensitive permission with no approved declaration (SMS, call log, background location, all-files access)	Permissions / sensitive data
The reviewer could not get past your login screen	App access instructions
Screenshots, title or description overselling or misdescribing the app	Metadata / deceptive behaviour
Build no longer meets the current target API level	Target API level requirement

On app access specifically: if any part of the app is behind a login, you have to give working credentials in App content → App access, and you can add up to five sets of instructions. A demo account that expired two months ago reads to a reviewer exactly like a broken app.

How long the resubmission actually takes

Usually hours to a couple of days. But Google is explicit that it is not uniform:

For certain developer accounts, we'll take more time to thoroughly review your app to help better protect users. This may result in review times of up to seven days or longer in exceptional cases.

Nobody — no agency, no consultant, no "Play Store expert" on a freelance site — can shorten that queue. If someone tells you they can, that alone is the tell.

One thing that is not a rejection

If your app is sitting in closed testing and you cannot push to production, that is usually not an enforcement action at all. Personal developer accounts created after 13 November 2023 have to run a closed test with at least 12 testers opted in continuously for 14 days before they can even apply for production access. Testers who opt in, test for a few days and drop out do not count, and the 14 days have to be consecutive. It is a waiting requirement, not a violation, and there is nothing to fix.

Sources

Prepare your app for review — https://support.google.com/googleplay/android-developer/answer/9859455
My app has been removed from Google Play (resubmission + appeals) — https://support.google.com/googleplay/android-developer/answer/2477981
Publish your app (review times) — https://support.google.com/googleplay/android-developer/answer/9859751
App testing requirements for new personal developer accounts — https://support.google.com/googleplay/android-developer/answer/14151465

Disclosure: I write for ZoopCoder, an Indian development studio, and we sell a fixed-price Play Store rejection fix at ₹2,999 — diagnosis plus resubmission in 2-4 working days. Everything above is in Google's public documentation and you can do all of it yourself for free; I wrote it up because the two-track rule costs people weeks. We do not guarantee approval and nobody honestly can. If the hold-up is the 14-day tester clock rather than a rejection, this piece on how long an app actually takes to go live in India has the timeline.

What a Shopify store really costs in India in 2026 — including the fee only Indian sellers pay

Preciousky — Tue, 15 Sep 2026 05:31:16 +0000

Disclosure: I work at ZoopCoder, an Indian dev shop, and we sell a paid fixed-price Shopify setup. Every Shopify number below is Shopify's own published India price and is billed by Shopify, not by us — none of it reaches us. The one paid thing we sell is flagged clearly at the end. Verify the rates on Shopify's site before you plan around them; they move.

Every "how much does Shopify cost" article you will find is written for a merchant in the US, the UK or Australia. For an Indian seller, all of them are wrong in the same specific way, and it is not the subscription price.

Here is the actual arithmetic for India as at September 2026.

1. The subscription (Shopify's own India price list)

From shopify.com/in/pricing:

Plan	Pay monthly	Pay yearly
Basic	₹1,994/mo	₹1,499/mo
Grow	₹7,447/mo	₹5,599/mo
Advanced	₹30,164/mo	₹22,680/mo
Plus	from ₹1,75,000/mo	—

And, verbatim from the same page's FAQ: "There are no setup fees on any of our plans."

So the headline is ₹1,994 a month, or ₹17,988 a year if you commit annually. That is the number everyone quotes. It is also the number that matters least.

2. The thing that is different in India: Shopify Payments doesn't operate here

Shopify publishes a list of supported countries for Shopify Payments. As I write this it runs from Australia and Austria through to the UAE, the UK and the US — 40-odd countries.

India is not on it.

That has one direct consequence, which Shopify also states plainly in its pricing FAQ:

Third-party transaction fees may apply when you use a third-party payment provider (instead of Shopify Payments). The rate depends on your plan.

Put those two facts together and you get the India-specific outcome: every Indian Shopify store must use a third-party gateway — Razorpay, PayU, Cashfree, PhonePe — which means every Indian Shopify store pays Shopify's third-party transaction fee on every order. There is no configuration that avoids it, because the thing that would avoid it isn't available here.

A merchant in a supported country can switch that fee off by turning Shopify Payments on. You cannot. That is the asymmetry nobody's cost comparison mentions.

3. And then there's GST on the gateway fee

Second India-only line item, and an easy one to under-budget. A standard Razorpay/PayU/Cashfree account is around 2% per transaction on domestic cards — and 18% GST is charged on that fee, which makes the real rate about 2.36%.

On ₹50,00,000 of annual sales that's ₹1,18,000, not ₹1,00,000. An ₹18,000/year line that appears in exactly zero comparison tables published outside India.

One more, if you are GST-registered: Shopify bills its subscription from outside India, so the reverse charge mechanism applies — you pay the GST to the government yourself and claim it back. Net zero if you are registered, a real 18% if you are not. Ask your CA, not a blog post, about your own position.

4. So what does it actually cost to run?

Stack the three layers for a Basic-plan store:

Subscription: ₹1,994/mo (₹1,499/mo yearly)
Shopify's third-party transaction fee: a percentage of every order, unavoidable in India, rate depends on plan
Gateway + GST: ~2.36% of every order

The first number is fixed. The other two scale with your revenue — and that is the whole decision, because WooCommerce's cost structure is the opposite shape: nothing for the software, everything in hosting and maintenance labour, which stays roughly flat as sales grow.

Two lines with different slopes cross somewhere. We did that arithmetic at four revenue levels for the Indian market — including where the crossover actually sits and the case for not building a store at all below a certain volume — in what an e-commerce website costs in India.

The short version of that guide, so you don't have to click:

Under ~₹2 lakh/year in online sales: don't build a store. A WhatsApp Business catalogue and a payment link take an afternoon and cost nothing but the transaction fee.
~₹2 lakh to ~₹13 lakh/year: Shopify. The subscription plus its cut is cheaper than paying somebody in India to keep WooCommerce patched, and it is dramatically less work.
Above ~₹13 lakh/year: the lines cross and WooCommerce starts winning, because Shopify's percentage keeps climbing with your revenue and maintenance labour doesn't.

That recommendation sends most small sellers away from the larger project, which is the opposite of what an agency blog usually does. It is also just what the maths says.

5. What setup actually involves

A blank Shopify store does not sell. What it needs before it can take a rupee:

A theme customised enough not to look like a demo (free themes are fine; the licence for a paid one is yours to buy)
Products with real variants and collections, not a flat list
A gateway connected and KYC-approved — this is usually the long pole, not the design
Shipping zones, rates and COD, which in India is still a large share of orders
GST tax settings
Refund, privacy, shipping and terms pages — gateways ask for these during approval, and a missing shipping policy is a very common reason an Indian gateway application stalls
A real end-to-end test order before you announce anything

None of that is hard. All of it is fiddly, and the gateway approval step has a queue you don't control.

If you'd rather not, ZoopCoder does it as a fixed price: Shopify store setup — ₹14,999, 7-10 working days, up to 30 products, gateway connected, COD, shipping, GST, domain, policy pages and a live test order before handover. The Shopify plan stays on your own account and your own card — we work as staff on your store and that access can be removed the day we hand over.

The one-line summary

Shopify in India is ₹1,994/month plus a percentage you cannot switch off, because Shopify Payments doesn't operate here. Budget the percentage, not the subscription. Below about ₹13 lakh a year in sales, it's still the right platform for most sellers — it's just not as cheap as the international articles make it look.

Google Play's API 36 deadline has passed — what actually breaks when you upgrade

Preciousky — Tue, 15 Sep 2026 05:29:30 +0000

Disclosure: I work at ZoopCoder, an Indian dev shop, and we sell a paid fixed-price version of this upgrade. Everything below is from Google's own published documentation and is linked so you can check it. There are no fees in this post paid to us except the one clearly marked at the end — treat this as a commercially interested source and verify the dates yourself.

If you have an Android app in production and you have not shipped an update since August, there is a decent chance Play Console will refuse your next upload with this:

Your app must target Android 16 (API level 36) or higher.

That is not a bug and it is not your build tooling. It is Google Play's annual target API level requirement, and this year's step took effect on 31 August 2026.

Here is exactly what the rule says, what it blocks, how much time you have left, and — the part most posts skip — what actually breaks when you raise the number.

The rule, in Google's words

From Meet Google Play's target API level requirement:

Starting August 31 2026: New apps and app updates must target Android 16 (API level 36) or higher to be submitted to Google Play; except for Wear OS and Android Automotive OS apps, which must target Android 15 (API level 35) or higher, and Android TV and Android XR apps, which must target Android 14 (API level 34) or higher.

So:

Form factor	Minimum target API level
Phones / tablets / foldables	36 (Android 16)
Wear OS	35 (Android 15)
Android Automotive OS	35 (Android 15)
Android TV	34 (Android 14)
Android XR	34 (Android 14)

Two things people get wrong about this:

It applies to updates, not just new apps. A five-year-old app with a million installs cannot ship a one-line crash fix until its targetSdk goes to 36. The block is on the upload itself, in Play Console, before review.
There is a second, softer rule for apps you never touch again. Existing apps must target API 35 or higher "to remain available to new users on devices running Android OS higher than your app's target API level." An app left on API 34 doesn't vanish — it just quietly stops being installable by new users on current phones, which looks identical to your install rate dying for no reason.

The documented exception is narrow: "permanently private apps that are restricted to users in a specific organization and intended for internal distribution only."

You can buy time, once, until 1 November 2026

Also straight from that page:

If you need more time to update your app, you'll be able to request an extension to November 1, 2026. You'll be able to access your app's extension forms in Play Console later this year.

That is the whole reprieve. It is a one-off form inside Play Console, it moves your date to 1 November 2026, and it does not renew. If you are reading this and you're blocked, filing that is the first thing to do — then do the work, because the extension is not a plan.

What actually breaks (this is the real work)

Bumping targetSdk from 35 to 36 is one line. Everything after that line is the job. Four changes catch almost everybody, all documented in Behavior changes: Apps targeting Android 16:

1. The edge-to-edge opt-out is gone

Android 15 enforced edge-to-edge for apps targeting API 35, but you could escape with R.attr#windowOptOutEdgeToEdgeEnforcement = true. For apps targeting API 36, that attribute is deprecated and disabled on Android 16 devices — you cannot opt out any more.

Practical effect: your content now draws under the status bar and the navigation bar. Buttons end up under the gesture pill; headers end up under the clock. Nothing crashes, so CI stays green and the bug arrives via a screenshot from a user.

The fix is to apply window insets properly (Compose / Views) rather than to hunt for a new opt-out flag. There isn't one.

2. Predictive back is on by default — and `onBackPressed` is never called

This is the nastiest one, and it is the reason I am writing this post:

For apps targeting Android 16 (API level 36) or higher and running on an Android 16 or higher device, the predictive back system animations (back-to-home, cross-task, and cross-activity) are enabled by default. Additionally, onBackPressed is not called and KeyEvent.KEYCODE_BACK is not dispatched anymore.

If your app intercepts the back key at all, that interception silently stops running. The single most common casualty is the WebView wrapper pattern — the classic

@Override
public void onBackPressed() {
    if (webView.canGoBack()) webView.goBack();
    else super.onBackPressed();
}

— which is in a very large share of India's small-business apps. After the upgrade, back exits the app instead of going back a page, and it does so from the first screen the user ever presses back on.

Two options: migrate to the supported back navigation APIs, or set android:enableOnBackInvokedCallback="false" on <application> or the specific <activity> as a temporary opt-out while you migrate. Google's own wording for that flag is "temporarily opt out", and it is worth treating that word as load-bearing.

3. Orientation and aspect-ratio locks stop being honoured on big screens

For apps targeting Android 16 (API level 36), orientation, resizability, and aspect ratio restrictions no longer apply on displays with smallest width >= 600dp. Apps fill the entire display window, regardless of aspect ratio or a user's preferred orientation, and pillarboxing isn't used.

If you shipped screenOrientation="portrait" and assumed it would hold, it won't on a tablet, a foldable's inner screen, or desktop windowing. There is a per-activity manifest opt-out (PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY) and an application-level one, but the direction of travel is obvious and the escape hatches are explicitly transitional.

4. `elegantTextHeight` is deprecated and ignored — and this one is an India problem

Android 16 deprecates the elegantTextHeight attribute, and the attribute will be ignored once your app targets Android 16. The "UI fonts" controlled by these APIs are being discontinued, so you should adapt any layouts to ensure consistent and future proof text rendering in Arabic, Lao, Myanmar, Tamil, Gujarati, Kannada, Malayalam, Odia, Telugu or Thai.

Six of those ten scripts are Indian. If your app ships Tamil, Telugu, Kannada, Malayalam, Odia or Gujarati strings, your line heights move and tightly-packed layouts clip. Nobody in your QA group is going to catch that unless somebody is explicitly told to look at the regional-language build.

While you are in there: the 16 KB page size deadline

Different rule, same neighbourhood, and worth doing in the same sitting. From Support 16 KB page sizes:

To ensure your app works correctly on the latest versions of Android, all apps targeting Android 15 (API level 35) and higher must support 16 KB memory page sizes on 64-bit devices on Google Play. Starting February 1, 2027, if your app updates don't support 16 KB memory page sizes, you won't be able to release these updates.

The good news, also from that page:

If your app only uses code written in the Java programming language or in Kotlin, including all libraries or SDKs, then your app already supports 16 KB devices.

So this only bites if you (or a dependency — think older video, ML, crypto, PDF or game SDKs) ship native .so files. Check your AAB's lib/arm64-v8a/ contents before you assume you're clear, because "a library I depend on has NDK code" is a much more common answer than "I wrote NDK code".

What this costs

Honest version: if it's a healthy modern project with maintained dependencies, this is a half-day for someone who has done it before, and you should just do it yourself using the links above. Nothing in this post is secret.

It gets expensive when the project is old: an unmaintained Gradle plugin, an AGP version that won't compile against API 36, a dependency that was abandoned three years ago, a Cordova shell. Then you are not doing a one-line bump, you are doing an archaeology project.

If you'd rather hand it over, ZoopCoder does this as a fixed-price job: target API 36 upgrade — ₹2,999, 2-4 working days, which covers the tooling update, the four behaviour changes above, a 16 KB check on native libraries, and a signed AAB. We quote separately (and say so up front) if the project turns out to need a rewrite rather than an upgrade — that is the honest failure mode of a fixed price on legacy code.

The wider point, which is worth more than the service: an Android app is not a thing you finish. Google and Apple move their requirements on their own calendar, not yours, and an app nobody touches for two years eventually fails a store requirement without anything about it having "broken". We put a yearly number on that in what website and app maintenance actually costs in India.

Do the extension form today if you're blocked. Then do the upgrade before 1 November.

WhatsApp Business Platform pricing in rupees — and the two things that change on 1 October 2026

Preciousky — Mon, 14 Sep 2026 22:31:50 +0000

Disclosure: I work on ZoopCoder, a small Indian dev shop that builds WhatsApp chatbots as a paid service. Every per-message rate below is Meta's, taken from Meta's own published rate card, and is billed by Meta directly to your WhatsApp Business account — none of it reaches us. The one paid thing we sell is at the end, clearly marked.

WhatsApp Business Platform pricing has changed twice in eighteen months and is about to change again in two weeks. Most of the "WhatsApp API pricing India" pages you will find are still describing the 2023 model. Here are the current numbers in rupees, straight off Meta's rate card, plus what actually lands on 1 October 2026.

Source for everything below: Meta's pricing documentation, last updated 10 September 2026, and the INR rate card CSV linked from it.

The model, in one paragraph

Until mid-2025 Meta charged per 24-hour conversation. Since 1 July 2025 it charges per template message delivered instead. You are charged when a template message is delivered; the rate depends on the template's category (marketing, utility, authentication) and the country calling code of the person receiving it. Free-form, non-template messages — the ordinary replies a bot or a human sends inside an open 24-hour customer service window — have not been charged since 1 November 2024.

That last sentence is the one with an expiry date on it. More below.

India rates today (effective 1 July 2026)

Per message delivered, in rupees, to an Indian (+91) number:

Template category	Rate per message	What it is
Marketing	₹0.8631	Promotions, offers, re-engagement, cart nudges
Utility	₹0.1150	Order confirmations, shipping updates, payment receipts
Authentication	₹0.1150	OTPs and login codes
Authentication-international	₹2.4971	Auth messages billed under the international rate
Service (free-form reply in an open 24h window)	not charged	…until 30 September 2026. See below

Two things jump out. Marketing is 7.5× the price of utility in India, and utility is so cheap — about eleven and a half paise — that order updates are effectively a rounding error. A store sending 2,000 shipping updates a month spends ₹230. A store blasting 5,000 marketing templates a month spends ₹4,315. Same channel, wildly different economics, and the difference is entirely which category your template is approved under.

What changes on 1 October 2026

Two changes, both of which make free things cost money.

1. Service messages start being charged. Those free-form replies inside an open 24-hour customer service window — everything a chatbot says back to a customer who messaged first — become chargeable at the same rate as utility and authentication in your market. In India that is ₹0.1150 per message.

There is a free tier, and it is per phone number, not per business: 1,000 service messages per business phone number per month, free. Meta only charges from the 1,001st service message delivered in a month. The allowance does not roll over — 1,000 in October, 1,000 in November, unused ones vanish. And note Meta's own warning: if you have no payment method on the account, your first 1,000 service messages each month still go out, but the 1,001st is simply not delivered. Add a payment method in Billing Hub before October if your volume is anywhere near the line.

2. Utility templates sent in reply to a user become chargeable again. Since 1 July 2025, a utility template delivered inside an open customer service window was free. From 1 October 2026 it is not.

India is not in Meta's list of markets whose marketing, utility or authentication rates change on 1 October 2026, so the ₹0.8631 / ₹0.1150 figures above should hold through the switchover. The new cost is the newly-chargeable categories, not a rate rise.

What that does to a real bill

Take a small Indian D2C store running a bot on one number. 2,000 people message in each month; the bot answers each with roughly three messages; the store also sends 2,000 shipping updates and one marketing blast to 5,000 opted-in contacts.

Line	Volume	Until 30 Sep 2026	From 1 Oct 2026
Bot replies (service messages)	6,000	₹0	(6,000 − 1,000 free) × ₹0.1150 = ₹575
Shipping updates (utility templates)	2,000	₹230	₹230
Marketing blast	5,000	₹4,315	₹4,315
Monthly total		₹4,545	₹5,120

So the October change costs this business ₹575 a month. Not existential — but it is the difference between "replies are free" and "replies are metered", and if you are running a high-volume support bot on one number, 50,000 service messages a month goes from ₹0 to about ₹5,635.

Three ways to keep the bill down

Let the customer start the conversation. A click-to-chat link, a WhatsApp button on your site, a QR code on the packaging. Replying inside an open window is ₹0.1150 a message and the first 1,000 are free; reaching out cold with a marketing template is ₹0.8631 every time.
Get the template category right. An order confirmation approved as marketing instead of utility costs you 7.5× for no reason. Write templates so they are unambiguously transactional, and challenge a miscategorisation rather than shrugging at it.
Watch the 1,000-message line per number. The free tier is per business phone number. If you genuinely run separate support and sales functions, separate numbers each get their own 1,000 — but do not split numbers purely to farm the allowance; you will pay for it in verification hassle and split chat history.

One thing worth saying about unofficial tools

There is a whole market of cheap "WhatsApp automation" tools that drive the consumer app rather than the Business Platform. They are cheaper because they are against WhatsApp's terms, and the failure mode is your business number getting banned with the chat history inside it. If WhatsApp is a real sales channel for you, the official API's per-message rupees-and-paise pricing is not the expensive option.

The paid option, stated plainly

ZoopCoder builds a chatbot on the official WhatsApp Business Platform — menus, up to 25 FAQ replies, lead capture into a Google Sheet, human handoff, up to 3 templates submitted for Meta approval — for a fixed ₹7,999, live in 7–10 working days, no monthly fee from us. It is here with the full scope. Meta's per-message charges above are yours and go to Meta; we do not mark them up and we do not resell them.

If you are costing a whole storefront rather than just the bot, the rest of the recurring lines are itemised in our e-commerce website cost guide for India.

Rates change quarterly. If you are reading this months from now, check Meta's rate card before quoting these numbers to anyone.

What it actually costs to publish an iPhone app on the App Store from India (2026 numbers)

Preciousky — Mon, 14 Sep 2026 22:30:51 +0000

Disclosure: I work on ZoopCoder, a small Indian dev shop that sells App Store submission as a paid fixed-price service. Every fee in this post is money paid to Apple, not to us, and I have linked Apple's own page for each one so you can check it. The single paid thing we sell is flagged at the very end — the rest of the post works fine if you ignore it.

Every few weeks someone asks me the same question in a slightly different form: "how much does it cost to put an app on the App Store?" The answers online are either American, or a year out of date, or quietly skip the part that actually costs money. So here are the 2026 numbers, in rupees, with sources.

1. The fee: US$99 a year, and the word year is the whole story

The Apple Developer Program is 99 USD per membership year, "in local currency where available" — so Apple bills you in rupees during enrolment. At ₹95.61 to the dollar (14 September 2026) that is about ₹9,500 a year.

Compare that to Google:

Store	What you pay	How often
Google Play	US$25 (about ₹2,400)	Once. Ever. One account, every app you ever ship
Apple App Store	US$99 (about ₹9,500)	Every year, for as long as you want the apps listed

That difference compounds. Three years on Google Play costs US$25. Three years on the App Store costs US$297.

And Apple's fee does not lapse quietly. When the membership expires, your apps are removed from the App Store. People who already installed the app keep their copy, but nobody new can download it and you cannot ship an update until you renew. If you are a solo dev with one free app and no revenue, budget that ₹9,500 as a permanent line, not a launch cost.

(Accredited educational institutions, government entities and qualifying non-profits can apply to Apple for a fee waiver. Most people reading this will not qualify.)

2. Individual or organization? Decide before you pay, not after

This one costs people days, and it is free to get right.

Individual enrolment needs your Apple Account with two-factor on, and a card. That is it. But your own legal name is shown as the seller on the App Store listing. For a personal project, fine. For anything you want to look like a company, not fine.

Organization enrolment shows your company name as the seller instead, and Apple requires rather more:

a D-U-N-S Number for the legal entity (free from Dun & Bradstreet, but requesting one takes days);
a legal entity that can contract with Apple — Apple explicitly does not accept DBAs, trade names or branches;
a work email on your organization's own domain — a Gmail address will not do;
a publicly working company website on that same domain. A domain-registrar parking page or a link to your Instagram gets rejected;
and the person enrolling must actually have authority to bind the company.

If you are an Indian private limited or LLP and do not yet have a D-U-N-S number, start that request first and do everything else while it processes. Switching from individual to organization later is a support ticket, not a checkbox.

3. Review takes a day. Rework takes a fortnight.

Apple's own number on the App Review page: "On average, 90% of submissions are reviewed in less than 24 hours."

That is genuinely fast — faster than Google Play's typical turnaround right now. The reason iOS launches feel slow is the other Apple statistic on that same page:

"On average, over 40% of unresolved issues are related to guideline 2.1: App Completeness"

Guideline 2.1 is not a design judgement or a policy grey area. It is the boring stuff:

the app crashed on the reviewer's device;
placeholder content — lorem ipsum, a stock avatar, an empty tab — still in the build you submitted;
incomplete information: no demo account, so the reviewer hit your login screen and could not get past it;
broken links (a privacy policy URL that 404s will do it);
a screenshot showing an Android device, or UI that is not in the build.

Every one of those is checkable in twenty minutes before you submit. Each one you miss costs a full review cycle, and cycles are where the two weeks go.

The demo account is the single highest-value thing you can add. If your app has any sign-in at all, put a working username and password in the App Review notes, make sure the account has realistic data in it, and keep it alive until the app is approved. Reviewers do not sign up.

4. Guideline 4.2, and why website wrappers die on iOS

If your plan is "wrap our website in a WebView and ship it", read guideline 4.2 first. Apple says it plainly:

"Websites served in an iOS app, web content that is not formatted for iOS, and limited web interactions do not make a quality app."

Android will usually take that app. iOS will usually not. If you want the same web content on the App Store, it needs real native behaviour on top — push notifications, offline handling, native navigation, device features that a browser tab cannot offer. Plan that as build work, not as a conversion step.

5. The whole first-year bill, in rupees

For an Indian founder shipping one iPhone app, with a build that already exists:

What	Who charges it	Amount	How often
Apple Developer Program	Apple	US$99 (~₹9,500)	Every year
D-U-N-S number (org accounts)	Dun & Bradstreet	₹0	Once
Apple commission on in-app sales	Apple	15% under US$1M/yr revenue	Per sale
App Store submission, if you do it yourself	—	₹0 and a day or two of your time	Per app

Year one: about ₹9,500 plus your time. Year two onwards: about ₹9,500. There is no per-app charge and no submission fee — the recurring membership is the entire Apple bill until you start selling inside the app.

FX used throughout: ₹95.61 to the US dollar, 14 September 2026. Apple charges the rupee price shown at enrolment, which will not track the spot rate exactly.

6. When it is not worth it

Be honest with yourself about the ₹9,500 a year. If you are shipping a free app with no revenue model, no update plan and no users waiting for it, an iOS build is a subscription you will resent in month fourteen. Ship Android first — US$25, once, forever — see whether anyone wants the thing, and buy the Apple membership when there is a reason to.

7. The paid option, stated plainly

If you would rather not learn App Store Connect: ZoopCoder does the whole submission — app record, listing, App Privacy labels, age rating, export compliance, build upload, review notes and demo login — for a fixed ₹4,999, sent to Apple review in 2–3 working days. That is the service page, price and scope on it. The ₹4,999 is on top of Apple's US$99, not instead of it, and nobody outside Apple can promise you approval — treat anyone who does as a red flag.

If you are still costing the build itself, we keep an itemised breakdown at mobile app development cost in India, including the yearly fees both stores charge.

Corrections welcome — if Apple changes a number, tell me and I will fix the post.

What it actually costs to publish an Android app on Google Play from India (2026 numbers)

Preciousky — Mon, 14 Sep 2026 20:01:32 +0000

Disclosure: I work at ZoopCoder, an Indian development shop that sells a paid Play Store submission service. That price is at the bottom. Everything above it is the same thing I would tell you for free, and every fee in this post is paid to Google or Apple, not to us.

Someone asks "how much does it cost to publish an app on the Play Store" roughly every day. They get told "$25", they pay the $25, and then three weeks later they are still not live because of a rule nobody mentioned. Here are the real numbers as of September 2026, from doing this repeatedly for Indian clients.

1. The fee is US$25, once, and that is genuinely all of it

A Google Play developer account costs a one-time US$25 registration fee — about ₹2,400 on an Indian card at today's rate, plus whatever forex markup your bank adds. There is:

no annual renewal — you pay once and the account is yours;
no per-app charge — one account can hold as many apps as you want;
no charge to push updates.

This is the single biggest difference from Apple, which charges US$99 every year and delists your app if you stop paying. If you are choosing which platform to ship first on a tight budget, that asymmetry matters more than any development cost.

The one thing Google does take is a service fee of 15–30% on in-app purchases and subscriptions — 15% on the first US$1M of yearly earnings for most developers. If your app takes money for physical goods or services delivered outside the app, that fee does not apply.

2. The cost that is not money: the 14-day, 12-tester clock

This is the one that ruins launch dates.

If your developer account was registered as a personal account after 13 November 2023, Google will not give you production access until you have run a closed test with at least 12 testers who stay opted in continuously for 14 days.

Read that carefully, because each clause bites:

12 testers — real Google accounts that actually opt in. Not 12 email addresses you own.
14 continuous days — the clock starts when the test starts, not when you apply.
If testers drop below the threshold, the clock effectively restarts.

Organisation accounts (a registered company, D-U-N-S verified) are exempt from this entirely. If you are a registered company and you have a choice, register the developer account as the organisation on day one, not at the end of the project. It is free and it saves you two to three weeks.

Nobody can shorten this for you. Any service that offers to "provide testers" is offering you a policy violation — Google treats fake tester accounts as exactly that.

3. You cannot upload an APK, and you cannot target an old SDK

Two hard technical gates that catch people using app builders and free converters:

Requirement	Since	What it means
Android App Bundle (.aab)	August 2021 for new apps	A plain `.apk` will be rejected at upload.
Target API 36 (Android 16)	Current Play requirement	Building against an older `targetSdk` blocks the upload, not just new features.

If you exported your app from a free "website to app" tool, check both of these before you pay for anything else. A large share of those tools still emit an APK built against an older target API, and some do not let you supply your own signing key — which means you could never publish an update under your own account even if the first upload succeeded.

4. The five declarations that actually cause first rejections

The upload is the easy part. First submissions get bounced on paperwork far more often than on code:

Data safety form that does not match reality. You declare what the app collects and shares. If your app pulls the advertising ID or device identifiers through an SDK you forgot about, and the form says it collects nothing, that is a mismatch and a rejection.
Missing or unreachable privacy policy URL. It must be a live, public URL, on your own domain, reachable without a login.
Wrong target-audience answer. Answering "children" pulls in a whole extra set of Families policy requirements. Answering it carelessly is a policy problem, not a form problem.
App access credentials the reviewer cannot use. If any part of the app is behind a login, you must give a working demo account. Expired or 2FA-protected demo logins are a very common bounce.
Content rating questionnaire (IARC) answered inconsistently with what the app actually does.

None of these need a developer to fix. All of them need someone to actually read the app's behaviour instead of clicking through the form.

5. A realistic end-to-end budget (Indian solo founder, app already built)

Line item	Cost	Paid to	Frequency
Google Play developer account	US$25 (≈ ₹2,400)	Google	Once, forever
Privacy policy page	₹0 if you write it yourself	—	Once
Store listing copy + screenshots	₹0–₹5,000	Designer, or yourself	Once
Console submission work	₹0 if you do it yourself	—	Per app
Apple, if you also want iOS	US$99 (≈ ₹9,500)	Apple	Every year

So: an Android-only launch for an app that already exists can genuinely cost you one payment of about ₹2,400 and a fortnight of waiting. That is the honest answer, and it is why I think "how much does it cost to publish an app" is usually the wrong question — the expensive parts are the app and the fourteen days, not the fee.

6. Where we fit, since I said I'd be upfront

If you would rather not spend an evening inside Play Console:

ZoopCoder submits an app to Google Play for a fixed ₹1,999 — store listing, IARC content rating, Data safety form, target audience, app access declarations, the release itself, and the first round of Google's review feedback. Typically sent for review within 1–2 working days of getting the files. Details and scope: https://zoopcoder.com/services/play-store-app-publishing.php
If what you are publishing is an existing website, we build it into a signed, Play-ready AAB targeting API 36 for a fixed ₹4,999: https://zoopcoder.com/services/website-to-android-app.php

The US$25 is still yours to pay to Google, the app is published under your account, and nobody — us included — can guarantee that Google approves it. Anyone who tells you otherwise is selling you something they do not control.

If the part you are actually worried about is the calendar rather than the console, we wrote up where the tester window fits into a real Android launch plan here: https://zoopcoder.com/guides/how-long-to-build-app-website-india.php

Numbers checked September 2026. If Google has changed a threshold since, the Play Console policy pages win over this post — tell me in the comments and I will correct it.

DEV Community: Preciousky

Google's Play Billing v8 deadline and Apple's 7-day subscription rule — two IAP gotchas costing real rejections

Android: Google now requires Play Billing Library v8 for every update

iOS: subscriptions have a 7-day floor, and purchased credits can never expire

Cloudflare's "Flexible" SSL trap, and the real DNS wait time for a hosting migration

The Cloudflare redirect loop nobody expects

How fast does a DNS change actually happen?

PWA cost in India, and the Play Store ASO myth that wastes founders' money

1. What does it actually cost to turn a website into an installable PWA?

2. The Play Store ASO myth that wastes money: stuffing keywords into your listing does not help

Google Play vs Apple Developer Accounts in India: Real Costs, the D-U-N-S Trap, and When You Can't Choose Personal

What each one actually costs

The account-type trap nobody mentions

The D-U-N-S number timeline that blows up launch dates

What breaks accounts after they are already live

Quick reference

Website to Android App in 2026: Two Play Store Rules That Silently Reject Free Converter Output

Rule 1: Play has not accepted a plain APK for a new app since August 2021

Rule 2: every app must target API level 36 (Android 16) — enforced from 31 August 2026

What this means practically

WooCommerce vs Shopify for an Indian store: what actually shows up on the bill

The software itself

The fee Indian sellers usually discover after the first payout

The gateway, which you pay either way

So what repeats every month?

The crossover

Sources

Why your Google Play app gets rejected again after you fixed it — two rules from Google's own docs

1. You are not supposed to be waiting for a reply

2. The corrected build has to land on every track — and the bad one has to be deactivated

The causes worth checking before you resubmit

How long the resubmission actually takes

One thing that is not a rejection

Sources

What a Shopify store really costs in India in 2026 — including the fee only Indian sellers pay

1. The subscription (Shopify's own India price list)

2. The thing that is different in India: Shopify Payments doesn't operate here

3. And then there's GST on the gateway fee

4. So what does it actually cost to run?

5. What setup actually involves

The one-line summary

Google Play's API 36 deadline has passed — what actually breaks when you upgrade

The rule, in Google's words

You can buy time, once, until 1 November 2026

What actually breaks (this is the real work)

1. The edge-to-edge opt-out is gone

2. Predictive back is on by default — and onBackPressed is never called

3. Orientation and aspect-ratio locks stop being honoured on big screens

4. elegantTextHeight is deprecated and ignored — and this one is an India problem

While you are in there: the 16 KB page size deadline

What this costs

WhatsApp Business Platform pricing in rupees — and the two things that change on 1 October 2026

The model, in one paragraph

India rates today (effective 1 July 2026)

What changes on 1 October 2026

What that does to a real bill

Three ways to keep the bill down

One thing worth saying about unofficial tools

The paid option, stated plainly

What it actually costs to publish an iPhone app on the App Store from India (2026 numbers)

1. The fee: US$99 a year, and the word year is the whole story

2. Individual or organization? Decide before you pay, not after

3. Review takes a day. Rework takes a fortnight.

4. Guideline 4.2, and why website wrappers die on iOS

5. The whole first-year bill, in rupees

6. When it is not worth it

7. The paid option, stated plainly

What it actually costs to publish an Android app on Google Play from India (2026 numbers)

1. The fee is US$25, once, and that is genuinely all of it

2. The cost that is not money: the 14-day, 12-tester clock

3. You cannot upload an APK, and you cannot target an old SDK

4. The five declarations that actually cause first rejections

5. A realistic end-to-end budget (Indian solo founder, app already built)

6. Where we fit, since I said I'd be upfront

2. Predictive back is on by default — and `onBackPressed` is never called

4. `elegantTextHeight` is deprecated and ignored — and this one is an India problem