It wouldn't be hard.

If you can examine traffic on a network from which attacking traffic originates, you can see that it's coming from a phone.

Then you could see which app by either limiting or deleting apps one at a time, or you'd need two sources, then just see which apps the two sources have in common.

When you have 250 Gbps, it'd be simple to capture a fraction of a second's worth of traffic, then write a script to fire off emails to network admins of every IP involved and ask them to look in to it. Out of hundreds or thousands of messages, you'll get a few humans who'd look in to it and would be helpful.

I should know, because I've done this very thing.

If your nontechnical neighbour's ISP calls and says "you're participating in a DDoS, will you please find out which device behind your NAT is sending the traffic and fix whatever the problem is", do you think your neighbour can fix it in five minutes?

They could remote stop the router?

A responsible ISP will block the user but this means the user is going to call the helpdesk which costs money.

An irresponsible ISP will stall the process to see if you give up, which is free.

They could, which mitigates the attack without locating the actual source (that is, your app) and leaves you free to use the same app again for another attack next week. Maybe even taking care to use a different subset of the devices where your app is installed.

because nothing says you have to include your real ip in the src header of the ip packet if you don't care about the reply.

rp_filter (reverse path) does. Problem is it's a leaf(ish) router solution: if the src ip is not in the locally attached subnet, drop it. Not every isp sets this up though, for whatever reason.

limiting your spoofability to ips by the same isp doesn't help, especially since many will have multiple subnets so it won't help your target's ability to filter the packets out