Apple Developer Indifference
blog.forecast.io
blog.forecast.io
Wow, this statement is such drama.
There is no "allowance" for how many emails you can send to Apple. The Apple developer evangelist email is public and emails to it are not limited. The author is confusing emails and TSIs (Technical Support Incidents).
You can also call the developer support line, which picks up after a couple rings with a live human. And you can file bugs. And you can tweet to the developer evangelists, which may be the fastest, most effective way to get an urgent problem like this on their radar.
The two TSIs that are free with your developer account (and then cost after that, if you ever even use your first two) are for code-level support, meaning "how do I accomplish this with code." This is clearly spelled out (see https://developer.apple.com/support/technical/submit/).
They will get your question answered, if an answer is possible. Apple pulls out all the stops to get these resolved, and it's a huge misunderstanding of their purpose to use them for an outage report, and further to claim that you can only send two emails to Apple without paying.
Far from being indifferent, the Apple developer relations team is hitting it way out of the park. Yes, outages happen, and that's unfortunate. But there's no need to make something out of it that it's not.
http://developer.android.com/reference/android/location/Geoc...
https://code.google.com/p/android/issues/list?can=2&q=geocod...
I don't think that Apple would risk to lose it's developers to other platforms, they should have witnessed how Windows Mobile desperately tries to boost it's app numbers and how Android pushed hard to reach big numbers of apps for everything. Their Mac platform also suffered from "everybody supports Windows" situation.
Apple also tried to stop cross platform apps getting in the AppStore by banning apps made with 3rd party tools(I believe they rationalised it by saying that it's about the app quality but later they got less stricter on this).
So yes, Apple wants to make developers happy so that IOS platform gets the best apps but it's just hard thing to do.
However it would have been better if Apple had a competitor on the premium apps business, Google's money comes from advertisement which probably keeps them unmotivated to transform their store to more premium marketplace. If Android becomes serious money-making platform this probably would push Apple harder to solve developer problems too.
The downtime isn't the issue, it's the lack of communication during the downtime. Things go down, it's inevitable, even Google suffers outages from time to time - but we've collectively been doing this web API thing for a while now, and there's are certain best practices that should be obvious by now.
Have a status page that's up to date. Post updates to the status page. Give ETAs when you have them, or state you don't have a ETA when you don't. I shouldn't have to waste customer service resources calling or emailing someone about this - if your service is down you should know it before I do, and should keep the status page up to date as needed.
I don't think this is really about Apple's care (or lack thereof) towards their developers. This is about Apple simply sucking really hard at anything related to the web. Despite this being the year 2014 they still have to take their store offline to make major product additions. iCloud was a veritable disaster for the first year of its existence. Their Maps data is still a cruel joke. And, evidently, their core OS web APIs can go down silently with no spokesperson or page to inform anybody.
This is, IMO, the weakest point of Apple, and where Google is most able to eat their lunch. The smartphone market is maturing, and IMO the innovation forwards will be less in the hardware side (where Apple is good) and more in the software services side (where Apple is atrocious).
Like having the #1 app and music stores? I'd like to suck like that!
>Despite this being the year 2014 they still have to take their store offline to make major product additions.
I don't think that's any technical issue. That's how the want to present new products.
>Their Maps data is still a cruel joke
That are OpenStreetMap, not theirs. They just put a face on it. And its comparable with Google Maps, depending on where you live.
>And, evidently, their core OS web APIs can go down silently with no spokesperson or page to inform anybody.
Yeah, because if there was some spokeperson to tell the usual corporate BS we get from other web API vendors ("we are working to locate the problem" (well, duh), "seems to be an issue with our West Coast facilities" (well, duh), etc, it would really make a difference.
How do you access the app and music store from the web?
Besides, OP also mentions Apple Maps as an example at "Apple sucking hard on anything web related" and you can't access that from the "web" either.
The web != just the ole HTML "world wide web". We know also have native clients. We still call services with native consumers "web services" after all.
And in fact iTunes is just a glorified browser view (albeit with a custom format now IIRC, used to use plain HTML at some point).
I concur. My point was to challenge the statement about Apple not caring about it's developers. I don't defend Apple's way of handling this, there are industry standards to handle service outages, Apple should implement them.
"Have a status page that's up to date. Post updates to the status page. Give ETAs when you have them, or state you don't have a ETA when you don't. I shouldn't have to waste customer service resources calling or emailing someone about this - if your service is down you should know it before I do, and should keep the status page up to date as needed."
One you start calling it an 'industry standard' you give false authority to what is basically saying 'do what everyone else does'.
What would that communication be?
If I'm a team of sysadmins working to find out what caused the issue and trying to fix it properly as soon as I can, the last thing I want to do is being asked by some manager type "well will it be ready".
It's not as if you can tell when a bug will be found and fixed, or if some idea you try will definitely work. The only answer is: "it will be ready when it's ready".
And in fact most other answers are BS. How many time have you heard from hosting providers for example: "We had a glitch in our network, but it's fixed now" -- and the issue persists or comes back with a vengeance a few hours later?
Unfortunately I'm a little jaded by some experiences I had with Apple developers at WWDC. Last year I tried working with a dev there to set up an XCode Bot to make Ad Hoc builds. He basically said we were doing it wrong and would have to use developer signed (not Ad Hoc) builds for QA. I asked him if they had ever talked anyone outside Apple about how they do CI or QA on apps before they came up with Bots... painful silence.
Apple is a black hole.
That said if I had to develop a phone application for my company tomorrow I'd develop for iOS first and Android second.
There are good reasons for picking either platform but Apple has a single big chunk of the market which simplifies development and testing (Android has gotten better at this).
> Maybe if iOS wasn't the default platform for all the hipster developers, Apple would start giving a damn about small developers.
Nothing in this article mentioned anything about hipster developers no implied it, so apart from making you look a tad silly I'm not sure what the point of that bit was.
In addition not all small developers are hipster developers which seemed to be the implication.
Companies always provide better service to those customers who earn them the most revenue, this is not something new, try getting an engineer at Google to explain why they broke imap again if you have a dozen people using it then try if you have 10,000.
In fact prioritising such stuff by revenue is an entirely rational viewpoint when you have less than infinite resources.
Your use of the word hipster is unclear. Does that word even have a meaningful definition anymore?
[1] https://developer.android.com/about/dashboards/index.html
What apps have you developed on Android lately?
Or your opinion is just based on what you read on the internet?
Both platforms have their share of problems and neither of them is 'simpler' or 'harder'. It just the way it is.
That being said, I absolutely will deploy to iOS before Android, because that is where the market and money is. Android markets to a broad swath of people, a huge of segment of which consists of lower socioeconomic classes, and the conversion rate for purchases is lower (my experience) for the same effort (I actually find developing for Android to be slightly easier than iOS, in spite of the unfortunate choice of Java as the language, but the fragmentation issues others might throw at you by way of countering your argument are largely irrelevant for the kinds of apps I'm interested in producing). Apple product users are generally in a higher socioeconomic class and generally are more willing to part with their dollar. It just makes business sense to target that first to get revenue, then target Android to extract value.
EDIT: Don't mind downvotes, but please explain. I think this is really a huge part of the reason.
"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."
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.
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.
http://geopy.readthedocs.org/en/latest/
I used it for a personal project recently and it really easily allows you to switch between geocoders, which was useful for the edge case that Google didn't get.
> Using client-side Maps API services (JavaScript and Flash) in the browser is rate limited per map session. That means that requests are distributed across all your users and scale as the number of users grows. Therefore, client-side APIs should be always preferred and used whenever possible.
(pretend the document wasn't written for like 2007) https://developers.google.com/maps/documentation/business/ar...
Their API limits are pretty amazing for free, if you're able to distribute the load across all your clients, which on iOS is the name of the game.
I used MapQuest's free tier awhile back which didn't have the map usage restriction but was limited to 5000 queries a day, enough for what I needed but probably no where near enough for many applications.
I don't understand the connection to the geocoding problem. Did it only impact small developers? Was the problem fixed faster for large developers?
It's not like there could be any other response than "It will be fixed as soon as we can". So, what exactly were they expecting to hear?
Regarding their customers, I'm not sure if this is an American vs Europe thing, but I never, ever, contact software companies for support. Nor do I know many (if any) people that do. It's 2014. You can read the manual or search for help online. And if a service is down, you wait it out and assume it will get back up. It's not like they don't know it's down, or telling them will make it go up faster. That's just like honking while on a traffic jam. Just adds noise.
Were those users really that dependent on a $1 dollar weather app that they had to "deluge" its developers in a 3-day service disruption?
I would either wait it out, or download another comparable app.
For clients of network services, it can be useful to know details about the scope of the outage (when did it start? who is affected? are there workarounds?). Yes, during the initial investigation there is often little to say, but even just opening up a communications channel signals to your clients that you take the outage seriously. Once a root cause has been identified, it is often possible to provide an ETA on the fix, which may take hours. Again, being able to say simply "it will be fixed in N hours" and delivering on that statement shows your clients that you know what you are doing.
Three days of outage of a externally-facing service with no communication shows that it's still amateur hour at Apple as far as network services are concerned. Full disclosure: I work for another tech company that specializes in network services, among other things.
The only reply I ever really had was on an forum with "We're looking into it" and that was a few days before a fix was made
This more underlines the fact that, as others have pointed out, Dark Skies should have better fallback behavior.
Anyway, again, I agree with the underlying premise. It seems like overkill to need to have a fallback geocoding service, but I've use Geocod.io in the past and it seemed pretty cool. I have to say though, for a single application it seems like implementing 2 of every external service you use is a ridiculous thing to expect.
That's like saying deploying a service on more than one machine in different data centers in case one of them goes down is unrealistic. We've long past that and long recognized that it is not only realistic but necessary once you're on certain scale.
Are you sure you've read the article?
If you need a feature to work in the presence of down servers, you need to make your own fallback or perhaps cache some of the results locally.
I upvoted you because you make a good point about the fact that apps should handle network/service failures appropriately such that ideally it isn't a crisis but that doesn't make it an acceptable level of service.
It's not totally unreasonable to needle at Apple because there are lots of things they could do to improve developer relations, and openness about service status and reliability is clearly one of them.
On the other hand, taking it as true that they are actually indifferent takes a bizarre leap of logic, given how much effort they put into the tooling, the documentation, WWDC itself, making WWDC content available to those who can't attend, etc.
It's obvious that they are overloaded and are having problems scaling support for their developer community. It's far from obvious that they are indifferent.
[edit: downvotes - of course, because I'm not vehemently attacking Apple. Bear in mind that I don't think it's bad to needle at Apple, but I think it's only because people know that Apple does care about what developers think that it's worthwhile. Meanwhile let's not get things out of perspective.]
However, you are flat out wrong to say it's "Lazy", because that implies that they have the time and resources to devote to a more thorough handling of these cases. I'd prefer that they spend more time fixing bugs and improving the software than handholding developers.
Now this doesn't mean that I think they are doing it all perfectly. They certainly should have a service status dashboard for their backend, so that the forecast.io guys could have pointed at Apple as the culprit with authority.
There is an argument for catching a server down response and alerting the user that the third party server is down.
But end of the day apple do suck when it comes to getting a fast reply , as a enterprise customer of Apple we often feel like its worthless talking to our reps. Since outside the US no apple rep has any pull in any way.