Hacker News Reader

Comment by thebooktocome | Hacker News Reader

I don't have a product on the market so perhaps I'm being incredibly naive, but why didn't the OP throw Apple under the bus? It seems to me a better response than panicking, using up all your free support e-mails (to no avail), and etc.

View on HN

They basically did, if you look at their twitter feed: https://twitter.com/DarkSkyApp

"Any other iOS devs getting a 500 error from Apple's geocoder?"

"Still trying to figure out what the deal is with location searches. (Apple support emails cost $50 a pop. You'd think they'd respond pronto)"

"Wow, the Apple technical phone support people are the nicest support folks I've ever talked to (geolocation problem isn't fixed yet, though)"

"Been 12 hours and we still haven't heard from Apple regarding the 500 error from their geolocation service. May go entire weekend unfixed."

Telling your users that it's Apple's fault is not a solution. The app is still broken.

There isn't really anything they could do. Even if they switched to a non-Apple geocoding service, it would still take over a week to get the new version of the app approved, and by then the Apple service was working again. Such a service might even cost money, hurting their ability to keep working on the app, and might even be less reliable than Apple. Then you'll say they need to write support for multiple services, but that may not be worth it to save 3 days location search down time a year vs. some new feature users will use every day.

Rereading it, it is ambiguous, but their wording ("I awoke to a deluge of user emails alerting us to this fact, and we quickly identified the culprit: Apple’s forward geocoding service was returning a 500 error code") gave me the impression that their app does not put up an informative error message, but instead "just didn't work", thus forcing the developer to spend time to figure out what was wrong.

If my original impression is correct, there is something they could have done: code more defensively, and give precise error messages ("the server is there, but..."). It is a little thing, but it can mean the difference between a deluge and 'just' a large flow of emails.

It's even worse because iOS users tend to have far greater love for Apple than for any app. Due to the degree to which Apple has managed to get a significant fraction of their customers to tie their self-image to ownership of Apple products, blaming Apple is just going to piss a lot of them off.

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.

Reply on news.ycombinator.com