Live data from Hacker News

Dear Apple

github.com

171–180 of 211 posts

Re: Dear Apple

#171
post #41

Earlier quoted context omitted.

Sooner or later people will wake up to the fact that this is their own fault for leveraging a proprietary ecosystem. You want to play in Apple's walled garden, you take the scraps they give you. They have no financial incentive to make the experience better for you if you're already a captive developer.

Yea, but iOS developers make twice as much as Android developers. Lots of customers love the walled garden and those customers spend a lot more on apps than Android customers do (Android installed base is multiples of iOS, yet revenues are double on iOS). And one of the reason the bigger spending customers are with Apple is the benefits of the walled garden. It's more secure, and it's updated far faster (or at all).…

> Yea, but iOS developers make twice as much as Android developers.

1) 2x mouse nuts is still mouse nuts.

2) Do they really make 2x? Especially after you deduct $100 a year?

Re: Dear Apple

#172
post #74

Earlier quoted context omitted.

Did you seriously just try to convince me that a 50k employee (by your logic) company is not a big company?

I'm not sure what flaw you found in what he wrote, or why even ask. Obviously it's not the absolute number (50k) that counts, but how it's distributed. (And those 50k are not even all programmers). If you do an OS, a mobile version of it, an embedded version of it, your own language, several huge SDKs, your own mail app, your own calendar app, you own spreadsheet, your own word processor, a TV appliance, the biggest…

A company with 50,000 employees in its corporate office(s) is huge. Saying another huge company is a bit larger and therefore this company is no longer huge is nonsense. Also, that a common range for defining "mid-sized" companies is under 1,000 employees should hint that Apple is beyond large. Here's a nice summary on how SBA and some companies classify other organizations:

http://smbresearch.net/sizing-up-smb/

Businesses with thousand or more employees are so rare as percent of the whole that they deserve their own category anyway. As in, what you say about them wouldn't apply to businesses in general and vice versa.

Re: Dear Apple

#173

Earlier quoted context omitted.

Not the grandparent, but I can share one example: Our team deploys OpenStack and is developing a custom dashboard in Rails. I'm more of a backend guy, although I also do my fair share of frontend development. But I had a ticket in my sprint, just a tiny UI bug, but I was busy in the backend, so I asked a junior dev to take care of it. He cloned the repo, then proceeded to fight with rbenv and postgres and what not on…

Replace Mac with Windows and you've got the same problem. It's the junior's fault for trying to fight the system.

The difference is that on Windows, most developers expect Unix applications to just not work. (The fine print: I can't comment on WSL.) But macOS was always sold (by other developers) as "the intuitive UI plus the power of Unix", so I'd expect to get Unix applications going with a negligible amount of yak-shaving, esp. something like Rails that is used by latte-sipping Mac hipsters across the world.

Re: Dear Apple

#174

Earlier quoted context omitted.

Also, the company with the most cash reserves.

Perhaps because they don't have huge uncofuced teams? It's not like having fewer people per project hasn't worked out for them in the one way that really matters for a company -- profit.

They have the most cash reserves because they're (a) incredibly profitable due to product demand and monopolistic practices (i.e. patent suits); (b) stockpiling cash. It's that simple. There's plenty of things they could be improving at Apple or just investing in. They're hoarding instead. They're not alone: many of the greediest, richest, and shareholder-oriented companies are doing the same thing while stagnating.

Re: Dear Apple

#175
post #164

Earlier quoted context omitted.

I'm not sure what flaw you found in what he wrote, or why even ask. Obviously it's not the absolute number (50k) that counts, but how it's distributed. (And those 50k are not even all programmers). If you do an OS, a mobile version of it, an embedded version of it, your own language, several huge SDKs, your own mail app, your own calendar app, you own spreadsheet, your own word processor, a TV appliance, the biggest…

SpaceX has 5000 employees and they design, build, launch, and LAND rockets.

A much easier feat than having to deal with retail customers in shopping malls. Physics is much more rational.

Re: Dear Apple

#176
post #115

Earlier quoted context omitted.

I remember a few years ago, at a WWDC session on Xcode, the presenter was talking about version control improvements. He said something to the extent of "Xcode has a robust version control system" and the crowd laughed. And the presenter got offended, said it "wasn't nice" of the audience to laugh considering how hard-working the Xcode team was. My recollection is blurry so it would be nice if someone else remembers…

Can someone link to a video of this session, or the title and the year WWDC was held?

I would guess "Source Control Management in Xcode", 411 from 2012: http://asciiwwdc.com/2012/sessions/411

Re: Dear Apple

#177
post #3

The one thing I'd really like to see is a more stable autocomplete. Having a decently working editor should be prioritised above everything else in my opinion.

Not only autocomplete, but syntax highlighting as well. SourceKit seems to crash with every moderately complex expression.

SourceKit crashes are caused by bugs in the Swift type checker most of the time; it's not SourceKit itself that's at fault usually. We did a lot of work to fix architectural problems in 3.1, especially with generics, and there will be more improvements in 4.0. It's definitely a priority now that the language design has settled down.

Re: Dear Apple

#178

Earlier quoted context omitted.

I develop in Xcode every day, and it's usually the least of my problems. Everything this letter asked for is an I don't care for me.

I guess you're lucky, because I fight SourceKit crashes every couple of minutes.

You can find SourceKit crash logs in Console.app; can you file a bug and attach some of them?

Re: Dear Apple

#179

Earlier quoted context omitted.

I actually picked a small number. With documentation, testing and everything you get pretty quickly to large teams. I bet less than 10 would be devs.

I was all-in with six. Three people to write the code. Two people to write the documentation and otherwise interface with the public. One person to answer all of the emails and attend all of the meetings and make sure nobody interrupts the other five people. If you have headcount for "testing" then I don't want to use your software. Tests are integral to coding and should be written first.

Do you have a publicly accessible project I could inspect how this all worked out for you?

Re: Dear Apple

#180
post #132

Earlier quoted context omitted.

As far as I've been able to tell, Apple engineers use "file a radar" to mean "I'd rather let someone else triage that, or even better yet I'd rather you get lost in the system, so here's a quest for you to go on so I can get back to work", particularly as we all know that at the end of that quest the result will be "marked as duplicate", past which point Apple refuses to give you any more information or even a follow…

That's a rather insulting comment, and it's completely wrong. Apple engineers tell you to file a radar because if it's not in radar, it won't get done . Period. Radar is the way Apple engineers track work that needs to get done, and if nobody files a radar, it can't be tracked, prioritized, assigned, and completed.

The problem is that none of that is apparent to an outsider. You can tell developers that filing radars is important until you're blue in the face, but as long as dealing with Radar from the outside is functionally identical to talking to a wall, you shouldn't be surprised when you get pushback like the parent's.

If you find that "insulting", consider how it feels to be told to go through the work of filing dozens of most-likely-duplicate reports simply because Apple won't deign to allow searching existing reports. Regardless of whatever excuses they give for that, it sends a very clear signal about how Apple values the time of third-party developers.

Post reply on HN