Your Guide to Launching an App (2026 Update)

Learning how to start an app business in Australia comes down to doing six things in the right order: work out how the app makes money, set up a structure that can own it (usually a Pty Ltd company), make sure that company owns the code and the brand, publish app-specific terms and a privacy policy, get through Apple and Google’s review, then keep it all current after launch.

Here’s the honest bit. Most founders pour months into design and code, then treat the business and legal side as a weekend job before submission. That’s backwards. The mistakes that cost real money, like a developer who legally owns your code or an App Store listing stuck in your personal name, all happen before launch. Every one of them is avoidable.

How do you start an app business in Australia, step by step?

You need a monetisation plan, a legal structure, clear ownership of your intellectual property, a set of user-facing legal documents and developer accounts with Apple and Google. Here’s the order we’d tackle them in. Each step makes the next one easier.

Stage	What to sort out	Why it matters for an app
1. Model	How the app makes money and what data it touches	Decides which documents you need and whether Apple and Google take a cut
2. Structure	Company registration, ABN, business name if needed	Decides whose name appears as the seller and who carries the liability
3. Ownership	Developer agreement, IP assignment, NDA	Makes sure the business (not a contractor or founder) owns the code
4. Brand	Trade mark search and application	Stops a forced rebrand after you’ve paid for downloads and reviews
5. User documents	App terms of use, privacy policy, subscription terms	Required by both stores and shaped by Australian consumer and privacy law
6. Store accounts	Apple Developer Program, Google Play Console	Organisation accounts need the company and a D-U-N-S Number first
7. Launch and maintain	Testing, submission, reviews, updates	Every new feature or data flow can change your legal documents

Notice where the app stores sit. Sixth. First-time founders often open a developer account on day one under their own name, then spend weeks untangling it once a company exists.

Start with the business model, because it writes half your paperwork

Before you register anything, answer four questions. Who pays? What do they pay for? What personal information does the app touch? Can users post content other users see?

Those answers decide your document list. A free app with no accounts needs far less than a subscription app with user profiles, chat and payments. They also decide what the stores take. Both Apple and Google generally require their own billing for digital content and features. Apps selling physical goods or real-world services, like a court booking or a tradie call-out, sit outside that rule and can use a payment provider such as Stripe.

That distinction changes your margins by up to 30%, so check it before you price anything.

Should you start an app business as a sole trader or a company?

For most founders who want to start an app business with real users, a company is the better choice. Apps collect data, take payments and get used in ways you can’t fully predict. The risk is higher than it looks from your laptop. A Pty Ltd company is a separate legal entity, so claims and debts sit with the company rather than your house.

Well, mostly. A company doesn’t make you bulletproof. Directors can still be personally liable for insolvent trading, breaches of director duties or personal guarantees you sign. The company protects you from ordinary business risk, not from everything.

The app store reason most guides miss

Apple’s organisation enrolment only accepts legal entities, and it verifies them with a D-U-N-S Number. Trading names and business names aren’t accepted. So if you’re a sole trader trading as “Budget Buddy”, you enrol as an individual. Your full personal name shows as the seller on your App Store listing.

The D-U-N-S Number itself is free. Dun & Bradstreet can take up to five business days to issue it, then Apple needs up to two more to receive it. Request it the day your company is registered.

Google has its own version of this. Personal Play Console accounts created after 13 November 2023 must run a closed test with at least 12 testers for 14 continuous days before they can go live. Organisation accounts skip that requirement. Registering a company first can save you a fortnight of chasing friends to keep a test app installed.

	Sole trader	Company (Pty Ltd)
Personal liability	Unlimited. Your personal assets are exposed	Generally limited to company assets
App Store seller name	Your personal legal name	Your company’s legal name
Google Play testing gate	Applies to new personal accounts	Organisation accounts are exempt
Raising investment	Not possible to issue shares	Can issue shares and set up vesting
Setup and running cost	Low	Higher, with ASIC fees and an annual review
Best for	Testing an idea with no users or revenue yet	Anything you plan to launch, monetise or scale

