Awesome Apps

27/10/2026

05/10/2026

Do not follow where the path may lead. Go instead where there is no path and leave a trail.

04/10/2026

Here is the question that separates gym booking systems.

"A member cancels at 5:20am for a 6am class that has four people waiting. Walk me through exactly what happens, and tell me what a staff member has to do."

At 5:20am there is no someone — no front desk, nobody watching a waitlist. Either the software moves the next person in, or the spot stays empty and a member who wanted it never finds out.

We compared Mindbody, Glofox, Clubworx and Hapana on exactly that.

Worth putting in the diary as well: Australia's new unfair trading practices regime takes effect 1 July 2027 and applies to every gym with recurring memberships.

https://eawesome.com.au/blog/gym-apps-compared-on-class-booking/?utm_source=facebook&utm_medium=social&utm_campaign=wave1-2026-09-27

03/10/2026

Both app stores now require account deletion. Apple wants it inside the app; Google wants a publicly reachable web page. Both are checking that a user can ask.

The Australian Privacy Act is checking something different — whether the data actually gets destroyed once you no longer need it. An app can satisfy both stores and fail that completely.

We found it on our own app. The deletion endpoint existed. The policy page was published. Review passed. And the endpoint returned a 500 error for any user who had actually used the app, while silently leaving related records behind for the accounts where it did work.

We had also published a five-year retention period for something we only needed for three. Neither store asked.

If you have a deletion feature you have never tested with a real account that has genuine history, you do not know which of those two you have. The six-step test: https://eawesome.com.au/blog/app-store-data-deletion-compliance-australia-2026/

01/10/2026

Three different things get sold to trades as "booking".

A form that sends you an enquiry. A request against a service. A real booking against availability.

Only the third is a booking — the other two are a message you still have to answer, usually at night.

A barber can sell a 30-minute slot because the job is 30 minutes. A plumber selling a "9am Tuesday" is making a promise the day may not keep, which is why the software has to be cleverer.

We compared ServiceM8, Tradify, AroFlo and simPRO on that one question, with feature descriptions checked against vendor documentation in September 2026.

https://eawesome.com.au/blog/booking-apps-for-trades-compared/?utm_source=facebook&utm_medium=social&utm_campaign=wave1-2026-09-27

30/09/2026

If you run a venue, here is the number worth five minutes.

Take a $40 order. On a marketplace at around 30% commission you keep about $28. Ordering direct, at roughly 1.75% plus 30c, you keep about $39.

That is about $11 a transaction — and at twenty orders a week, around $11,000 a year.

Menulog stopped accepting orders on 26 November 2025, ending twenty years here, with its share down from roughly 80% in 2014 to under 25%. The market changed shape. The arithmetic behind it did not.

Use the marketplace for what it is genuinely good at, which is discovery. Then make the direct path worth using.

https://eawesome.com.au/blog/restaurant-ordering-apps-honestly-compared/?utm_source=facebook&utm_medium=social&utm_campaign=wave1-2026-09-27

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. 👇