This guide walks through what each account actually requires, how long each one takes to get approved, and how to decide which to start first based on your budget, business structure, and launch timeline.

Quick Answer

Start whichever account has the longer approval wait — usually the Apple Developer Program if you’re enrolling as an organization, since it requires a D-U-N-S number and manual review that can take anywhere from a few days to a few weeks. Google Play Console approval is typically faster (often within a couple of business days) once identity verification clears, but its $25 fee and the new personal-account testing rule mean solo developers should also start early rather than at the last minute.

What Each Account Actually Requires

Apple Developer Program costs $99 per year (Enterprise Program is $299/year for internal-only distribution) and requires an Apple ID with two-factor authentication. If you’re enrolling as an individual/sole proprietor, you just need your legal name and a matching payment method. If you’re enrolling as an organization, Apple requires a legal entity, a website, a D-U-N-S number that matches your business’s legal name in the D&B database, and someone with legal authority to accept Apple’s agreements. Getting a D-U-N-S number is free and usually takes a few business days, but can stretch closer to 30 days without expedited processing — and Apple’s own review after that can take anywhere from a few days to a few weeks, especially for organizations.

Google Play Console has a one-time $25 registration fee (no annual renewal) but now requires identity verification for every new developer — a government-issued ID (and sometimes a selfie) for individuals, or a D-U-N-S number for organization accounts. Verification typically completes within a few hours to about two business days. The bigger catch: any personal (non-organization) developer account created after November 13, 2023 must run a closed test with at least 12 opted-in testers for 14 consecutive days before Google will grant production access — so even though registration is quick, reaching a live listing isn’t instant either.

How to Decide Which to Set Up First

Base the decision on which process has more unknowns for your situation, not which store you personally prefer. If you’re enrolling Apple as an organization, start there first — the D-U-N-S lookup and Apple’s manual review are the least predictable steps in either process, and starting early gives you buffer room while you build the app itself.

If you’re a solo developer without a registered business, Apple’s individual enrollment is usually the faster of the two to get approved, but Google’s 12-tester, 14-day closed testing requirement means you should open your Play Console account and start recruiting testers as early as possible, since that clock only starts once your app is in testing — not once you register.

If cost timing matters (say, you want to delay spending until you’re closer to launch), Google’s one-time $25 fee is easier to front early since it doesn’t recur, while Apple’s $99 is an annual cost you may not want to start until you’re closer to submission.

If you’re only launching on one platform initially, this whole question is moot — just start that platform’s account as soon as you’re seriously working on the app, since both processes can run in parallel with development.

Tips / Common Mistakes

Don’t wait until your app is finished to start either account — identity verification and D-U-N-S lookups can stall on mismatched business names, expired IDs, or unverifiable addresses, and you don’t want that discovered the week you planned to launch.

Make sure your legal business name matches exactly across your D-U-N-S registration, your Apple enrollment, and your Google organization account — small mismatches (abbreviations, punctuation, “LLC” vs “L.L.C.”) are a common cause of rejected or delayed verification.

If you’re a solo developer on Google Play, start lining up your 12 testers before you’re ready to submit — friends, beta communities, or testing services can fill this, but the 14-day clock doesn’t start until testers are actually opted in.

Keep your payment method valid for both — Apple can suspend renewal if the annual charge fails, and Google’s registration fee won’t be refunded if identity verification later fails, so double-check your ID documents match your account details before paying.

Explore more: More App Development guides.

Apple Developer Account vs Google Play Console FAQs

Can I set up both accounts at the same time?

Yes, there’s no rule against running both enrollments in parallel. Many developers do this specifically because Apple’s organization review can take longer, so starting both at once minimizes total wait time before you can submit to either store.

Is Google Play Console really cheaper than Apple Developer Program?

Yes — Google Play Console is a one-time $25 fee with no renewal, while Apple Developer Program is $99 every year you want your app to stay live. Over multiple years, Apple is the more expensive of the two.

Do I need a D-U-N-S number for both platforms?

Only if you’re enrolling as an organization on either platform. Individual/personal accounts on both Apple and Google skip the D-U-N-S requirement, though Google still requires personal ID verification either way.

How long should I budget before my planned launch date?

For an organization account on either platform, budget at least 3-4 weeks to account for D-U-N-S processing and manual review delays. For individual accounts, a week or two is usually enough, but add 14+ days if you’re a solo Android developer who needs to clear Google’s closed testing requirement.

Build It With GTStudios