Going the company route? Register your company before you sign with a developer or enrol in either store. That way the contracts, accounts and IP all start life in the right name.

Do you need an ABN and GST registration?

Yes. You’ll need an ABN for the business, and the stores’ tax setup will ask for it. A company gets its own ABN, separate from any sole trader ABN you already hold. Starting as a sole trader? You can apply for an ABN online in a few minutes.

GST registration kicks in once your GST turnover hits $75,000. One nuance for app founders: when you sell to Australian consumers through the App Store or Google Play, the store is generally treated as the supplier for GST purposes, so Apple or Google accounts for the GST on those sales. Direct web sales and B2B deals work differently. Talk to your accountant before you set prices, and again before your first BAS, because store payouts arrive net of commission and tax and confuse plenty of bookkeepers.

Co-founders and holding companies

Starting with a co-founder? Put a shareholders agreement in place before the first line of code. It covers vesting, decision-making and what happens if one of you walks away with half the equity and none of the work.

Some founders go a step further and hold the app’s IP in a holding company that licenses it to a separate trading company. If the trading company gets sued, the core asset sits one step removed. The catch? The protection only exists on paper if there’s actually paper. We regularly see two-company structures with no signed licence between them, which leaves the arrangement easy to challenge. Get your accountant’s view on tax first, and sign the licence the same week.

Do you need to register an app in Australia?

There’s no government register for apps. When people talk about registering an app, they usually mean one of four separate registrations. You need some of them before launch, and one is easy to forget about. Here’s which is which when you set up an app business in Australia.

What you register	Where	Do you need it?
The business itself	ASIC for a company (you get an ACN), the ABR for an ABN	Yes, before you sign contracts or enrol in the stores
A business name	ASIC’s business names register	Only if you trade under a name that isn’t your exact legal or company name
The app name as a trade mark	IP Australia	Strongly recommended, ideally before you build
Your developer account	Apple Developer Program and Google Play Console	Yes, this is what actually lets you publish

Here’s the wrong assumption we hear most often. Registering a business name feels like owning it. It doesn’t. A business name registration only tells the public who is trading under that name. It gives you no right to stop someone else launching an app with the same name. That protection comes from a trade mark.

Some apps also need an industry licence. An app that gives financial product advice may need an Australian financial services licence. Software that diagnoses, monitors or treats a medical condition can be regulated as a medical device by the TGA. If your app touches money or health, check this before you build.

Who owns your app’s code when you start an app business?

Whoever wrote it, unless a contract says otherwise. Under Australian copyright law, code written by an employee in the course of their job belongs to the employer. Code written by a freelancer, agency or offshore contractor belongs to them by default, even if you paid every invoice.

That default catches a lot of founders out. Without a written assignment, your developer could reuse the code, refuse to hand over the source files or become the only person who can update your app. Investors will find this in due diligence, and it can stall a raise.

What your developer agreement should cover

Use a software development agreement before any work starts. Not after the first sprint. At a minimum it should deal with:

• IP assignment. All code, designs and assets created for the project transfer to your business on payment.
• Source code handover. The developer delivers the full source files and repository access, not just a compiled app.
• Third-party and open-source components. The developer lists what they’ve used and confirms the licences allow commercial use. Some “copyleft” licences can require you to publish your own code.
• Specifications, milestones and acceptance testing. Paying in stages against agreed deliverables means you still hold something back if the project drifts.
• Store account access. Your app should sit in your business’s developer accounts, with the developer added as a team member. Never the other way around.
• Confidentiality, security and warranties. The developer keeps your idea private, handles user data securely and promises the work doesn’t infringe anyone else’s rights.

One practical warning on offshore developers. A contract is still worth having, but enforcing an Australian judgment overseas is slow and expensive. Staged payments and repository access from day one protect you better than any clause. If the offshore team can see user data, your privacy policy needs to say so too.

