True it is not a solution but taking the fall for Apple is not good business practice either. In the spirit of full disclosure I would tell my users what was going on, point them to tweets, forum posts that showed that it was indeed Apple's issue and my brand should not take a hit for it.
Where are you guys getting the impression that Dark Skies didn't do this? I'm sure they did, but as I said it's not a solution, so it doesn't do anything to relieve the situation. Users won't be happy until the problem is resolved (and they shouldn't be.)
Ok agreed it is not a solution but since the functionality mentioned depended on the service Apple was providing, apart from telling the users that there is a problem with Apple or switching to an alternate service (not as easy as it sounds) during a crisis what other solution would you propose? Granted building a fallback into the design at the beginning would have been a better way to do things but I would forgive the OP not doing this since it is Apple they are dealing with and there is a certain expectation that your support tickets will be addressed.
> Granted building a fallback into the design at the beginning would have been a better way to do things
Notice that, that building the fallback is not building a fallback for the location API but for all the cloud based APIs that the app uses (or atleast the critical ones.) Then there is impedance mismatch between each of these APIs.
Definitely useful to do but sounds like a lot of work.
Agreed, If the fallback is using another service provider's API. I wouldn't recommend that because you then have to maintain version changes to each API. A fallback could also have been caching, slowly adding data to your own solution as users used the API so that the outage would affect some users whose queries were not cached or part of own solution. There could be more fallback strategies but I totally agree with you that using fallback APIs is not a good idea in terms of long term maintenance.
