How I Got My App Published on the Apple App Store

I started with a practical problem

My app, WP Labs: Invoice, is now live on the Apple App Store. Getting it there involved much more than making a few screens look good.

I wanted to bring estimates, invoices, customer information, and job records into one app. For an independent professional, those details belong together: the customer who asks for an estimate is the same customer who eventually needs an invoice.

That practical goal gave the project a starting point. Instead of trying to build every possible business tool, I had a workflow to build around: prepare the work, document it, and keep track of what the customer owes.

I built with tools I could work with

The project uses Expo and React Native for the mobile app, Supabase for backend services, and RevenueCat for subscriptions. I developed on Windows and later moved the project to a Mac as I worked with the Apple side of the process.

Those tools helped me build the app, but they did not make all the decisions for me. I still had to think through account creation, customer records, document details, and what a person should see when they first open the app.

If you are a beginner, that is a useful distinction. Choosing a framework gives you a way to build. You still need to decide how your app helps someone complete a real task.

I learned that running an app and preparing a store build are different jobs

Seeing the project run during development was progress. Preparing an iOS release introduced another set of details: app configuration, signing credentials, build settings, and the file that gets uploaded to App Store Connect.

Expo Go was part of my development setup, while EAS was part of the production-build work. An app working in a development environment did not mean every release setting was ready.

Across the project and later updates, I also worked through Google sign-in configuration and iOS build errors. I learned to treat an error message as something specific to investigate: what setting is missing, what part failed, and what needs to be checked before trying again?

Expo’s iOS submission guide explains that workflow. I have also put together a beginner-friendly submission overview here on the blog.

I had to think about the information around the app

The app itself was only one part of the release. I also needed the information that explains it: its name, description, screenshots, support details, and privacy-related pages.

For WP Labs: Invoice, the website includes support, privacy, terms, disclosures, and customer-facing pages. Those pages help explain the product and give people somewhere to go when they have a question.

For anyone preparing a first submission, my advice is to check whether the listing describes the app you are actually submitting. Use screenshots from the app, describe the features plainly, and make sure support links lead somewhere useful.

Apple’s before-you-submit guidance calls for complete, accurate information and accessible backend services. It also asks for review access when an app requires an account.

Subscription setup was a separate piece to get right

One App Store Connect issue I encountered involved subscription groups. The message said:

“New subscription groups must be submitted with an auto-renewable subscription from within that group.”

That made it clear that creating a group and creating the product inside it were connected parts of the setup. Subscription configuration needed its own attention alongside the app submission.

I used RevenueCat in the app, but Apple’s product setup and review requirements still mattered. A subscription service helps manage purchases; it does not replace App Store Connect.

Apple’s current in-app purchase submission instructions say the first product of each purchase type, including an auto-renewable subscription, must be submitted with a new app version. Check those instructions for the situation that applies to your app.

My takeaway: do not leave subscriptions until the final few minutes before submission. Give yourself time to connect the product setup, the app’s plan screen, and the review submission.

The reviewer needs to understand how to use the app

An app can make sense to its developer and still leave someone else unsure where to begin. I knew what each screen was supposed to do because I had been working on it. A reviewer or new customer does not have that background.

For a first release, I would focus review notes on the steps needed to reach the important features. If signing in is required, provide the access Apple needs. Explain anything a reviewer would otherwise have to guess.

Apple’s review guidance specifically asks for access to account-based features and explanations of less obvious functionality or purchases. That is a useful reminder to look at the app from someone else’s point of view.

A practical test is to start with a fresh account and walk through one complete task. For an invoicing app, that could mean adding a customer, preparing a document, and checking the result rather than only looking at the dashboard.

Getting published was a milestone, and the work continued

WP Labs: Invoice was approved and became available on the App Store. That is the concrete result of this project: an app someone can download and use.

Publishing did not finish the development work. Since release, I have continued working on onboarding, subscription choices, business settings, and how customer and job information fits together.

Fresh-account testing has been especially useful. A developer account with existing data can hide questions that a new customer will encounter immediately.

I now think about release preparation and everyday usability together. A working build matters, and so does the person trying to create their first invoice without having to understand how the app was built.

What I would tell someone publishing their first app

Start with one useful workflow and get it working from beginning to end. Keep a record of the issues you encounter and what you changed, so you can check the same steps again before an update.

Make room in your plan for the parts around the code: the listing, support pages, account access, subscriptions, and the review submission. They are part of delivering an app to real people.

You do not need to know everything before you begin. You do need to keep checking your assumptions as the project moves from your development environment to a release.

For me, publishing WP Labs: Invoice turned an app project into a product I could keep improving. That is the part I want to share here: practical lessons from building something, working through the details, and taking the next step.

Official guides to keep nearby

• Expo: submit an iOS app with EAS
• Apple: submit an app for review
• Apple: before you submit
• Apple: submit an in-app purchase

Publishing guidance checked October 4, 2026. This is my experience with WP Labs: Invoice; the official guides cover current requirements.