Hiring staff or contractors to build it

Bringing developers in-house changes the picture. Employees need an employment contract, award-compliant pay and super, and the IP they create belongs to you automatically. Contractors need a contractor agreement with an express IP clause, because the default runs the other way.

Where founders get caught is the “contractor” who works fixed hours, uses your equipment and answers to you like staff. Labelling them a contractor doesn’t make them one. Get the arrangement right before they start, not when they ask about super.

Fixing ownership after the fact

Already built the app without a proper contract? Or wrote it yourself before the company existed? Fix it with an assignment of intellectual property, signed by whoever currently owns the code, transferring it to your company. Do the same for the logo, designs and any content a freelancer created.

And before you pitch the idea to developers, designers or investors, have them sign a mutual non-disclosure agreement. It won’t stop someone building a similar app from scratch. It does stop them walking off with your materials.

How do you protect your app’s name and brand?

Register a trade mark. A registered business name doesn’t give you exclusive rights to a brand, and neither does publishing first on the App Store. A trade mark registered with IP Australia is what lets you stop copycats using a confusingly similar name. You can register a trade mark for your app name and logo online.

Search before you build. If someone already holds a trade mark for a similar name in software, you could be forced to rebrand after you’ve spent money on downloads, reviews and paid ads. Rebranding an app means a new listing name, new screenshots and a confused user base. It’s a painful few months.

Most apps need protection in class 9 (downloadable software) and often class 42 (software as a service). If your app delivers a specific service, such as fitness coaching or education, you may need that service’s class too, for example class 41 for education. Getting the classes wrong is one of the most common reasons founders end up with a registration that doesn’t cover what they actually do. If budget is tight, file the word mark first. The name is what people search for.

What about patents and copyright?

Copyright in your code, graphics and written content arises automatically in Australia. You don’t register it. And no, you don’t need a copyright notice on every screen. It adds very little.

Patents are harder. Australian courts have been strict about software, and an app that simply runs a business process on a phone usually won’t qualify. If your app does something genuinely technical and new, speak to a patent attorney before you release it publicly, because public disclosure can destroy novelty.

What legal documents does an app need before launch?

At a minimum, an app needs terms of use and a privacy policy that match how the app actually works. Depending on your model, you may also need subscription terms, a B2B agreement, community rules and website terms. Here’s the short version before the detail.

Document	Who needs it	Common mistake
Mobile app terms of use	Every app with users	Terms users only “accept” by opening the app
Privacy policy	Every app on either store	Copying another app’s policy that describes different data
Subscription terms	Any app with trials or renewals	Hiding cancellation inside store settings with no explanation
Community or acceptable use rules	Apps where users post, message or upload	Leaving them out of social apps, which Google requires
B2B or SaaS agreement	Apps sold to businesses, clubs or clinics	Using consumer terms for an enterprise customer
Standalone EULA	Downloadable software, SDKs, desktop tools	Paying for a EULA that repeats your terms of use

App terms of use

Your mobile app terms of use are the contract between your business and your users. They set out what users can and can’t do, how payments and refunds work, who owns user content, when you can suspend accounts and how far your liability goes.

Three details matter more than most people think:

• Use click-wrap acceptance. Make users tick a box or tap “I agree” at sign-up. Terms users are only “deemed” to accept by using the app are far harder to enforce.
• Respect the consumer guarantees. A clause saying “no refunds under any circumstances” misrepresents your customers’ rights under the Australian Consumer Law. You can say store purchases are refunded under Apple’s or Google’s process, and link to it, but keep the consumer guarantees intact. Since November 2023, unfair terms in standard form contracts can attract penalties, not just be struck out.
• Drop the “we can change these terms at any time” clause. A one-sided variation clause is a classic unfair term. Give advance notice of material changes and let users cancel without penalty if they don’t like them.

Running a website alongside the app? You can often use one combined set of terms for both, provided it clearly covers each platform and says where subscriptions are actually bought. Our guide on using the same terms for your website and app walks through when that works.

