App development in Mallorca: how to publish your app on the App Store and Google Play without surprises

When a company commissions app development in Mallorca, almost the whole conversation is about design, features and budget. Hardly anyone asks about the last stretch: getting the app onto Apple's App Store and Google Play. It looks like a minor formality until the app is finished, the team expects it on Monday, and the store sends it back for a reason nobody saw coming.

This article covers what to have ready before you publish, who should own the store accounts, how to lower the risk of a rejection and what to do in the weeks after launch. It applies just as well to a business in Palma as to one in Menorca, Ibiza or Formentera.

An example to set the scene

Picture a padel club in Calvià (a hypothetical case) that commissions an app to book courts, join matches and receive notifications. Development goes well and the demo works. But when it's time to publish, several things surface at once: the developer accounts were opened by an outside contractor using a personal email, there's no public privacy policy, the screenshots are from the prototype, and nobody has thought about how to move from internal testing to real members.

None of it is serious on its own. Together, a week before launch, they turn into an avoidable delay.

1. Developer accounts should belong to the company

To publish on both stores you need a developer account with each (Apple and Google), and both charge a fee you should check on their official sites. What matters isn't the cost but whose name the accounts are under.

• In the company's name, with a corporate email that doesn't depend on one person.
• With at least two people on your side holding admin access.
• With real tax and contact details: the stores use them to verify the owner, and that process can take longer than expected.
• With the development team added as collaborators, not as owners.

If the account belongs to your supplier and you change supplier one day, the app and its reviews stay tied to another company. This is the point most worth putting in writing before the project starts, just like the code and the data.

2. What the stores ask for besides the app

Besides the app file itself, each store wants a listing with content that someone has to prepare. The earlier it's written, the better, because it often depends on business decisions rather than technical ones.

• Name and description of the app, with the main keyword used naturally and without promising what the app doesn't do.
• Screenshots of the final version, in the sizes each store requires, with text in the languages you'll offer. In the Balearic Islands that is usually Spanish, Catalan, English and, depending on your audience, German.
• Icon and, where relevant, promotional images.
• Privacy policy at a public, reachable web address, describing what data the app collects and why.
• Data disclosure: both stores ask you to state what personal information is collected. It has to match what the app really does.
• Support contact and a page or email where users can raise problems.
• Test account: if the app requires logging in, the store reviewer needs a demo username and password to get in.

One practical detail: if the app uses the camera, location or notifications, the app itself should explain to the user why it needs them at the moment it asks for permission. It's one of the most common reasons a review gets complicated.

3. Why a store may reject an app

You don't need to memorize the rules, but it helps to know what usually holds up a review. The rules change, so check Apple's and Google's official guidelines when you're ready to publish. The most frequent reasons are common sense:

• The app crashes on opening with a different configuration from the tester's.
• The description or screenshots don't match what the app does.
• The privacy policy is missing or the permissions aren't justified.
• The reviewer can't get in because there's no test account.
• The app is little more than a website in a wrapper, with nothing that makes it worth being an app. If your case is mostly informational, a responsive website may suit you better; we compare native, hybrid and web apps in a separate article.

If you're rejected, it isn't the end of the world: the store gives a reason, you fix it and resubmit. The real risk is the calendar. That's why it pays to submit the first version with margin, not the day before a campaign, an opening or the start of the season.

4. From internal testing to real users

Before publishing to everyone, both platforms let you distribute test versions to a small group (on Apple through TestFlight; on Google through internal and closed testing in Google Play). Use them.

A sensible sequence for a first release:

1. Your own team: your people test the full flow with real data, with no customers watching.
2. A small group of trusted customers: ten or twenty people who will give honest feedback and flag what breaks.
3. Open release: only when the important bugs are fixed and the team knows how to answer the most common questions.

In the padel club example, the second group could be the most active members, who also help spread the word at the club once the app works well.

5. After publishing: the first weeks

Publishing isn't the end of the project; it's the start of maintenance. Agree in advance on:

• Who watches for crashes: a system that alerts you when the app closes unexpectedly, so you hear about it before your customers do.
• Who answers reviews and within what time. A polite reply to a complaint carries a lot of weight.
• How updates get released: every new version goes through review again, so you can't promise changes "by this afternoon".
• What happens when a new version of iOS or Android comes out: the app may need adjustments, and that work should be planned for.
• How success will be measured: downloads, active users, bookings made through the app. Three or four clear numbers are enough.

When publishing on the stores doesn't make sense

An app on the stores isn't always the best decision. You may want to wait if:

• You're still unsure what users will do inside the app that they can't do on your website.
• Nobody will handle support and reviews after launch.
• Your audience is very small and could use a private link or an installable web app.

In those cases a first version as a web app can give you real data before you take the leap. If you'd like to see how we approach this kind of project, there's more on our mobile app development service in Mallorca. And if what you need is an internal tool or a way to connect the app to your systems, see our custom software for businesses too.

The short version

• Developer accounts in your company's name, with two admins.
• Store listing prepared with final screenshots, text in the needed languages and a public privacy policy.
• A test account for the reviewer and permissions clearly explained.
• First version submitted with calendar margin.
• Internal testing and a small group before opening to the public.
• Clear owners for crashes, reviews and updates.

Let's talk about your app

If you're thinking about launching an app in Mallorca, Menorca, Ibiza or Formentera and want to reach the stores without surprises, tell us what it should do and who will use it. Email derek@dereksolutions.com or call +34 680 283 973 and we'll work out where to start.