Need help with your website, app, or small-business tech? GTStudios builds web, apps, and software for small businesses. See how GTStudios can help.

Want dev news in your inbox? Subscribe to the free newsletter.

Photo by Fotis Fotopoulos on Unsplash.

The post Apple Developer Account vs Google Play Console: Set Up First? appeared first on GTStudios.

This guide walks through the practical differences between building on iOS and Android first, gives you a simple framework for deciding, and flags the mistakes that slow teams down when they rush the decision.

Quick Answer

Build for iOS first if your customers are consumers or professionals in the US, Western Europe, or other markets where iPhone usage is high, or if you’re selling a premium/paid product. Build for Android first if you need to reach the broadest possible global audience, are targeting price-sensitive or emerging markets, or want the lowest cost of entry. If your app is internal-only (used by your own employees), the decision often comes down to what devices your company already issues.

The Practical Differences That Actually Matter

Developer account cost and setup: Apple’s Developer Program is $99/year and requires enrolling with an Apple ID plus (for most business apps) a D-U-N-S number if you register as an organization. Google Play’s developer account is a one-time $25 fee with no annual renewal. Cost alone rarely decides the platform, but it affects how fast you can get moving.

Review and launch timelines: Apple’s App Store review is typically fast once you’re set up — often a day or two per cycle — but budget extra time for a first submission and for any rejections that trigger another review cycle. Google Play has a different bottleneck: as of 2026, personal (non-business) developer accounts created after November 2023 must run a closed test with at least 12 opted-in testers for 14 consecutive days before they can apply for production access. Verified organization accounts (registered under a real business entity) are exempt from this closed-testing requirement, which is a meaningful advantage if you’re launching as a company rather than an individual.

Device and OS fragmentation: iOS apps only need to support Apple’s own hardware and a small number of active iOS versions, which keeps QA scope tighter. Android apps run across a much wider range of manufacturers, screen sizes, and OS versions, so testing and support tend to take more planning on that side.

Development environment: Building and submitting an iOS app requires a Mac and Xcode. Android development with Android Studio runs on Windows, macOS, or Linux, which can matter if your team isn’t already on Apple hardware.

Monetization and payments: Both platforms take a cut of in-app digital purchases (Apple’s standard commission is 30%, dropping to 15% for qualifying small businesses and subscriptions; Google offers comparable reduced rates for smaller developers). If your business app doesn’t sell digital goods through the app itself — e.g., it’s a services, logistics, or internal tool — this consideration mostly disappears.

How to Decide Which Platform to Build First

Start with your actual users, not assumptions. If you already have a website, check your analytics for the mobile OS split among your current customers — that’s a far better signal than any general industry pattern. B2B and enterprise audiences frequently skew toward iPhone in North America; global consumer or budget-conscious audiences often skew Android.

Match the platform to your goal. If the app supports a premium or subscription product, iOS users have a stronger track record of paying for apps and subscriptions. If the goal is maximum reach with minimal friction (think logistics, field service, or emerging-market retail), Android’s broader device reach and lower cost of entry usually wins.

Factor in your timeline and team. If you need to launch fast and you’re registering as a verified business, Android’s exemption from the 14-day closed-testing rule can shave real time off your schedule. If your team already has Mac hardware and iOS experience, that head start matters too.

Consider cross-platform frameworks as a middle path. Tools like Flutter and React Native let you ship to both iOS and Android from a largely shared codebase. They’re a reasonable option if you genuinely need both platforms close to launch, though a platform-native app still tends to give you the tightest performance and the fastest access to new OS features.

Tips and Common Mistakes

Don’t try to launch on both platforms simultaneously with a small team just because you can — it usually means shipping two mediocre apps instead of one solid one. Pick a primary platform, launch it well, and expand once you have real usage data.

Don’t register your Google Play developer account as a personal account if you’re launching as a company — verifying as an organization from the start avoids the 12-tester, 14-day closed testing requirement later.

Don’t underestimate Android QA scope. Budget real testing time across a handful of representative device tiers (not just your own phone) rather than assuming one build behaves the same everywhere.

Don’t skip beta testing on either platform. Apple’s TestFlight and Google Play’s closed testing tracks both let you catch bugs and gather feedback before a public release — use them even if you’re not required to.

Don’t wait until submission day to read the current App Store Review Guidelines or Play Console policies. Both platforms update their rules regularly, and a policy violation you didn’t know about is the most common reason for review delays.

Explore more: More app development guides.

iOS vs Android for business apps FAQs

Can I build for the other platform later?