Privacy policy

Apple and Google both require a privacy policy for every app, linked from your store listing and inside the app. A mobile app privacy policy explains what data you collect, why, who you share it with (including analytics and ad SDKs) and how users can access or delete it.

Many founders assume the Privacy Act 1988 (Cth) doesn’t apply to them because of the small business exemption for businesses turning over less than $3 million. Be careful. The exemption doesn’t cover businesses that trade in personal information, such as passing user data to third parties for a benefit, or health service providers. And since 10 June 2025, individuals can sue over serious invasions of privacy under a statutory tort that applies whether or not you’re exempt.

More is coming. From 10 December 2026, privacy policies for businesses covered by the Act must explain any automated decision-making that uses personal information and could significantly affect people. The OAIC’s Children’s Online Privacy Code must also be registered by that date, although its start date hasn’t been confirmed.

Three gaps turn up again and again in app policies:

• Social sign-in data. “Sign in with Apple” or Google can hand you a name and email. If you can receive it, your policy has to cover it, even if you never display it.
• Named third parties. Affiliates, marketplaces and payment partners that receive user data should be identified, not buried under “service providers”.
• Offshore hosting and access. A US-based backend or an overseas support team means cross-border disclosure. Say so, and get consent where it’s needed.

Your store declarations need to match your policy, too. Apple’s privacy “nutrition label” and Google’s Data safety form ask what your app collects. If they don’t line up with your privacy policy, expect a rejection or, worse, a complaint.

Apps with AI features

Using a third-party AI model to summarise, generate or recommend? That’s a data flow, and most founders forget to document it. Your privacy policy should say what goes to the AI provider and where it’s processed. Your terms should say AI output can be wrong.

Check the provider’s terms too. Many offer a data processing agreement covering where data is stored and whether it can be used for training. Sign it before launch, not after a user asks.

Do you still need an EULA?

Sometimes. If you don’t supply your own licence, Apple applies its standard Licensed Application End User License Agreement, which is governed by Californian law. That’s not ideal for an Australian business, and Apple lets you replace it with your own terms.

For most consumer apps, though, well-drafted terms of use that include a licence to use the app do the job. A standalone EULA makes more sense for downloadable software, SDKs or desktop tools. Don’t pay for two documents that say the same thing.

Apps sold to businesses, or that connect buyers and sellers

Selling to gyms, clubs, clinics or schools rather than individuals? Consumer terms aren’t enough. The business customer needs its own SaaS or subscription agreement covering pricing, uptime, support, data ownership and what happens to their data when they leave. The people using the app still accept your end-user terms.

Marketplace apps have a different problem. If merchants or providers list on your platform, your terms need to make clear the sale contract is between the customer and the merchant, and that merchants are responsible for their own pricing and descriptions.

Apps with children, health or user-generated content

Is your app aimed at children or likely to attract them, or does it collect health, biometric, location or family information? Then your obligations step up. You’ll need explicit consent flows, parental consent where children are involved and a privacy policy written for your actual data. The draft children’s code goes further, proposing child-friendly privacy policies and privacy impact assessments for services likely to be used by kids.

Health and wellbeing apps also need clear disclaimers that the content isn’t medical advice. Social media style apps should check whether the minimum age rules for social media platforms, in force since December 2025, apply to them.

Can users post, message or upload? Then your terms need a licence to host that content, rules about what’s banned, a way to report it and the right to suspend accounts. Google Play goes further for apps listed as Social or Dating: you must publish standards prohibiting child sexual abuse and exploitation, offer in-app reporting and nominate a child safety contact before you can publish.

What other laws apply once your app has users?

Two areas catch app founders in their first year: marketing messages and data breaches. Neither needs a lawyer every week. Both need a plan before launch.

Marketing emails, SMS and push notifications

Account and transactional messages (password resets, receipts, renewal notices) are part of running the service. Marketing messages are different. Under the spam rules, commercial emails and SMS need consent, must identify your business and need a working unsubscribe.

