Awesome Apps

11/09/2026

The app works, so why is there still a bill?

It is the most common question after a launch, and it has a specific answer: the app does not change, but everything around it does.

Apple releases a new iOS every September. Google Play enforces target API levels, and apps that fall behind get hidden from new downloads. Every payment gateway, booking system and login provider you connect to updates its API on its own schedule.

So the realistic timeline for an app with no maintenance budget:

0 to 12 months — works fine
12 to 18 months — minor glitches on newer devices
18 to 24 months — push notifications and logins start breaking
24 to 36 months — removed from new downloads on the Play Store

After that it is a rebuild rather than an update, and a rebuild typically costs 3 to 5 times what consistent annual maintenance would have.

The planning rule most developers use is 15 to 20% of the original build cost per year, agreed before launch rather than after the first problem.

Read the full breakdown: https://eawesome.com.au/blog/how-much-does-it-cost-to-maintain-an-app-australia-2026/

10/09/2026

Your developer says the app will not build any more, and that nobody changed anything. Both parts are true.

Apple ships new build tools every year. This year it is Xcode 26. When a build service moves to them, your app gets compiled by something stricter than last time — so the app did not change, the thing compiling it did.

Good news first. The app already in the store keeps working. Customers are unaffected. What you have lost is the ability to ship an update, which matters the moment you need one — a crash, a payment provider change, a store deadline.

What it should cost, and this is the part worth knowing:

A simple dependency pin — one to three hours.
A framework upgrade — one to three days.
An app untouched for two or three years — one to three weeks.

Same break. The difference is entirely how current the app was.

Ours was one line, and Android was never affected, because Android does not use Apple's toolchain.

Read the full guide: https://eawesome.com.au/blog/xcode-26-business-app-what-it-means-when-to-act/

09/09/2026

Your app has a delete-my-account button. That is not the same as the data being deleted.

The app stores check that a deletion path exists — Apple inside the app, Google on a public web page declared in the Play Console. The Privacy Act cares about something else entirely: whether the personal information is actually destroyed or de-identified once you no longer need it.

An app can pass both store reviews and still fail that.

We found it in our own app. The endpoint was there, the policy page was correct, review passed. The endpoint returned a 500 error for any user who had actually used the app — and where it did complete, it silently left related records behind.

So the check is not a policy review. It is a test: create an account with genuine history, delete it through the in-app path, then look in the database. Then check your analytics, email platform, CRM and error tracking, because copies you have pushed to third parties are still your obligation.

An empty account will pass a deletion test that a real one fails.

Read the full guide: https://eawesome.com.au/blog/app-store-data-deletion-compliance-australia-2026/

03/09/2026

Most app briefs arrive over-specified. Accounts, sync, notifications, a recommendation engine, social sharing, an admin dashboard.

• The whole app is four screens
• What we kept
• What we left out

Read the full post — link in the first comment. 👇

02/09/2026

The most expensive way to discover your app has no content is to finish building it first.

• The gate: three thresholds, decided before we looked
• The result
• Then we built one slice for real

Read the full post — link in the first comment. 👇

01/09/2026

Every React Native codebase has a MOCKVIEW somewhere.

• Finding M1: the placeholder that could act
• Finding M2: a fire-and-forget logout
• Finding M7: a token from the right user, for the wrong app

Read the full post — link in the first comment. 👇

27/08/2026

27/08/2026

If your app has a login screen, you've probably asked: should we implement Apple Sign-In, Google Sign-In, or both?

Disclosure: this covers products we have an affiliate relationship with. We may earn a commission if you buy through our links. It costs you nothing and it does not change what we recommend.

• The Quick Answer
• Apple Sign-In: Privacy-First Authentication
• Google OAuth: Rich User Data

Read the full post — link in the first comment. 👇

26/08/2026

Our iOS production build failed with no source change at all. Same commit, same dependencies, green one day and red the next.

The build image had moved underneath us. EAS rolled its latest tag to Xcode 26, Apple's compiler tightened one rule, and a library bundled with React Native stopped compiling as a result.

The fix was one line. The lesson is bigger: a build image tagged latest is a dependency you never pinned and never chose to upgrade, on a schedule someone else sets. If you are working to a store deadline, that is a scheduling risk worth writing down.

Read the full breakdown and the five-minute triage: https://eawesome.com.au/blog/xcode-26-fmt-consteval-react-native-build-break/

26/08/2026

Our account deletion endpoint worked for users who had never used the app, and returned an error for everyone who had.

A single bare delete statement produced two failures at once. Users with history got a foreign key violation and kept their account. Users without history got a successful delete that quietly left all their other data behind, and that is the one nobody reports, because it looks like it worked.

Both app stores and Australian Privacy Principle 11.2 care about the outcome, not whether an endpoint exists. Ours existed. It was wired to a real button with correct copy. It did not do the thing.

Read the full breakdown, including the four checks you can run on your own app this week: https://eawesome.com.au/blog/account-deletion-endpoint-500-orphaned-data/