Same reason as we've discussed before. The app isn't running. It can't check for new updates. They'd have to push the badge notification to the device and the number that they'd need to push would depend on what charts that device does and doesn't have downloaded. They'd need a big database to track all that and there could be plenty of bugs.
I dunno. Let me guess at a quick number of records here... There's what, um... Guessing here... Let's use round numbers... 300 charts including Canada, VFR, IFR, etc. Call it 500... (I'd go count but I'm being lazy.)
The next is an even bigger guess but I'll go high... 100,000 ChartCase users? (Probably way high.)
Tagging each chart with a, say... Ten character unique hash (also a guess as to how many uniques you'd need before you could re-use one... 'cause I don't want to do the math while I'm eating lunch), that's 5000 characters to transmit from the mobile device to know what charts it has installed at first, and need only transmit changes after that if the DB says it has the list.
Add some overhead since it'd probably be wise these days to stuff that into XML to make the coder's lives easier. Go crazy, call it 6000 characters to send.
As for the DB, a 100,000 by 500 record table is tiny. There'd obviously be some overhead there too, but they already have a DB of subscribers, so this is an addition of a table with 500 booleans to the existing DB. Could just stash the incoming string and post-process it later, into the booleans, too.
So 500 booleans in a referenced table against "customerID"... From a DBA perspective, that's tiny.
The challenge is the code to send the update, something to parse it on the receiving end, on the inbound side. That's cake. Much of the code stricture is already there. If you launch the App it sets a badge and knows what needs to be updated.
Just need to move that code from iOS to a central server.
All depends on how they implemented that piece as to how portable it is from iOS to say, C or Perl, or ... shudder... Python.
The heavy-hitter code would be the SQL query to compare each user against a master "current release" table, and build the badge notifications and send them. I think a modern RDBMS could easily handle the queries for that in a reasonable amount of time, the CPU burnt by the program/script could be throttled since it doesn't need to be done in near-real-time. A few hours after chart release is great. Up to a day is tolerable. And the fallback is the already existing code on the iOS side if the notification system barfs.
I don't think it's as insurmountable as it might seem on the surface. But I do understand if it's not a priority. I definitely don't think it's a "huge" database. They're storing almost as much data against my userID just to have my address info, contact info, etc. And booleans are wicked fast in any good RDBMS. Way faster than retrieving a VARCHAR with my e-mail address.
Just thoughts. I'm not complaining. It isn't *that* hard. Not quite "low-hanging fruit" either, though.
