Hi, yes, we know, this is fixed already and will be available in the next update, we waited now 7 days for Apple to approve our latest release, and we are not sure why it takes so long this time, normally the approval process takes a day or two.
Can't really say why this happened, when we show that offline banner is because we detect the device without a valid internet connection, it could be connected to a network but failed to be online, so the app failed to retrieve the next booking, let's see if it was a temporary glitch as we haven't seen any other reports about this.
sent DM
Yes, the application detects 3 bounds here, LLA ARN, ARN-MIA + return. So it's treating LLA-ARN as a standalone due to the stopover (it's technically speaking not a stopover but still a layover).
Yep, I understand that. The reason is that we cache the boarding pass for quick and offline access, when we have an internet connection and a positive response from the backend we update the boarding passes, in this case, backend doesn't return the first boarding pass as we are after STD but only the second one, this explain the flickering and updating with disappearing the first BP, which is obviously not good. We are checking our logic, we should not remove a cached boarding pass unless that flight is canceled. So, we will fix this in a way or the other. Thanks for reporting this, impossible for us to replicate this use case from the office.@massimo I filed a bugreport yesterday about the boarding card after about 1 second switches to next flight when current flight is delayed and boarding is started after orgin departure time.
Irritating when the gate alarms as wrong boarding card is scanned
/ TT
Strange stuff, never got any reports like this.
