interaction in the entire run. If that is how security reports are handled, I would not recommend an app developed by this person.
Response: initially positive, then ghosted, then defensive
Fix: none
Code quality: entirely vibe coded
# What next?
Now that we see these apps, we're at a crossroads. What next? Well, I'll first give some recommendations to you, the user, and then to a developer who may have these issues or wish to look further at their app.
I always recommend that, no matter how much money or how little data it is, you first believe that the developer is telling the truth, is able to actually code (although this is a lot harder; check for common "vibe coding," i.e., emojis, bolded text, gradients, and other junk), how they respond, and whether it is honestly worth it. At the end of the day, I'm not here to tell you how you should spend your time or money; I can only give you tips and help you make an informed decision.
So, let's move on, shall we?
# Common failure patterns I kept seeing?
This is a TL:DR of what's posted in my blog, but,
* Trusting plain JSON from Gumroad / Lemon Squeezy / Polar or custom APIs and only checking simple flags like `success: true` or `activated: true`
* Storing critical license or trial data in UserDefaults or unprotected JSON/MessagePack files in Application Support
* Misconfigured Supabase row‑level security, allowing users to modify their own license rows or even release/update tables
* Treating a specific Keychain item’s existence as “Pro is on”, which can be faked with normal macOS tooling
Now, for those who are looking to develop or have an app that may have a flaw listed here, how can we fix it?
* Validate more than one “success” flag in JSON. Check product IDs, users, expiry, and signatures.
* Keep real license decisions on the server where possible; treat local data as a cache.
* Lock down Supabase RLS so users cannot modify license or release rows they shouldn’t touch.
* Sign or MAC cached license state on disk.
* Publish a clear way to report security issues, and respond like you actually want your app to survive.
Good examples of how to react include Resurf, How To Convert, LowTechGuys (Pipiri), InfiniDesk, Taphouse, Seam, and OS‑Engine. None of them were perfect; they just treated reports as a chance to improve, not as a personal attack.
# The end
If you wish to have your own app reviewed, you can see https://kamidevs.com/application-security. I aim to do free reviews for a developer's first app if they're a student or cannot afford one (see the 32 I just reviewed). For those who wish for a review but are unsure of pricing, discounts may apply.
I am free and open to any and all questions you might have, such as, can you give me tips on managing an app's security in Swift, or other questions, or what an app was like, expanded, i.e., you wish to know my thoughts on the app's UI/UX and security for any of the posted ones, or in general, how was your night? This post is, however, made at the time of posting, 23:50, so I will be going to bed, but you can expect a reply in 12 hours if this post wasn't mass reported or removed!
Now, this, is the end of the post, it's just a small post, on what is fully written in my blog, see that for,
* all 32 apps, names and links
* per‑app notes, ratings, and interaction summaries
* more detailed explanation of “vibe‑coded” apps
* concrete advice for better licensing and update security
Full writeup: [ https://kamidevs.com/blog/macapps-audit](https://kamidevs.com/blog/macapps-audit)
# NOTICE
If you’re a developer whose app is on the list and you think I’ve been unfair, or you want a follow-up review, contact me privately; my details are at the end of the blog or in the messages/emails I've previously sent. If you wish for a proper conversation, please send me a message on Discord. I do not like Reddit chats as it lacks functions I normally use.
https://redd.it/1ryvdei