Don’t bundle marketing consent into your terms. A separate opt-in at sign-up is cleaner, and it’s what reviewers and regulators expect to see.

Data breaches and security promises

If you’re covered by the Privacy Act, the Notifiable Data Breaches scheme can require you to notify affected users and the OAIC when a breach is likely to cause serious harm. Even exempt businesses benefit from a simple data breach response policy, because the first 72 hours are chaos without one.

Watch what you promise. “Bank-grade security” is a marketing claim you may have to prove. The opposite mistake also shows up: template wording warning that nothing online is ever secure, which spooks users for no reason. Say you take reasonable steps to protect data, then actually take them.

What changes for subscription apps in 2027?

Parliament passed the Competition and Consumer Amendment (Unfair Trading Practices) Act 2026 on 2 July 2026. From 1 July 2027, it bans unfair trading practices and subscription traps across the Australian Consumer Law. If your app runs on free trials and auto-renewals, this is the change to plan for now.

In practice, businesses offering subscriptions will need to give key information before sign-up, keep subscribers informed during the subscription and offer an easy, straightforward way to cancel, including online cancellation in some cases. Drip pricing is also targeted: if you show a base price, you’ll need to disclose any extra transaction-based charges alongside it.

A broader ban targets manipulative design, often called dark patterns. Think fake countdown timers, pre-ticked upsells or a cancel button hidden three menus deep. Penalties sit under the existing ACL regime, which runs to tens of millions of dollars for companies.

A common assumption is that Apple and Google handle all of this because they process in-app payments. They handle the billing. You’re still responsible for how your app presents offers, what your terms promise and whether your onboarding pushes people into something they didn’t mean to buy. Build honest subscription screens now and 2027 becomes a non-event.

How do you launch an app on the App Store and Google Play?

How do you launch an app once the business side is in place? It follows a similar path on both stores: enrol, build and test, prepare your listing, submit for review, then release. The details differ, and those details are where launches stall.

	Apple App Store	Google Play
Account	Apple Developer Program, about A$149 a year	Google Play Console, a one-off US$25 fee
Organisation enrolment	Legal entity plus D-U-N-S Number	Organisation account with D-U-N-S Number
Testing before launch	TestFlight is optional but strongly recommended	Mandatory 12 testers for 14 days for new personal accounts
Privacy disclosures	Privacy nutrition label plus privacy policy link	Data safety form plus privacy policy link
Account deletion	Required in-app if users can create accounts	Required, with a web link to request deletion
Search keywords	App name, subtitle and a 100-character keyword field	Title, short description and full description are all indexed

Fees change, so check the current amount when you enrol.

Launching on the App Store

You’ll manage your app through App Store Connect (the tool older guides still call iTunes Connect). Before you submit, run a beta through TestFlight on real devices, not just the simulator. Apple rejects apps for crashes, broken links, placeholder content and missing login details for the reviewer far more often than for anything exotic.

Two requirements catch founders out. If users can create an account in your app, they must also be able to delete it from within the app. And your privacy label has to reflect every SDK in your build, including analytics and crash-reporting tools you didn’t write yourself.

Launching on Google Play

Google Play also requires a privacy policy link, a completed Data safety form and a working way for users to request account deletion. On a new personal account, the closed test is the real bottleneck. The 14 days must be continuous, and if your opted-in testers drop below 12, the clock effectively resets. Recruit 20 or so, so ordinary drop-off doesn’t cost you another two weeks.

Why first submissions get rejected

Most rejections are boring. Good news, because boring problems are easy to prevent. The usual suspects are crashes on a device you didn’t test, a login screen with no demo account for the reviewer, placeholder text or broken links, a privacy policy URL that doesn’t load, and privacy declarations that don’t match what the app collects.

Apps that let users pay for digital content outside the store’s own billing also draw attention. If your model involves web payments, read the current payment guidelines before you design the checkout, not after the rejection email.

