Originally Posted by
ExplorerWannabe
They could have put a logic check in to see if the customer already had a BP and not delete the cached BP until a new BP was available but it's hard to foresee what other problems such decision logic might introduce -- especially when you think about wonky data connections. The more cases coders try to provide for, the more failure modes are potentially introduced and the more unforeseen effects.
Coming in a late to the discussion, but assuming it's a bad thing to leave a pax without a BP (I'm in the UA shouldn't have done that camp), another option they have with the app is to convert the BP to a "valid for security but not to get on the plane" pass, like you get when you check in for an international flight at home and they want to see your docs at the gate before they'll issue a real boarding pass. They could also pop an alert onto the screen when they make a major change, like "check in at gate XX before boarding".
AS doesn't spend nearly the effort on their app that UA does, and I get all kinds of messages popping up when they change things - seat change, flight cancelled, here's your new flight, we realized that was stupid and booked you a more rational replacement, etc. Coupled with location ability on the phone, they can check your location and decide on your chances of making the flight. They already have a note about using your location to tell you what to do next at the airport - they could make it useful. They do something similar with the app that FAs use to check in for work - they have to be located in the terminal when they check in on their phone. It's certainly a bunch more things that can go wrong in their implementation, and a screenshot or paper BP is still a good idea, but they already have capabilities and tools to not do what they did to the OP.