Powstania Warszawskiego 15
31-539 Kraków
Most of a first release is code. The part that sets the date usually is not. Before a build reaches either store, a company needs two developer accounts, a business identifier issued by a third party, a declared trader status for the European Union, and a build that clears deadlines both stores moved this year. Here is what you need to publish an app in 2026, checked against Apple and Google in September.
Two: an Apple Developer Program membership and a Google Play Console account, both registered to the company as an organization rather than to a person. Publishing to both stores costs very little. Store commissions come later and only if you sell something. The account fees themselves are small: Apple runs an annual charge, Google a single registration charge that never repeats.
What actually matters is the account type. On both stores you can register as an individual or as an organization, and the choice changes who is named as the seller, who can be added to the team, and on Google Play, how long your first release takes to reach production.
An organization enrollment needs legal entity status, a D-U-N-S number registered to that entity, a work email on your organization domain, a publicly available and functional website on that same domain, and a person with legal authority to bind the company to agreements.
Apple does not accept trade names, DBAs, fictitious businesses or branches. The legal entity name becomes the seller shown on the App Store. If you are not the owner or founder, Apple asks for a reference who can confirm your authority, and it may ask for notarized business documents.
An organization account is linked to a Google payments profile carrying the company legal name and address, and needs a D-U-N-S number whose registered details match that profile. Contact email and phone are verified by one time code and must stay reachable.
Google verifies these identity details before you can publish, and the legal name and address returned by the D-U-N-S lookup have to match the payments profile. You get a limited number of attempts to enter the D-U-N-S correctly.
The most common failure on the Google side is a mismatch: the legal name typed into the console is a trade name or a shortened version rather than the exact name on the incorporation certificate. The same discipline applies on Apple.
Both stores compare your entry against an external record, so a company that trades under a brand name should have its registration documents open while filling in the forms.
Yes, for an organization account on either store, and it is the item most likely to move a launch date.
A D-U-N-S number is a nine digit business identifier issued by Dun and Bradstreet. Both Apple and Google use it to confirm that an organization exists as a legal entity. Apple describes them as free in most jurisdictions, and many companies already have one without knowing, so the first step is always a lookup rather than an application.
Apple asks you to allow up to five business days after requesting one, and says paying for expedited service does not shorten that. In practice, companies that have never been in the Dun and Bradstreet database report longer waits, and a representative may call to confirm business type or headcount before the number is issued.
This is the item that quietly sets the earliest date anything else can happen. Organizations cannot even buy the membership until Apple Developer Support has verified the enrollment details. Without the membership there is no app record, and without the app record there is no first TestFlight build.
On our projects at Apps Value, a Flutter and React Native team in Kraków, this is the single request we make in week one, before design is finished and long before there is anything to upload.
Personal Google Play accounts created after November 13, 2023 cannot publish to production until they have run a closed test with at least 12 testers who stayed opted in continuously for 14 days. The requirement started at 20 testers and Google reduced it to 12 in December 2024, so older guidance you may find is wrong on the number.
Three details decide whether this hurts. It applies per app, not per account. Internal testing does not count, only the closed testing track. And if testers drop below 12, the 14 day clock restarts, which is why teams recruit a few more than the minimum.
Organization accounts sit outside this requirement. That is the practical argument for registering as a company even when a founder could technically ship under their own name: an organization account trades a longer verification up front for a shorter path to production, and it keeps the company as the named seller.
An organization Play account skips the closed test that adds at least two weeks to every first release from a personal account.
If you offer the app in the course of a business, yes, and without a verified status the app is removed from every European Union storefront.
The European Digital Services Act requires app stores to show verified trader contact details on the product page. Apple implemented this in two stages. Since October 16, 2024 you must declare trader status to submit a new app or an update for the European Union, and since February 17, 2025 apps without a verified status are removed from the App Store across the EU until it is provided.
That removal was not a warning. When the deadline passed, Appfigures counted close to 135,000 apps going inactive across EU storefronts inside about 30 hours, including approved apps that were already live and had not changed at all.
You are a trader if you offer the app in the course of a business, which covers paid apps, in app purchases, advertising revenue, VAT registration in the EU, or an app that promotes a business. Every developer has to declare a status either way, including those declaring that they are not traders.
An address, a phone number and an email address, shown to users on the app product page. For organizations Apple prefills the address associated with the D-U-N-S number.
The obligation is that the details are accurate and reachable, not that they are personal. A registered business address and a support line and inbox that a real person monitors satisfy it. Details that turn out to be unreachable put the listing back at risk, because the platform is obliged to act on unreliable trader information.
Uploads to App Store Connect need Xcode 26 and an iOS 26 SDK, and Google Play submissions must target API level 36 or higher. Both stores moved the bar this year, and both changes block submission rather than downloads. An app that is live and untouched keeps running. The moment you need to ship an update, including a security patch, the bar applies.
Since April 28, 2026, anything uploaded to App Store Connect must be built with Xcode 26 or later using an SDK for iOS 26, iPadOS 26, tvOS 26, visionOS 26 or watchOS 26.
This is about the SDK you build with, not the version your users run, so your deployment target can stay lower. One side effect is visual: apps built against the iOS 26 SDK pick up the new system look on native controls unless you opt out, which is worth a full pass on screens before release.
Since August 31, 2026, new apps and updates must target Android 16, meaning API level 36 or higher, to be submitted to Google Play. Existing apps must target at least API level 35 to stay available to new users on newer devices.
An app that is behind gets a policy warning in Play Console, and the extension form on the Policy status page can keep it distributed to all users until November 1, 2026. Permanently private apps restricted to a single organization sit outside these rules.
Apple also required updated age rating responses for every app by January 31, 2026, and ratings were automatically migrated to the new system on that date. If an app has not been touched in a year, this is one of the settings that can hold up an otherwise routine update.
If your team has not shipped in six months, do a dry run upload before you need one. Toolchain and SDK failures are silent until the moment you upload, and finding them during a real release is how a one day patch becomes a one week patch. This is one of the reasons our app maintenance work starts with a build audit rather than a feature list.
Google is adding an identity layer underneath Android itself, separate from the Play Console account. Registration opened to all developers in March 2026, and from September 30, 2026 apps must be registered to a verified developer in order to install and update on certified Android devices in Brazil, Indonesia, Singapore and Thailand.
The first phase covers installs from Google Play and several device maker stores in those four markets. Google says the requirement expands globally in 2027 but has not published an exact date, so any source giving you a firm 2027 deadline is guessing.
For a European or American company shipping now, nothing changes this month. It matters in two cases: if you distribute in those four markets, and if you distribute outside Google Play at all, for example an internal tool handed to field crews by direct install.
There is also a new limited distribution account for hobby and student projects, free and capped at 20 devices, which is not a route for a commercial product.
The accounts belong to the client. Not to the agency, not to the developer who set them up, and not to a personal address that leaves when someone changes jobs. The company pays the fees, the company is named as the seller, and the company keeps control of the listing, the certificates and the users who have access.
An agency does not need ownership to do the work. Both stores support inviting a team member with the right role, which is how we ship on fixed price projects: your account, our access, and a handover that is nothing more than removing a user at the end.
Where this goes wrong is inherited work. When we take over an app from another supplier, the account question is the first thing we ask about and often the hardest to answer, because the original account sits with a supplier who has stopped answering email.
That is a slow problem to unwind, and it is a large part of why rescue projects start with access rather than code.
Plan on the first two weeks of a project, running alongside design at no cost to the schedule, and longer when a D-U-N-S number has to be requested from scratch.
The paperwork alone occupies those weeks: a D-U-N-S lookup or request, two enrollments with verification on both sides, a payments profile, a trader declaration, and, on a personal Play account, a 14 day closed test before production is available.
None of that is difficult, and none of it can be compressed by working harder or by adding developers. It is a queue with external parties in it. Our own project timelines put accounts and access in week one for exactly this reason, and the projects that slip are almost always the ones where this step waited for the build to be ready.
If you are scoping a first release now, this belongs in the first conversation, alongside scope and budget. We cover it in the discovery workshop and in what we ask for when you brief an app development company, and it is one of the few parts of a project a client can complete before anyone writes code.
Both stores support transferring an app between accounts, but the transfer carries conditions on both sides and takes longer than opening the correct account at the start. If a company exists, register as an organization from day one. It also avoids the Google Play closed testing requirement, which applies to personal accounts created after November 13, 2023.
Apple asks you to allow up to five business days for the D-U-N-S number alone, and that step comes before enrollment. Apple does not publish a time for the organization review, and organizations can only buy the membership once Apple Developer Support has verified the enrollment, so a company starting from nothing should plan in weeks rather than days.
For organization accounts, yes on both. Apple requires it for companies and educational institutions, and Google requires it for organization accounts unless the account belongs to a recognised government body. Individual accounts do not need one, but they publish under a personal name rather than the company name.
Week one of the project. The verification steps run in parallel with design and build at no cost to the schedule, and they are the only part of a launch that depends on organizations outside the project. Waiting until the app is ready converts a background task into a blocking one.
It should not own them. The company should create both accounts in its own name and invite the agency as a team member. We work this way at nearshore engagements across Europe, and it means the handover at the end is a permissions change rather than a negotiation.
An address, a phone number and an email address on the app product page in the European Union. The information has to be accurate and reachable, so a registered business address with a monitored support line and inbox is the normal arrangement rather than personal contact details.
Not in the first phase. It applies to installs on certified Android devices in Brazil, Indonesia, Singapore and Thailand. It becomes relevant to everyone when Google expands it globally in 2027, and it is relevant sooner if you distribute an app outside Google Play, such as an internal tool installed directly on company devices.
Thomas Siudut
Co-Founder and CEO, Apps Value
Thomas sets the company's long term strategy and direction, identifies market opportunities, and owns business development and client acquisition. He builds strategic partnerships that last beyond a single project. He works with clients from the first strategy conversation, so their business goals, not just their feature list, drive every decision.
Bring your scope and we will tell you what has to be in motion before the build starts, and what the account setup does to your date.
Book an intro call30 minutes, no preparation needed.