A rejection isn’t the end of the road. Read the reason carefully, fix exactly what the reviewer flagged and reply through the resolution centre if something was misunderstood. One warning: don’t let your developer rewrite your privacy policy just to get through review. Fix it properly, then resubmit.

Writing a store listing that gets found

App Store search doesn’t read your description, so your keywords need to live in the app name, subtitle and keyword field. Don’t repeat words across those fields; Apple already combines them. Google Play works more like a search engine and reads your full description, so write it for humans first and use your main terms naturally.

Either way, the first two lines of your description do most of the selling, because that’s all people see before tapping “more”. Lead with the problem you solve, not your feature list. Keep every claim accurate, too. A listing is advertising, and misleading claims about features you haven’t built yet breach the Australian Consumer Law.

Set up a simple website for the app as well. It hosts the privacy policy and support page both stores ask for, and it helps journalists and search engines find you.

What we see in Lawpath consultations

Lawpath lawyers speak with founders working out how to start an app business every week, from pre-revenue side projects to funded startups weeks from launch. The same problems come up again and again.

• The developer is already building, with nothing signed. It’s one of the most common situations we see. The fix is simple while the relationship is friendly: a development agreement with an IP assignment, signed before the next invoice is paid.
• The code or accounts sit in the wrong name. IP owned by the founder personally, or by the developer, with the app live in an individual developer account. An IP assignment deed into the company and a store account transfer fix it, and both are far easier before launch than after.
• Documents stitched together from AI tools or other apps. Typical gaps are data flows the policy never mentions, subscriptions described as in-app when they’re sold on the website, template wording about sizes and packaging in a purely digital app, and references to the “National Privacy Principles”, which were replaced by the Australian Privacy Principles back in 2014.
• Terms that break consumer law. Blanket no-refund clauses, “we may change these terms at any time” clauses and liability exclusions with no “to the extent permitted by law” wording are among the most common fixes our lawyers make.
• Privacy policies that miss the quiet data flows. Social sign-in details, affiliate partners, offshore hosting, offshore support staff and AI providers all need to be disclosed. Founders usually know about these flows. They just don’t think of them as “collecting” anything.
• Children’s and sensitive data treated as ordinary data. Education, health, family and sports club apps often collect far more sensitive information than the founder realises. Our lawyers also commonly recommend limiting paid subscriptions to users aged 18 and over, so each subscriber can contract in their own name.
• Insurance as an afterthought. Professional indemnity and cyber insurers often want to see your final terms before quoting, and your liability cap should make sense next to your cover. Get the terms right first.

None of these are exotic. They’re the normal result of building fast, and they’re all cheaper to fix before your first thousand users than after.

What happens after you launch your app?

Launch day is when the maintenance job begins. Watch crash reports in App Store Connect and Play Console, reply to reviews (both stores let you respond publicly) and ship fixes fast while early users are still forgiving.

Treat your legal documents like part of the product. Every time you add an SDK, a payment option, an AI feature or a new data collection point, check whether your privacy policy, store disclosures and terms still describe what the app actually does. Out-of-date documents are one of the quietest risks in an app business. Nobody notices until a regulator, user or investor does.

One habit fixes most of it: put a legal check on your release checklist for any update that changes what data you collect, what you charge or who can use the app.

Checklist: how to start an app business in Australia

• Monetisation model decided, including whether store billing applies
• Company registered, with its own ABN (and GST if you’re over or near $75,000)
• Shareholders agreement signed if there’s more than one founder
• Developer agreement signed, with IP assignment and source code handover
• Any existing IP assigned from founders or freelancers to the company
• Trade mark search done and application filed for the app name
• D-U-N-S Number obtained and organisation developer accounts set up
• Mobile app terms of use with click-wrap acceptance in the sign-up flow
• Privacy policy that matches your real data flows, linked in-app and in both store listings
• Apple privacy label and Google Data safety form completed and consistent with the policy
• Separate opt-in for marketing messages
• In-app account deletion working
• Subscription screens that clearly show price, renewal and how to cancel
• Beta tested on real devices (and the 14-day Google test completed if it applies)
• Support website live with contact details and your legal documents

