> You just install it on your phone and use the app.

Some people on the cybersecurity side are starting to cry....

I have been getting these comments often here, including concerns about my non existent backend's security.

Last time, when I pointed out that the attack surface for mobile apps is typically very small, some users started to talk about zero day vulnerabilities in the OS's media handling, as if it was a concern for my app implementation.

I found the concerns again wildly overblown.

But what if someone discovers a iOS 0day worth several million dollars and burns it to compromise your app specifically? /s

You sound like a person who's never had their app pen tested. The attack surface is anything but small if you're working with any kind of sensitive data.

Why? The api has to be secure. Mobile os keeps the app safe. Where is the attack surface?

You don’t believe how often people leave secrets in the app or use webviews and iframes badly, misconfigure OAuth in client side and so on. There are many issues where secure API does not help.

Ok, yeah, I forgot that people do ship api keys inside binaries

Are there cybersecurity concerns in the frontend? I would have thought you have to assume the client is untrusted and only do security work on the backend

1. Not storing secrets properly or using hardcoded secrets

2. Wild use of webviews/iframes sometimes easily propagates as XSS in phones

3. Incorrect client-side OAuth 2.0 configuration e.g. with schema-based redirect URLs.

4. Not supporting high-enough API versions, which may prevent some OS-related weaknesses

5. The list is actually very long. Just few top of my mind.

Fantastic answer thank you

Doing anything right on web is 10x harder and more complex. The problem is the browser, once you use it to deliver anything you have to buy into all of it’s bullshit. CORS, XSS, headers, caching. All that just goes away (outside your backend API, if you even need one) when you ship a native app