Yes — most teams launch on one platform first, validate the app with real users, then build the second version once they have budget and usage data to justify it. Using a shared design system and API backend from the start makes the second build faster.

Do I need a Mac to build an iOS app?

Yes, Xcode (Apple’s development tool) only runs on macOS, and it’s required to build and submit iOS apps. Android development with Android Studio works on Windows, macOS, or Linux.

Should I just use Flutter or React Native to build both at once?

It’s a valid option if you need both platforms close together and want to share most of the codebase. The tradeoff is usually slightly more work to fine-tune performance and platform-specific UI polish compared to a fully native app.

Which platform is cheaper to launch on first?

Google Play has a lower upfront cost — a one-time $25 developer fee versus Apple’s $99/year — but if you register as a personal (non-business) Play developer, the mandatory 14-day closed testing period can add time to your launch. Verified business accounts on Google Play skip that requirement.

Build It With GTStudios

Need help with your website, app, or small-business tech? GTStudios builds web, apps, and software for small businesses. See how GTStudios can help.

Photo: Pooja dhamo / CC BY 4.0, via Wikimedia Commons.

The post iOS vs Android: Which Should You Build First? appeared first on GTStudios.

This checklist covers the eight things most likely to trip you up before you hit submit, for both the iOS App Store and Google Play. Work through each item once and you’ll avoid the days of back-and-forth that first-time submitters often run into.

Quick Answer

Before submitting a Flutter app, verify your pubspec.yaml version numbers, code signing setup, build format (AAB for Android, IPA for iOS), target SDK levels, permissions, privacy policy URL, store assets, and that you’ve tested a release build on a real device — not just in debug mode.

The 8-Item Flutter Submission Checklist

1. Version numbers in pubspec.yaml. Your version follows the format version: 1.0.0+1, where the number before the plus sign is the user-visible version name and the integer after it is the build number. Both stores require the build number to increment with every upload — submitting the same build number twice will cause an immediate rejection. Start new projects at 1.0.0+1 and never reuse a build number.

2. Code signing is configured correctly. On iOS, you need a valid Distribution Certificate and an App Store Provisioning Profile generated in Apple’s Certificates, Identifiers & Profiles portal. After April 28, 2026, Apple requires all submissions to be built with Xcode 26 or later. Open ios/Runner.xcworkspace, set the build target to Any iOS Device (not a simulator), and confirm signing under Product > Archive before running flutter build ipa –release. On Android, generate your upload keystore with keytool -genkey -v -keystore ~/upload-keystore.jks -keyalg RSA -keysize 2048 -validity 10000 -alias upload, reference it in key.properties, and keep both files out of version control. Because new apps must enroll in Play App Signing, Google holds the actual app signing key — if you ever lose your upload keystore, you can request an upload key reset through the Play Console (Setup > App integrity) and continue publishing without losing your app listing.

3. You’re building in the right format. Android requires an Android App Bundle (.aab), not a fat APK. Run flutter build appbundle –release to produce the correct artifact. Adding –obfuscate –split-debug-info=build/app/outputs/symbols obfuscates your Dart code and keeps debug symbols out of the bundle. For iOS, flutter build ipa –release produces the signed archive ready for upload via Xcode Organizer or the Transporter app.

4. SDK targets meet store requirements. For Android, your build.gradle must set both compileSdk = 35 and targetSdk = 35 — Google Play requires apps to target Android 15 (API level 35) for new submissions and updates. Setting minSdk = 24 covers the large majority of active Android devices. For iOS, your project must be built with Xcode 26 or later for submissions after April 28, 2026. Run flutter doctor -v to confirm your toolchain versions before building.

5. Permissions are trimmed and described. Open AndroidManifest.xml and audit every tag — remove anything your app doesn’t actively use, since reviewers flag unused permissions and some third-party plugins inject permissions you may not notice. On iOS, every protected API your app accesses needs a corresponding purpose string in Info.plist. Keys like NSCameraUsageDescription must have a specific, user-facing explanation (for example, ‘Used to scan QR codes for login’). Generic descriptions like ‘Needed for app functionality’ are a common rejection trigger.

6. A hosted privacy policy is in place. Both stores require a privacy policy URL that resolves to a live page — not a PDF, not a Google Docs link, not a staging URL. The policy must describe what data you collect and how it’s used. On iOS, you enter this URL in App Store Connect under App Information and must also complete the App Privacy labels (the ‘nutrition label’ for data collection). On Android, fill out the Data Safety section in Play Console accurately — mismatches between what you declare and what your app actually does can trigger removal after launch.