Frequently asked questions

How much does it cost to start an app business in Australia?

Development is the big cost, and it varies widely with complexity. On top of that, budget for company registration and ASIC fees, a trade mark application, your legal documents, the Apple Developer Program (about A$149 a year) and a one-off US$25 Google Play fee. Legal setup is usually a small fraction of the build.

Can I start an app business as a sole trader?

Yes, but you’ll carry unlimited personal liability, publish on the App Store under your own personal name and, on a new personal Google Play account, face a 14-day, 12-tester testing requirement. A sole trader setup suits testing an idea. Most founders switch to a company before launch.

Do I need an ABN to publish an app?

If you’re running the app as a business, yes. Both stores’ payment and tax setup will ask for your business details, and you need an ABN to trade in Australia. A company gets its own ABN, separate from any sole trader ABN you already hold.

Do I need a D-U-N-S Number to publish an app?

Only if you enrol as an organisation, which a company should. Apple requires a D-U-N-S Number registered to your legal entity, and Google uses one for organisation accounts. It’s free, but allow about a week for Dun & Bradstreet and Apple to process it.

Does my app need a privacy policy if I don’t collect personal information?

Yes. Apple and Google require a privacy policy for every app, whatever it collects. In practice, most apps do collect personal information through sign-up, social login, analytics, crash reports or advertising SDKs, even when the founder thinks they don’t.

Who owns the code if I pay a developer to build my app?

The developer does, unless a written agreement assigns it to you. Australian copyright law gives ownership to the person who creates the work, except for employees working in the course of their job. Get a signed IP assignment and the full source code handed over.

How do I register an app name in Australia?

Apply for a trade mark with IP Australia, usually in class 9 and often class 42. That is the only registration that gives you exclusive rights to the name. Register a business name with ASIC as well if you trade under a name that is different from your company name.

Should I trade mark my app name before launching?

Yes, ideally before you build. A registered trade mark gives you exclusive rights to the name in your chosen classes, while a business name or App Store listing gives you none. Most apps need class 9, and often class 42.

Do I have to use Apple’s or Google’s in-app payments?

For digital content and features sold inside the app, generally yes, and the store takes a commission. Apps selling physical goods or real-world services, such as bookings or deliveries, can usually use their own payment provider. Check the current store guidelines before you design checkout.

Do Apple’s and Google’s terms protect my business?

No. Their developer agreements protect Apple and Google. You still need your own terms of use and privacy policy to govern your relationship with users and limit your liability. Their refund policies also don’t override the Australian Consumer Law.

How long does it take to launch an app on the stores?

Apple’s review commonly takes a day or two, but allow extra time for a first submission and possible rejections. On Google Play, a new personal account needs at least 14 days of closed testing before it can apply for production. Build a few weeks of buffer into your launch date.

What changes for subscription apps from July 2027?

From 1 July 2027, bans on unfair trading practices, subscription traps and drip pricing start. Subscription apps will need clear pre-sign-up information, updates during the subscription and an easy way to cancel. Manipulative design patterns will also be prohibited.

Can I use one set of terms for my website and app?

Often, yes, as long as the document clearly covers both platforms and reflects how each works, such as whether subscriptions are bought on the web or in the app. If the website and app do very different things, separate terms are cleaner.

Feeling a bit overwhelmed? That’s normal. Learning how to start an app business means learning three new rulebooks at once. You don’t need everything perfect on day one. You need the structure right, the code in your name and honest documents that match your app. Founders who sort those out before launch are already ahead of most apps in the store.

Your fastest next step is to hand the setup to people who do it every day. Get a fixed-fee quote from a Lawpath lawyer to set up your app’s structure, IP and launch documents in one go, then get back to building.