My favourite is a logout button with a logout API that fails. (Not a huge pratical concern, I admit, because it's a local attack.) Nobody ever notices because it still shows the logout screen, which hides the API error toast (if errors were even displayed). The still valid refresh token stays in sessionStorage (or even localStorage) while the app displays "logged out". (Bonus points if you cleared the access token in the error handler but not the refresh token, and on page reload you ask the user to log in again despite having a valid token.)

Or a login form that gets hidden after login, but clears the username and password only when you click "login back in". (Bonus points if the backend also enforces a 5min session timeout "for security".)

Storing private secrets in your public client is easy to avoid for anyone halfway competent. We are all professionals here.

Turn on the secrets scan in GitLab, and put in your release checklist to have the AI audit the usage of secrets in your app, and this is basically guaranteed not to occur.

I doubt current models even make such a mistake in the first place, and particularly so if you use reviews at all.

WebViews are not an inherent problem, it's the system browser embedded in your app.

Where it gets tricky is if your use case involves authentication in the browser. Together with the authentication in your app this is the one area where you need to focus on security.

The case where a SDK update is needed to prevent weaknesses of the OS seems rather unlikely.

Nailed it. Assume your client is compromised and/or malicious regardless of how it was built.

This is the most naive take on security ever. For the backend, you assume your client is compromised, but you still don't want to allow your client to be compromised.

If your clients are compromised then what's even the point of backend security. Users will login and do legitimate actions while their compromised client does whatever behind their back, while still looking normal. And the backend can't tell the difference.

They better start a proper hydration regime because they'll be crying a lot.

Same result here just using plain Opus 4.8+. I had a web ap with a PWA approach. Now I have an iOS app written in Swift/SwiftUI and an Android app in Kotlin in the appstores. I do not know how to code a single line of Swift or Kotlin. You just test the app and iterate with the AI over it until it is stable and does what it should.

> I do not know how to code a single line of Swift or Kotlin

sounds like your app is nothing serious

Why would you asume that, and how do you define serious? Ever since the iOS appstore presence I get more signups from organic app store searches + installs, which results to some percentage in new daily+monthly active users. Meaning: People use the native app and keep using it. That is how I would define have value, as it provides value to the users - else they wouldn't be using it.

My main agentic coding side project is something that I can't justify paying the apple developer license for. If I was an Android person or I didn't have to pay the developer license, maybe I'd just go for it.

Android got wirse than Apple. It costs 25 dollar now to get ID verified (mandatory) and before you can publish in the Ply store you need 12 betatester that install the app from a special link - those testers must keep the app installed 14days. Only then will you become visible publicly in the play store.

So you end up paying people on Fiverr to do it which costs more than 99€

> You just install it on your phone and use the app.

OP says they don't have an android phone...

No, they said they don't use android so don't know the native UX. You can test your app on the platform and confirm that the functionality all works, but how well it adheres to the platform's design language is subjective and hard to say if you aren't used to the platform.

Android studio has a emulator

I used the emulator - but just like I can use an iOS app for 30 seconds and tell you whether it feels native or not, I can't do the same for Android, since I'm not a daily user of Android phones.

And in the past, I didn't care because when I was manually building the app, I would just do my best with react native. But now that I can actually sweat the details (with the help of agents), I do want to hear from android users and use as many OS-native APIs and features.

I missed that.

I'd order a cheap Android phone to have a device in hand instead of working only with the simulator.

Others on our team use Android phones. So when I said that we spent the next few days actually polishing it, that's where others came in, providing feedback when they used it.

I could only sweat the details on liquid glass, etc because I'm a daily iOS user.

I am using Gemini as well as Opus on a somewhat small project in React Native and I can not imagine this thing being able to build the whole thing on its own without it being a dumbpster fire.

Can you share some details of how you work? What models? What harness?

I use Codex and Claude Code desktop apps. I generally use only the SOTA, now Astra and Fable 5.1, Opus 5 when Fable runs out.

I don't know if Gemini is suitable.

I had few issues with my native iOS app, the results are just decent after a few iterations, the models do what I ask them to do. Where do you see the problem?

The LOC for my app is now at almost 200k + 110k lines of test code.

"the models do what I ask them to do"

what the fuck are you talking about

can't believe what has become of this profession

what in the gobbledygook is this

> Opus

> Are there cybersecurity concerns in the frontend? I would have thought you have to assume the client is untrusted and only do security work on the backend.

I hate software engineering now.

We use CC with Fable(Opus before that) continuously on a rather large project, everything is tested, we maintain high verified test coverage, we ship features x10 faster than when we started(pre Claude-everything era 2-3 years ago). I never worked with RN before and I ship features now. LLMs allowed us to find issues within RN itself, that thanks to some patches, improved lower end Android experience by a lot. We just use all the Claude defaults with claude.md that evolved over last year.

> You just install it on your phone and use the app.

That‘s how you check functionality but that’s not how you get the bugs in the code.

That's the part covered by the other model's review. That together with manually verifying the functionality results in output that works.

If you don’t know the language you can’t evaluate if the models really found bugs.

That’s like translating a text to another language without knowing the language

This is wildly overblown. I've been working with agents for a good while, read tens of thousands of generated Python and the language factor is actually the part they get right that humans don't.

Do you know Python?

What do you think has more training data Python or Kotlin?

20+ years of using Python. I don't really think that lack of training data for Kotlin is a problem.

Damn, we really gotta get rid of the vibe coders. Bad things are on the horizon if we keep encouraging these naive habits.

How do you propose getting "rid" of "Vibe coders" (which I'm assuming you're pooling me into?)

Severe financial liability for security breaches, severe enough that, for instance, companies which leak 1m+ user data are driven to bankruptcy

[yes, this would also get rid of the previous generation of 1000-JS-lego vibers]

I work as a professional app developer. And I find this take to be naive.

Most of the time when I review code from AI, there is always something to improve.

It’s either a maintenance issue. e.g., Opus recommended and implemented a fix for a database corruption crash. This was ~400 lines of code with many moving parts. I reviewed, and found out Android Room library already handles this recovery case, and all I needed was a 10 liner PR that catches this exception and ignores it.

The maintenance is not only the burden on the human and LLM. With too many moving parts, it becomes harder and harder to build and verify the correctness of future features. Yes you can write test for this and that, but it didn’t need to exist in the first place.

The second problem is correctness issues. Especially the edge cases. You cannot just manually test out a race condition on a phone! Sometimes it happens! Sometimes it doesn’t! If it leads to a visible signal like a crash, then yes, you can try to reproduce it. But there are a lot of these that are “silent” and would just lead to bad experiences.

We already had a software quality crisis! And I think such views only exacerbate the situation! Quality matters!

And this is not an anti-AI stance. I vibe code personal projects where I don’t even look at the code. But when I use AI as a professional engineer, I act like a professional. Because these products do have an impact on people’s lives.

So you don't use agentic AI to develop a large mobile app and you think my take is naive?

I also used to work full time as a Android developer for five years, and I'm pretty sure I know better than you about the quality of my app that I work on everyday.

No where did I say we don’t do agentic dev!

Years of experience doesn’t mean much! I will challenge you on ideas. And the idea you are sharing is dangerous and unprofessional.

Especially at scale. e.g., we process more than 3.5 billion orders annually! This is serious business. Edge cases are common.

All true (and thanks for posting a concrete example rather than "LLMS suck"). But my take is that none of this is much different than before times when I had teams of developers creating applications. They would often make similar mistakes which I would either need to catch or which would flush out in the field. Where it seems that LLMs are not excellent is where the person driving it is also the senior domain expert so can immediately spot pitfalls. But typically using humans to develop software this was really not often the case. Those people get promoted so they're no longer cutting the code. Under that scenario (replacing subordinate humans) I find the current models are either on-par or somewhat better (specifically because the models can also act like a peer senior dev, discussing approach options etc).

I agree with you! And I’m not trying to romanticize the past! Humans/me wrote slop too.

I think we are over-indexing on speed of delivery. I think this is a mistake. The alpha is in speed and quality.

Currently, my experience is that human + AI can write software faster and with better quality than either party can do alone.

> It’s either a maintenance issue. e.g., Opus recommended and implemented a fix for a database corruption crash. This was ~400 lines of code with many moving parts. I reviewed, and found out Android Room library already handles this recovery case, and all I needed was a 10 liner PR that catches this exception and ignores it.

I understand this, but I just can't bring myself to care. I've been doing professional software work for almost two decades. These sorts of improvements/time savers are great without AI. With AI? Whatever. It's fine.

When the underlying lib has an issue, it'll be quicker to debug with the whole thing in context.

So exactly what value are you adding, then?

I take the specifications from the customer and type them into the AI

You do realize that letting the LLM produce more output means that maintenance will be more expensive? I can easily see a world where claude and gpt are producing more tokens to sell you more tokens.

This is not as obvious as many naively believe.

It depends on how hard to maintain the code added is, how likely it needs to change in the future, and most importantly on the cost.

If reviewing and manually improving the code takes hours, the cost may already be in the thousands.

That buys you a lot of AI usage, roughly a few months of continuous work.

You have to balance this with the chance that the suboptimal code the AI generated is actually fine and maintainable enough, and also the chance that during further work on that code a model might implement the same optimization on its own.

Just the other day I burned through my 5h quota twice in a row because I had opus spawn a review session on a medium sized PR and I don't know what happened but I told it to summarize to me and it said it spent 100M tokens throughout 50 subagent sessions.

And more recently its been recommending that i install this new browser called Aside. I did, and it almost felt like I was installing malware so I Uninstalled it fairly quickly (it also was not a great browser)

I feel like theres collusion somewhere.

yea man they are trying to nickle and dime you

Well yeah, that's the name of the game of most software companies. Anthropic has been fairly good up until the last week or so when it started needing more hand holding to not do things it didn't normally do.

The models will only get better and inference cost will go down.

I don’t see any reason to think the same thing that happens with all tech won’t happen here.

Enshittification and profit maximalization is around the corner looking for you.

That's just a straight shooter with upper management written all over him

One hopes you are better at that than the many others who are doing the same.

I have people skills; I am good at dealing with people.

Well then I just have to ask why can't the customers type them directly into the AI?

Funny that none of the commenters got the reference/joke

That's a recipe for regressions as the amount of surface you have to cover with "just...use the app" gets bigger and bigger.

You can write more automation to test it. But that's also how you end up with ever-growing test run times.

There are much better ways that aren't just "throw out the LLM" either. You just need to be more focused on throughput. Requiring manual validation can pretty rapidly require more hours than just sanity-checking code by hand, even (and I'm not advocating that for every use case, either.)

I can't afford manual QA passes if I'm gonna go as quickly as I want to.