7. Store assets meet spec. On iOS, your app icon must be 1024×1024px with no transparency, and screenshots for the iPhone 6.9-inch display (1320 × 2868px) are mandatory as of 2026 — missing this size blocks submission. On Android, your store icon must be 512×512px PNG with alpha, and a 1024×500px feature graphic is required. Use flutter_launcher_icons to auto-generate the full set of mipmap directories from a single source image, and generate adaptive icons (transparent foreground layer, solid background) to avoid a plain-square fallback on Android 8+. Remove any debug overlays from screenshots — they cause rejection.

8. You’ve tested a release build on a real device. Running flutter run –release on a physical phone is not optional. Release builds disable debug tooling and apply ProGuard/R8 obfuscation, which can surface crashes and broken deep links that were invisible during development. On iOS, distribute to at least a few testers through TestFlight before submitting — Apple recommends validating on TestFlight as a final gate. On Android, use the Internal Testing track in Play Console (typically approved within 30 minutes) to catch any install or launch issues before pushing to production.

Platform-Specific Gotchas Worth Knowing

On iOS, bundle ID consistency is a frequent pain point. The bundle ID must match exactly across your Apple Developer account, App Store Connect record, Xcode’s Runner target, and any third-party services like Firebase. A single mismatch causes signing failures that are time-consuming to untangle. Also confirm that CocoaPods or Swift Package Manager resolves cleanly on your build machine by running pod install from the ios/ directory before archiving.

On Android, bundle size can quietly creep past store limits if you’re not compressing assets. Convert images to WebP format, enable shrinkResources = true and minifyEnabled = true in your release build type, and verify the final AAB size in Play Console’s artifact explorer after upload. Also note that Play App Signing is now required for all new apps — Google securely holds the app signing key and you submit with a separate upload key, which means you can recover from a lost upload keystore by requesting a key reset through the Play Console without losing your app listing.

For apps with user accounts on either platform, both Apple and Google require you to provide a way for users to delete their account from within the app — not just a mailto link. If your app doesn’t have this and you request account-creation, expect rejection.

Common Mistakes That Cause Delays

Submitting without test credentials. If your app requires login and reviewers can’t access it, Apple will reject immediately. Provide demo credentials in the Notes field of App Store Connect’s App Review Information section. Google Play has the same requirement under the App Content section. Use a dedicated reviewer account so you’re not exposing real user data.

Skipping TestFlight or Internal Testing. Uploading straight to production review with an untested build risks catching a crash after the clock starts on review. Both platforms allow pre-release testing tracks that give you a chance to catch launch bugs. The time invested is almost always less than the time lost to a rejection and resubmission cycle.

Forgetting to increment the build number between submissions. If a build is rejected and you fix the issue, you must bump the build number — even if the version name stays the same — before re-uploading. Submitting the same build number after changes is a common source of ‘build already exists’ errors.

Leaving debug flags in. Double-check that dart:developer, debugPrint, and any logging packages are not writing sensitive data in release mode. Flutter automatically strips most debug assertions, but third-party logging libraries may need explicit configuration to stay quiet in production.

Explore more: App Development guides and tutorials.

Flutter App Store Submission FAQs

What’s the difference between flutter build appbundle and flutter build apk?

flutter build appbundle produces an Android App Bundle (.aab), which is required for Google Play submissions. The Play Store uses the AAB to generate optimized APKs for each device configuration, reducing download size. flutter build apk produces a single APK file, which works for direct distribution and testing but cannot be submitted to the Play Store for new apps or updates.

What happens if I lose my Android upload keystore?

If your app is enrolled in Google Play App Signing (required for all new apps), losing your upload keystore is not fatal. Google holds the actual app signing key, so you can request an upload key reset through the Play Console under Setup > App integrity. After submitting the request with a new certificate, Google typically processes it within a few business days and you can resume publishing updates without losing your app listing.

Do I need a separate Apple Developer account for each Flutter app I publish?

No. One Apple Developer Program membership ($99/year for individuals) lets you publish as many apps as you want under your account. You manage each app as a separate record in App Store Connect. The same applies to Google Play — the $25 one-time registration fee covers unlimited app publications under that developer account.

Build It With GTStudios

Need help shipping your app, game, or small-business tech? GTStudios builds web, apps, and games. See how GTStudios can help.

Photo by Fahim Muntashir on Unsplash.

The post Flutter App Store Checklist: 8 Things to Verify Before You Submit appeared first on GTStudios.