Every pilot at this operator flies with an iPad. On it: the charting app, the flight deck app for their aircraft type and the training provider's app. When one of those apps ships a new version, somebody has to decide whether the fleet gets it, then make sure every iPad actually took it.
At this charter operator, certified under Part 135 of the United States Federal Aviation Regulations, that somebody was the outsourced IT vendor. Force Update in the mobile device management console, by hand. Then "is the fleet on the right version?" answered by assembling a list by hand.
We replaced that with a program that runs on its own and asks a human exactly once.
The one click
Every 30 minutes through the operating day, the program checks Apple's App Store for a new version of each flight-critical app. It watches three: the charting app, the aircraft manufacturer's flight deck app and the training provider's app.
When it finds one, it pushes that version to a single iPad, the one belonging to the Electronic Flight Bag (EFB) coordinator, through a separate test copy of the app. Then it opens an approval in Microsoft Teams addressed to the EFB coordinator role, not a person. Whoever holds the role that month gets the request.
Approve, and the new version goes to every pilot iPad. Reject, and it doesn't. That's the whole human part.
The window
Here's the thing about a Part 135 operation: the aircraft flies tomorrow whether or not the coordinator saw the request. So the approval has a four-hour window. If nobody answers, the update goes to the fleet anyway.
That was a deliberate call, and it's the right one. An app the vendor has stopped supporting is a bigger risk to tomorrow's flight than an app nobody test-flew this afternoon. A pilot opening a dead app at the aircraft is the outcome the window prevents.
Proving it landed
Sending a push isn't the same as the app being on the iPad. Anyone who has run a mobile device management console knows the difference.
So the program doesn't stop at the push. It reads each iPad's inventory until the installed version matches the target and the inventory is fresh, device by device. An iPad that hasn't settled after 72 hours gets its own support ticket. Every fleet push opens a ticket too, so the operator's help desk holds the audit trail without anyone typing it.
Emails go out at each step: new version found, pushed to the coordinator, approved or window lapsed. And every morning a digest lists what version each device is on. That's the report the IT vendor used to assemble by hand, and now nobody does.
Battery health in the same place
Full disclosure: the battery side is a report, not a robot.
Jamf Pro, the management console the program writes to, keeps battery health for every enrolled iPad. That's what lets the operator spot a degrading battery before it becomes a problem on a duty day, without anyone plugging in an iPad to find out. The coordinator reads it in the same console the update program lives in. Threshold alerts are the obvious next step. They aren't built yet.
What went wrong
We're not going to pretend the first version was right.
A week after going live in April 2026, an update didn't land on one pilot's iPad. Two devices sat on the old version for seven and four days before a ticket caught it. The push had been sent. Nobody was checking whether it took. That's where the device-by-device verification, the 72-hour ticket and the rest of the "proving it landed" section came from. We rewrote the core of the program that week.
In September the service account's sign-in token expired after a period of inactivity and the program went quiet. Again a ticket caught it, not the program. The fix shipped the next day: a token failure now lands in the error group as a loud, named failure, and the token is kept alive on purpose.
Two incidents in five months, both recorded, both fixed in code. We'd rather you know that than read a case study where nothing ever broke.
Results
- Three flight-critical apps across 14 pilot iPads, 17 enrolled devices in all, updated through one approval flow since April 2026.
- A new version reaches the coordinator's iPad within 30 minutes of the program noticing it and reaches the fleet on one click, or after a four-hour window.
- Every iPad verified individually after each push. One help-desk ticket per fleet push, one per device that fails to settle in 72 hours.
- One daily fleet-version report instead of a hand-assembled list.
- Battery health for every iPad in the same console, read by the coordinator.
We don't have a time-saved number for this one, and we're not going to invent it. What we have is a fleet whose apps are current without anyone holding a console password and a calendar reminder.
If your pilots' iPads get updated by whoever has the console login that week, this is the shape of the fix. If Force Update on a Friday afternoon works for you, we're not going to talk you out of it.
Benjamin Thomas
ForIT Team
