111–120 of 211 posts
Earlier quoted context omitted.
You don't need many people to improve xcode. I bet 50 people could do miracles if anybody cares.
50 people would just have a lot of meetings. I bet 6 people could make a real difference though.
Apple works with their bug reporting system; instead of encouraging people to "sign" "letters" (on Google forms no less) - open a bug report at https://bugreport.apple.com , post the bug number and encourage people to duplicate it. This is the only way to move something at Apple.
You're joking, right?
74 signatures is hardly a blip. I would've waited for at least 5000 signatures before publishing this.
Earlier quoted context omitted.
I wish Hacker News would display both the original title and an editorialised subtitle. The first is important to capture the linked author's intent but the second is necessary for actually knowing what the link is about. You can see how it works on the Economist where there are two "titles" for each article, a catchy one and a useful one. e.g. From http://www.economist.com/printedition/2017-02-18 : Catchy / Useful -…
I've always found HN's policy of no editorializing of titles, and their insistence on original titles to be counterproductive. Quite often an excellent article will have a really generic or vague title that few people will ever read, and a judiciously edited title will interest people enough to read it. At that point, upvotes should determine whether the article lives or dies, as usual. If readers don't think the art…
"Dear Apple" or "Requests regarding XCode and Swift/ObjC" or "Developer tooling in the Apple ecosystem"
Uneditorialized titles also encourages marketing via title wording. But in general, isn't this the Facebook "link as it is" vs "how would be objectively and fairly make links better" debate?
It's absurd to have to beg the wealthiest software company in the world for what should be considered really basic stuff. Xcode is consistently unstable, slow, missing simple essential functionality (like refactoring), and Apple's interface builder is something that most experienced Apple devs know to run for the hills from.
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…
Earlier quoted context omitted.
Apple is not a big company. Out of the 116k employees they have 60k are in retail [1]. Another 6k are in AppleCare call centers [2]. So about 50k of them are at corporate. Contrast that with Google which has 72k employees [3] and Microsoft which has 120k employees [4]. Apple's organizational culture is meant to be about small teams. Steve Jobs once said "we're the biggest startup on the planet" [5]. This leads to com…
Did you seriously just try to convince me that a 50k employee (by your logic) company is not a big company?
Let's break that down across everything those 16k software engineers are responsible for:
• The OS kernels, drivers, and frameworks of macOS, iOS, watchOS, and tvOS
• The base-system software on all of those OSes, including rather involved apps like: iBooks, Safari, Mail.app, iTunes, Photos.app
• "Apps by Apple" like iWork, GarageBand, Pages/Keynote/Numbers, Final Cut Pro, Logic Pro X, iBooks Author, and, yes, Xcode
• Server.app (which adds to macOS the kind of enterprise domain-management + provisioning + MDM tooling that Windows gets in its Server releases, but also includes extra stuff like Wiki software, Xcode build-bots, and VPN management)
• Firmware + macOS drivers + Windows drivers(!) for Apple hardware (keyboards, mice, touchpads, headphones; I bought one of those MacBook USB-C multiport dongles recently and it did a firmware update, so apparently it has firmware too)
• Firmware and operating systems (usually NetBSD-derived) for "appliances" like the Airport/Time Capsule [though at least this has been dropped]
• Sponsored work on open-source projects (Webkit and LLVM being the two big ones) and standards (the Swift language; the Bonjour protocol)
• iCloud backend services: this includes the "obvious" things like the object store behind iCloud Drive and the per-app iCloud CoreData syncing servers; but also includes:
• • Apple's own maps service to back Maps.app
• • the iTunes store and App store (both in web and app form)
• • the Apple Music / "iTunes in the Cloud" sync servers
• • iCloud PIM support (mail, notes, calendars, reminders)
• • the FaceTime and Messages.app servers
• • Siri and Dictation (and you likely won't believe just how many languages Apple has built well-trained speech models for)
• • the Apple website / Apple Store + Apple Support apps
• • Xcode "development team provisioning" servers
• • webapp versions of iWork and the PIM apps (go look at icloud.com)
• • the Game Center servers
• • the iAd servers
Just stop pushing apps for iProducts. When all the major apps stop adding features for a while Apple will focus on getting developers back or customers switch to Android.
Yup, that. Vote with your keyboards. Apple writes software with the same tools and languages - if they considered this stuff a problem, they'd have fixed it by now. Besides, Apple has mechanisms for feedback, and it's not open letters on GitHub.
Yes, this letter should probably reference a bug#, but it should not be in the bug itself. And, because it's an open letter, you can go add a bug and make a PR to add it to the letter.
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…
So... they just don't know it's bad?
It's absurd to have to beg the wealthiest software company in the world for what should be considered really basic stuff. Xcode is consistently unstable, slow, missing simple essential functionality (like refactoring), and Apple's interface builder is something that most experienced Apple devs know to run for the hills from.
I've noticed this effect recently - I call it "too big to try." Once a given institution reaches a certain scale, the apparent limitations on human attention at the top of the hierarchy make it impossible for the organization to contemplate small ventures. Like the parable of Bill Gates finding a hundred-dollar bill on the sidewalk, it's no longer worth the time to stoop to pick up the small stuff. (Intuitively, this…
Earlier quoted context omitted.
Um, Google has actually worked very hard to de-couple parts of Android into separate apps, so that those apps can update without a carrier-managed total OS upgrade. This has arguably negative impacts on Android's utility as a non-Google OS, but there's no question that this strategy was to help push updates to users faster.
Making it a legal requirement, as they already do with so many others for OEMs to access Google services and the Play Store, would be the solution. No need for smoke and mirrors games regarding decoupling Android.