<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:media="http://search.yahoo.com/mrss/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/"><channel><title>App Store on Gruion</title><link>https://www.gruion.com/blog/tags/app-store/</link><description>Recent content in App Store on Gruion</description><generator>Hugo</generator><language>en</language><lastBuildDate>Thu, 01 Oct 2026 06:00:46 +0000</lastBuildDate><atom:link href="https://www.gruion.com/blog/tags/app-store/index.xml" rel="self" type="application/rss+xml"/><item><title>Shipping to both app stores costs about €120 in fees and three weeks you can't speed up</title><link>https://www.gruion.com/blog/post/2026-10-01-what-did-shipping-a-real-app-to-both-sto/</link><pubDate>Thu, 01 Oct 2026 06:00:46 +0000</pubDate><dc:creator>Gruion</dc:creator><guid>https://www.gruion.com/blog/post/2026-10-01-what-did-shipping-a-real-app-to-both-sto/</guid><description>App store fees are around €120. The real cost is about three weeks of waiting and one probable rejection. Four checks to run before you promise customers a mobile launch date.</description><content:encoded><![CDATA[<p>Every founder who asks me about mobile asks the same two questions: how many days, and how many euros. They usually expect the answer to be the build. It isn&rsquo;t. The build is the part you can control. What catches people out is the part you can&rsquo;t.</p>
<p>I&rsquo;m not going to quote you a project invoice and pretend it applies to your app. Scope changes that number too much. What I can give you is the part that barely varies from one app to the next: the store fees, the waiting, and the rejections. That is the part that surprises founders, and it is where launch dates slip.</p>
<p>The numbers, as of this writing:</p>
<ul>
<li><strong>Apple:</strong> €99 a year to publish.</li>
<li><strong>Google:</strong> a one-time $25.</li>
<li><strong>Total:</strong> roughly €120 in fees. That&rsquo;s a rounding error next to everything else.</li>
</ul>
<p>The days are another matter. Here are four checks to run before you tell a single customer &ldquo;the app is coming on the 15th.&rdquo;</p>
<h2 id="check-1-who-is-the-legal-owner-of-the-store-accounts">Check 1: Who is the legal owner of the store accounts?</h2>
<p><strong>Look at:</strong> whether the accounts are registered to you personally or to your company.</p>
<p><strong>A bad answer:</strong> &ldquo;My developer set them up on their own account.&rdquo; Now the app, the reviews and the customer data all sit under someone else&rsquo;s name. If you part ways, you are negotiating to get your own product back.</p>
<p><strong>What to do:</strong> register both accounts yourself, under the company if you have one. Apple will ask a company applicant for a business identifier called a D-U-N-S number. It&rsquo;s a free lookup, but it can take days to a few weeks to be issued or corrected. So this is day-one work, before any code.</p>
<h2 id="check-2-has-googles-testing-rule-been-planned-in">Check 2: Has Google&rsquo;s testing rule been planned in?</h2>
<p><strong>Look at:</strong> whether your Google account is personal or an organisation.</p>
<p><strong>A bad answer:</strong> you&rsquo;re on a personal account and nobody has mentioned the rule. For newer personal accounts, Google requires a closed test first. At least 12 real people must opt in and stay in the test for 14 continuous days before you can apply for public release.</p>
<p><strong>What to do:</strong> treat those 14 days as fixed. You can&rsquo;t compress them with money or a faster engineer. Recruit your testers from your existing paying customers while the app is still being built. That is the cheapest way I know to shave a week off the calendar. An organisation account avoids the rule but brings back the business-identifier wait from Check 1, so you are choosing which delay to take.</p>
<h2 id="check-3-is-your-app-more-than-a-website-in-a-frame">Check 3: Is your app more than a website in a frame?</h2>
<p><strong>Look at:</strong> what a reviewer sees in the first two minutes.</p>
<p><strong>A bad answer:</strong> the app opens your existing web product inside a wrapper, with nothing that feels native. Apple rejects apps that are really just a website, under its &ldquo;minimum functionality&rdquo; rule. It is the rejection I see most often from founders coming off no-code tools.</p>
<p><strong>What to do:</strong> ship at least a few things a website can&rsquo;t do well: notifications, a camera upload, a login that remembers you. Then say so in the review notes, in plain sentences. A reviewer who understands the app approves it faster.</p>
<h2 id="check-4-can-a-user-delete-their-account-inside-the-app">Check 4: Can a user delete their account inside the app?</h2>
<p><strong>Look at:</strong> the settings screen. Is there a working &ldquo;delete my account&rdquo; button?</p>
<p><strong>A bad answer:</strong> deleting an account means emailing support. Apple requires that if you let people create an account in the app, they can delete it from the app. Your privacy answers in the store forms also have to match what the app really collects. Founders get these wrong because they fill them in from memory.</p>
<p><strong>What to do:</strong> build the delete button, test that it actually removes the data, and have whoever built the app sign off on the privacy form answers. If you take payment for digital features inside the app, check the store commission before you set your price. The usual rate is 15–30%.</p>
<h2 id="the-one-thing-to-do-on-day-one">The one thing to do on day one</h2>
<p>Start the two slow clocks before you write any code:</p>
<ol>
<li>Register both store accounts under your company.</li>
<li>Open the Google test and recruit 12 testers as soon as there is anything installable.</li>
</ol>
<p>Here is the calendar that results when you do. A first submission usually gets an Apple answer within a day or two. First submissions get rejected often enough that I plan for one rejection, which costs about three to five days to fix and resubmit. Add the 14-day Google test and the account setup, and the store side alone runs about three weeks of elapsed time. If you start late, you pay for those weeks at the end, when everyone is already impatient.</p>
<p>The cost in euros is mostly the engineer&rsquo;s time, and the store waits add very little to it. The cost in days is the three weeks, and those are weeks nobody can buy back. I&rsquo;d rather you know that on day one than find out on day 40.</p>
<hr>
<p><strong>Product Sprint</strong> — from €12,000, 4–6 weeks. your product live in front of real users: backend, auth, payments, the AI features, CI/CD and monitoring. One platform; both web and mobile from €18,000.</p>
<p>It starts with a free product teardown: two hours on what you are building, what already exists, and what is actually blocking launch. You leave with a written plan and a realistic number, whether or not you work with us. <a href="https://www.gruion.com/#contact">Book a teardown</a> · <a href="https://www.gruion.com/services-pricing.html">What it costs</a></p>
]]></content:encoded><enclosure url="https://www.gruion.com/blog/post/2026-10-01-what-did-shipping-a-real-app-to-both-sto/cover.jpg" type="image/jpeg" length="0"/><media:content url="https://www.gruion.com/blog/post/2026-10-01-what-did-shipping-a-real-app-to-both-sto/cover.jpg" medium="image" type="image/jpeg"/><media:thumbnail url="https://www.gruion.com/blog/post/2026-10-01-what-did-shipping-a-real-app-to-both-sto/cover.jpg"/><category>Product Engineering</category></item></channel></rss>