Dear Apple(github.com)
github.com
Dear Apple
https://github.com/dear-apple/dear-apple
210 comments
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 this too.
But if that's really the attitude within Apple or the Xcode team, don't hold your breath for improvements.
Edit: changed my paraphrase of the presenter. since I remember it a little better now.
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 this too.
But if that's really the attitude within Apple or the Xcode team, don't hold your breath for improvements.
Edit: changed my paraphrase of the presenter. since I remember it a little better now.
Well gee they are working so hard so we shouldn't criticize obviously. Golly all that hard work, so nice that it exempts them from derision for their substandard product.
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
The videos from many WWDC sessions are altered. So even if you got the right session it may not have this. I've been in sessions where much less interesting this have happened that haven't made it in to the video. Also last WWDC they started pre-recording sessions so they could be up on the web sooner. Many of the video sessions from last year don't have any audience noise and differ significantly from the live session.
So... they just don't know it's bad?
I'd guess it's more like they choose to ignore it.
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 complaints about various neglected features or products and calls for Apple to hire more employees or spin off divisions so it can have dedicated resources. Just like people will always complain about the quality of service at airlines, Apple watchers will always complain about whatever pet issue they feel isn't getting enough attention. That there are complaints doesn't in and of itself mean that Apple needs to change their organizational culture. These complaints always miss the opportunity cost of the changes they suggest: that Apple is Apple because they are resource constrained.
[1] http://fortune.com/2016/01/28/apple-retail-ahrendts-employee...
[2] https://www.nytimes.com/2016/11/21/technology/how-apple-empo...
[3] https://abc.xyz/investor/pdf/20161231_alphabet_10K.pdf
[4] https://news.microsoft.com/facts-about-microsoft/
[5] https://www.youtube.com/watch?v=f60dheI4ARg
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 complaints about various neglected features or products and calls for Apple to hire more employees or spin off divisions so it can have dedicated resources. Just like people will always complain about the quality of service at airlines, Apple watchers will always complain about whatever pet issue they feel isn't getting enough attention. That there are complaints doesn't in and of itself mean that Apple needs to change their organizational culture. These complaints always miss the opportunity cost of the changes they suggest: that Apple is Apple because they are resource constrained.
[1] http://fortune.com/2016/01/28/apple-retail-ahrendts-employee...
[2] https://www.nytimes.com/2016/11/21/technology/how-apple-empo...
[3] https://abc.xyz/investor/pdf/20161231_alphabet_10K.pdf
[4] https://news.microsoft.com/facts-about-microsoft/
[5] https://www.youtube.com/watch?v=f60dheI4ARg
Did you seriously just try to convince me that a 50k employee (by your logic) company is not a big company?
This (https://www.quora.com/How-many-software-engineers-does-Apple...) says that Apple employs ~16k software engineers.
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
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
This looks like a reasonable list, however I think the overarching view is that with all of Apple resources (money, etc.) they should be able to point some of them at XCode. This may involve hiring developers or shifting priorities from other projects. Either way, it's something that most developers feel is necessary and good.
Then again, maybe this is another way of saying that Apple really doesn't care about professional programmers and their needs. Similar to the feedback around the latest MacBook Pro specifications and the lack of movement in the Mac Pro and Mac Mini machines.
Then again, maybe this is another way of saying that Apple really doesn't care about professional programmers and their needs. Similar to the feedback around the latest MacBook Pro specifications and the lack of movement in the Mac Pro and Mac Mini machines.
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 mobile app store on the planet, your own logic board and CPU designs, the biggest music store on the planet, another large desktop app store, your own DAW, your own NLE, your own compositor, your own broswer, your own javascript engine, your own AI, your own Maps, and several other things besides, then no, "50k" might not be enough.
Microsoft has 5000 programmers just for Office.
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 mobile app store on the planet, your own logic board and CPU designs, the biggest music store on the planet, another large desktop app store, your own DAW, your own NLE, your own compositor, your own broswer, your own javascript engine, your own AI, your own Maps, and several other things besides, then no, "50k" might not be enough.
Microsoft has 5000 programmers just for Office.
The flaw is that when you have 50k employees, you have much greater flexibility and resources with regard to human resources (and likely almost every other resource) to move around than a company with 200 employees.
Additionally, we are invited to "Contrast that with Google which has 72k employees". So, Google, which has almost exactly 20% more employees (after removing all retail and help center Apple employees), is supposed to be so much different, and an example of a large company? At least the comparison to Microsoft has more than a doubling of employees.
The argument that Apple works the way they do because they run their teams lean is fine, but let's not start acting like they're not a large company just because their culture is intentionally different in some aspects.
Edit: To be clear, by objection is to the premise "Apple is not a big company." which was the leading statement of the comment I replied to.
Additionally, we are invited to "Contrast that with Google which has 72k employees". So, Google, which has almost exactly 20% more employees (after removing all retail and help center Apple employees), is supposed to be so much different, and an example of a large company? At least the comparison to Microsoft has more than a doubling of employees.
The argument that Apple works the way they do because they run their teams lean is fine, but let's not start acting like they're not a large company just because their culture is intentionally different in some aspects.
Edit: To be clear, by objection is to the premise "Apple is not a big company." which was the leading statement of the comment I replied to.
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.
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.
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.
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.
I'm not sure the best way to measure and compare, but it sure seems like Apple focuses a lot more on a narrow set of products than either Microsoft or Google.
Apple might be vertically integrated to a higher degree than Microsoft and Google, but Apple doesn't have as big of product diversity.
Apple might be vertically integrated to a higher degree than Microsoft and Google, but Apple doesn't have as big of product diversity.
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.
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.
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.
Grandparent's not talking about unit tests. A good human tester can be very useful in finding the mysterious edge cases where the bugs roam, without wasting your developer's time doing the same.
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.
Yeah, if everything were synchronous, deterministic, linear, and non-interactive, life would be so much easier, and test-driven development might actually work.
Yeah, if everything were synchronous, deterministic, linear, and non-interactive, life would be so much easier, and test-driven development might actually work.
Do you use Apple software? I understand they are pretty big on manual testing.
Your process description doesn't sound anything like how I understand products are developed at Apple. Where's the headcount for the designers / UI specialists? Are you counting them as engineers?
Your process description doesn't sound anything like how I understand products are developed at Apple. Where's the headcount for the designers / UI specialists? Are you counting them as engineers?
Do you have a publicly accessible project I could inspect how this all worked out for you?
That would be a dream but I have never seen that I a large company. Every little thing gets huge overhead.
Mythical man month.
It seems like what was once their strength is now becoming a liability. They seem to be spreading themselves too thin and more and more people are complaining about more and more things. Since more customers are unhappy it seems like they either need to hire more people or cut products.
I thought they were already cutting products. Apple displays: gone. Airport: gone. Mac Mini and Mac Pro haven't had updates in so long they should be gone.
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 seems related to the absurd inflation in the cost of public works in the US over the last century.)
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 seems related to the absurd inflation in the cost of public works in the US over the last century.)
Definitely. To me, it's a symptom of control-oriented organizations, where too much information processing has to take place at the top. As a contrast, support-oriented organizations work to keep most decisions happening lower down.
It's especially frustrating here because the business case here seems pretty simple: go make these developers happy and effective. It's a known audience, they're easy to reach, they're not shy about telling you what they want. I don't think a lot of information needs to get to the top of the hierarchy.
It's especially frustrating here because the business case here seems pretty simple: go make these developers happy and effective. It's a known audience, they're easy to reach, they're not shy about telling you what they want. I don't think a lot of information needs to get to the top of the hierarchy.
Ironically, Bill Gates is probably not the best billionaire for this parable: http://community.seattletimes.nwsource.com/archive/?date=199...
That very wealth is what's insulating them from the long-term reality of the choices they're making. It's a trap!
Indeed, Apple has the high-tech equivalent of "dragon sickness", in a nod to Tolkien.
Google has a long road ahead of it, but it looks like they have the right pieces in place where I see small, incremental improvements each year, so maybe they're the tortoise. Milestones on that long road are like migrate away from Dalvik, fix business model / monetization issues with the Android marketplace, switch to vector-based canvas blitting, rationalize API support for different manufacturer-added features, and so on. What would be interesting is if they steal Apple's developer thunder by capitalizing upon open source and their in-house build system, and out-flank Apple's developer mindshare, by creating a developer-oriented ecosystem.
Imagine if you could hook up your own Docker container that Google's build infrastructure then taps to build your Android app...but all the open source your app depends upon are in their build infrastructure, with near-instant feedback on build and CI problems of the open source bits operating at a massive scale. App development shifts to a posture where open source frameworks/modules/libraries that already power a lot of software are orders of magnitude more convenient to develop under this ecosystem, and the agility/efficiency of all those Android developers coalescing around common open source components online in a single build and CI ecosystem far outstrips Apple-based developers stuck with XCode and their own person-oriented toolchains. Apple has nothing in the pipeline remotely like that kind of ecosystem. Google would also get big data-based insight into phone app development trends in real-time that Apple could only dream about. Google's phone app development OODA loop would tighten considerably smaller than Apple's.
I also wonder if Google and Microsoft could find benefits to team up to replace Dalvik with CLR, and then Microsoft Visual Studio becomes a first-class citizen on Linux for building CLR-based apps on Android.
Google has a long road ahead of it, but it looks like they have the right pieces in place where I see small, incremental improvements each year, so maybe they're the tortoise. Milestones on that long road are like migrate away from Dalvik, fix business model / monetization issues with the Android marketplace, switch to vector-based canvas blitting, rationalize API support for different manufacturer-added features, and so on. What would be interesting is if they steal Apple's developer thunder by capitalizing upon open source and their in-house build system, and out-flank Apple's developer mindshare, by creating a developer-oriented ecosystem.
Imagine if you could hook up your own Docker container that Google's build infrastructure then taps to build your Android app...but all the open source your app depends upon are in their build infrastructure, with near-instant feedback on build and CI problems of the open source bits operating at a massive scale. App development shifts to a posture where open source frameworks/modules/libraries that already power a lot of software are orders of magnitude more convenient to develop under this ecosystem, and the agility/efficiency of all those Android developers coalescing around common open source components online in a single build and CI ecosystem far outstrips Apple-based developers stuck with XCode and their own person-oriented toolchains. Apple has nothing in the pipeline remotely like that kind of ecosystem. Google would also get big data-based insight into phone app development trends in real-time that Apple could only dream about. Google's phone app development OODA loop would tighten considerably smaller than Apple's.
I also wonder if Google and Microsoft could find benefits to team up to replace Dalvik with CLR, and then Microsoft Visual Studio becomes a first-class citizen on Linux for building CLR-based apps on Android.
All of that has zero meaning given Google's reluctance to fix Android updates.
The majority of the Android users is yet to experience any of those improvements.
The majority of the Android users is yet to experience any of those improvements.
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.
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.
No need for smoke and mirrors games regarding decoupling Android.
I imagine it's not that easy to add something like this now, without huge OEM backslash. If it was there from the start, maybe it would work.
> Imagine if you could hook up your own Docker container that Google's build infrastructure then taps to build your Android app...but all the open source your app depends upon are in their build infrastructure, with near-instant feedback on build and CI problems of the open source bits operating at a massive scale.
But... why? Gradle already does a good job eliminating works-on-my-machine-isms, that sounds like cloud-for-the-sake-of-cloud.
> I also wonder if Google and Microsoft could find benefits to team up to replace Dalvik with CLR, and then Microsoft Visual Studio becomes a first-class citizen on Linux for building CLR-based apps on Android.
But... why?
But... why? Gradle already does a good job eliminating works-on-my-machine-isms, that sounds like cloud-for-the-sake-of-cloud.
> I also wonder if Google and Microsoft could find benefits to team up to replace Dalvik with CLR, and then Microsoft Visual Studio becomes a first-class citizen on Linux for building CLR-based apps on Android.
But... why?
> Gradle already does a good job eliminating works-on-my-machine-isms, that sounds like cloud-for-the-sake-of-cloud.
Github for build and continuous delivery/deployment/integration; extremely distributed build. Today an app developer pulls down the latest version of an open source library and building against it, then files any integration issues against the library's ticketing system. Google's system allows the library developer to build a version, then find everyone whose apps that use their library break because of the new proposed version. It vastly speeds up the delivery cycle and increases robustness between builds of all your dependencies and your app.
A lot of people really like the re-factoring and IntelliSense features in Visual Studio, but hate working under Windows. The new Linux compatibility push under Windows when it matures may accomplish the same as making Linux a first-class citizen in Visual Studio.
Google trying to further develop Dalvik/Android Runtime for Android seems to me eerily like Sun developing further generations of SPARC. Google would have to put up a really big war chest to continually find and address all the edge cases to sustain a process virtual machine going forward into the future, and I'm not clear where the value proposition lies in doing so, rather than settling upon an existing process virtual machine with more developers working upon it. I suspect Google does this because adopting someone else's process virtual machine, even an open sourced one, risks that someone else somehow strategically chokepointing Android development in the future with incompatible changes.
Github for build and continuous delivery/deployment/integration; extremely distributed build. Today an app developer pulls down the latest version of an open source library and building against it, then files any integration issues against the library's ticketing system. Google's system allows the library developer to build a version, then find everyone whose apps that use their library break because of the new proposed version. It vastly speeds up the delivery cycle and increases robustness between builds of all your dependencies and your app.
A lot of people really like the re-factoring and IntelliSense features in Visual Studio, but hate working under Windows. The new Linux compatibility push under Windows when it matures may accomplish the same as making Linux a first-class citizen in Visual Studio.
Google trying to further develop Dalvik/Android Runtime for Android seems to me eerily like Sun developing further generations of SPARC. Google would have to put up a really big war chest to continually find and address all the edge cases to sustain a process virtual machine going forward into the future, and I'm not clear where the value proposition lies in doing so, rather than settling upon an existing process virtual machine with more developers working upon it. I suspect Google does this because adopting someone else's process virtual machine, even an open sourced one, risks that someone else somehow strategically chokepointing Android development in the future with incompatible changes.
> Google's system allows the library developer to build a version, then find everyone whose apps that use their library break because of the new proposed version.
That assumes that library authors can see the code of dependent applications. Ehhh...
> It vastly speeds up the delivery cycle and increases robustness between builds of all your dependencies and your app.
Presumably by breaking repeatable builds? I certainly don't want it to replace libraries without my knowledge, and that's the only part where I can see it possible "speeding up the delivery cycle".
Oh, yeah, Gradle can do that anyway with -SNAPSHOT dependencies.
> A lot of people really like the re-factoring and IntelliSense features in Visual Studio, but hate working under Windows. The new Linux compatibility push under Windows when it matures may accomplish the same as making Linux a first-class citizen in Visual Studio.
Tried IntelliJ/Android Studio? Especially considering that ReSharper, which is more or less a port of IJ's refactoring, is usually considered a must-have add-on for VS.
> Google trying to further develop Dalvik/Android Runtime for Android seems to me eerily like Sun developing further generations of SPARC. Google would have to put up a really big war chest to continually find and address all the edge cases to sustain a process virtual machine going forward into the future, and I'm not clear where the value proposition lies in doing so, rather than settling upon an existing process virtual machine with more developers working upon it.
Sounds like migrating to OpenJDK would be a much more reasonable path in that case, since it wouldn't mean starting over in third-party application support.
That assumes that library authors can see the code of dependent applications. Ehhh...
> It vastly speeds up the delivery cycle and increases robustness between builds of all your dependencies and your app.
Presumably by breaking repeatable builds? I certainly don't want it to replace libraries without my knowledge, and that's the only part where I can see it possible "speeding up the delivery cycle".
Oh, yeah, Gradle can do that anyway with -SNAPSHOT dependencies.
> A lot of people really like the re-factoring and IntelliSense features in Visual Studio, but hate working under Windows. The new Linux compatibility push under Windows when it matures may accomplish the same as making Linux a first-class citizen in Visual Studio.
Tried IntelliJ/Android Studio? Especially considering that ReSharper, which is more or less a port of IJ's refactoring, is usually considered a must-have add-on for VS.
> Google trying to further develop Dalvik/Android Runtime for Android seems to me eerily like Sun developing further generations of SPARC. Google would have to put up a really big war chest to continually find and address all the edge cases to sustain a process virtual machine going forward into the future, and I'm not clear where the value proposition lies in doing so, rather than settling upon an existing process virtual machine with more developers working upon it.
Sounds like migrating to OpenJDK would be a much more reasonable path in that case, since it wouldn't mean starting over in third-party application support.
>That very wealth is what's insulating them from the long-term reality of the choices they're making. It's a trap!
What "long term reality"? They have been doing this when they were near bankrupt and continue to this day, 20 years later, and they are now the richest company on the planet.
Maybe the long term reality is actually success?
What "long term reality"? They have been doing this when they were near bankrupt and continue to this day, 20 years later, and they are now the richest company on the planet.
Maybe the long term reality is actually success?
The one that's been getting me lately is the split between Xcode 7/Swift 2.2 and 8/3. We have an older project in Swift 2 (yes, it's slated to get changed over, just not yet), and new work on a project in 3. If I try to open one while the other is already open, one of the Xcodes invariably freezes or crashes.
I will say, though, that I've always liked IB (though not storyboards). But then there's the wonderful "Oh, you opened a nib, I should move something around in the XML." -> SCM status changes even though I didn't modify the file.
I will say, though, that I've always liked IB (though not storyboards). But then there's the wonderful "Oh, you opened a nib, I should move something around in the XML." -> SCM status changes even though I didn't modify the file.
Can you still submit apps with Xcode 7?
In response to your problem, having done the Xcode Old/Xcode New dance every year since 2012, I got into the habit of making sure they are never running concurrently. Things get even worse if you run xcodebuild on the command line while a different UI version is running.
In response to your problem, having done the Xcode Old/Xcode New dance every year since 2012, I got into the habit of making sure they are never running concurrently. Things get even worse if you run xcodebuild on the command line while a different UI version is running.
You can't run multiple versions of Xcode concurrently due to CoreSimulator fighting over which version gets to run. This is a limitation we are aware of. We are also very aware of the problems it causes.
As for other problems, please file radars and respond to requests for additional information. I have been on the external side of radar, I know it can be frustrating, but we do read them and we do take direct action based on them. Even duplicates are very useful.
As for other problems, please file radars and respond to requests for additional information. I have been on the external side of radar, I know it can be frustrating, but we do read them and we do take direct action based on them. Even duplicates are very useful.
What? I have very little problem running Xcode 7 and Xcode 8 along side each other. As long as you close the simulator before running from the other version.
Only one CoreSimulator service can be running at a time because only one can be in control of the devices and the database. If you try to keep two versions of the tools open they'll keep killing each other's CoreSimulator or one will get stuck with the wrong incompatible version.
CoreSimulator is used during builds and for IB's accurate rendering feature. Instruments and Console open connections to CoreSimulator for various purposes. A lot of things can break.
CoreSimulator is used during builds and for IB's accurate rendering feature. Instruments and Console open connections to CoreSimulator for various purposes. A lot of things can break.
I've found having IB open in both versions will eventually lead to errors in IB, if not outright crashes.
> Can you still submit apps with Xcode 7?
...yes. You can. 6 is the minimum.
> having done the Xcode Old/Xcode New dance every year
There didn't used to be this hard division between Xcode versions because of the compiler. If you were willing to do some reconfiguring, you could use newer GCC or "Apple LLVM" with the older Xcode.
...yes. You can. 6 is the minimum.
> having done the Xcode Old/Xcode New dance every year
There didn't used to be this hard division between Xcode versions because of the compiler. If you were willing to do some reconfiguring, you could use newer GCC or "Apple LLVM" with the older Xcode.
Why are you not using the Swift 2.3 option in Xcode 8? It is going away in Xcode 8.3, but still, you can use more modern and stable dev tools.
I'm not sure why it hasn't been done yet; I've only been on the team for two months now. That would indeed be lovely. But the plan is to have one of our contractors move the entire project up to Swift 3. I don't know exactly when, though...
The OP mentioned Swift 2, not Swift 2.2 - even that upgrade can be non-trivial (2->2.2).
Eh, it is indeed 2.2, sorry for the imprecision. But yes, the concern is the time for the transition. Planned. We just have to fit it in.
The file changing just from being looked at is one of the basic reasons that IB is bad. Apple made a grievous mistake in designing UI markup that is intended to be hidden from developers. Un-organizable, un-diffable toxic sludge.
It boils down to budget. The app ecosystem simply isn't a high priority because it makes little to no money relative to Apple's core business. Matter of fact the best thing they did was introduce ads to app search, at least now they're probably making a few more bucks.
They invest most of their resources into hardware and critical software. Everything else clearly is secondary.
It doesnt take much to form this opinion either, just look at the quality of their software overall. Very inconsistent, trending towards mostly stable. Design improves which is good I guess but not what developers need.
They don't make a ton of money from independent developers and it doesn't matter anyway because most of the heavily used apps are created by Apple themselves.
They invest most of their resources into hardware and critical software. Everything else clearly is secondary.
It doesnt take much to form this opinion either, just look at the quality of their software overall. Very inconsistent, trending towards mostly stable. Design improves which is good I guess but not what developers need.
They don't make a ton of money from independent developers and it doesn't matter anyway because most of the heavily used apps are created by Apple themselves.
I'm only just getting into Apple development, and the course is using XCode and the interface builder. Could you tell my why I should avoid it and what approach to take instead? Or is it fine or even preferable to use it in the 'learning phase'?
Apple should start asking their software engineering candidates to invert red-black trees in interviews. I hear that makes these kinds of issues unlikely.
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.
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). For developers it's a better environment to develop for, consistent screen sizes and hardware features and I know I can write my latest app for the latest iOS and within months of it's release the vast majority of revenue producing customers will be on it. That's a big reason why better apps are written on iOS first, it's easier.
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). For developers it's a better environment to develop for, consistent screen sizes and hardware features and I know I can write my latest app for the latest iOS and within months of it's release the vast majority of revenue producing customers will be on it. That's a big reason why better apps are written on iOS first, it's easier.
> 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?
1) 2x mouse nuts is still mouse nuts.
2) Do they really make 2x? Especially after you deduct $100 a year?
$100 is peanuts to anyone actually earning money, and it's definitely peanuts compared to developer cost.
Except that I seem to remember a statistic like 95% of the iOS apps don't actually make enough to cover that annual fee.
If they didn't make $100, then it wasn't worth their time developing the app either, even without that fee.
Wow, it's that bad for developers of their own platform? I do rails development and left OSX for linux a few years ago after finding all the custom song & dance to do things on apple was painful. Not a day goes by I am not grateful for doing that, i am much happier doing web dev on a linux box.
But I was under the impression Apple at least took care of the devs who work on their platforms.
As someone else has noted: vote with your keyboard. I do ROR web development in part because I am free of many of the constraints other devs must face on custom platforms.
If you don't like doing dev with Apple, don't do dev with Apple. Either pick better tooling (if available) or ditch the platform (if possible).
But I was under the impression Apple at least took care of the devs who work on their platforms.
As someone else has noted: vote with your keyboard. I do ROR web development in part because I am free of many of the constraints other devs must face on custom platforms.
If you don't like doing dev with Apple, don't do dev with Apple. Either pick better tooling (if available) or ditch the platform (if possible).
The tooling is a lot worse in swift land than objective-c land. In Obj-C land compiles are fast, the debugger works and is stable and the indexer works just fine.
The entire pbxproj format is horrible, but at least you have stuff like BUCK (https://buckbuild.com/) that can mitigate some of that.
Another thing I would add to that letter are good build boxes. Bring back xserve, so we have CI that is not based on mac pros or mac minis.
Android devs, even though they have build tooling options with java, have other problems that make developing on their platform painful. Their simulators are bad compared to iOS, the fragmentation / lack of updates is pretty annoying and overall it's harder to deliver good equivalent android apps than it is for iOS. iOS as a software platform is actually pretty solid.
What do you use to develop on? Any specific laptop or is it a desktop?
The entire pbxproj format is horrible, but at least you have stuff like BUCK (https://buckbuild.com/) that can mitigate some of that.
Another thing I would add to that letter are good build boxes. Bring back xserve, so we have CI that is not based on mac pros or mac minis.
Android devs, even though they have build tooling options with java, have other problems that make developing on their platform painful. Their simulators are bad compared to iOS, the fragmentation / lack of updates is pretty annoying and overall it's harder to deliver good equivalent android apps than it is for iOS. iOS as a software platform is actually pretty solid.
What do you use to develop on? Any specific laptop or is it a desktop?
> The entire pbxproj format is horrible, but at least you have stuff like BUCK (https://buckbuild.com/) that can mitigate some of that.
FWIW I'm still not sure what the BUCK workflow is suppose to look like for most teams. It seems like if you use BUCK you're expected to not use Xcode even as an editor, yet there isn't another editor to pick up the slack (assuming you want autocompletion and decent highlighting). I think there's still a lot of work to be done for it to be a viable replacement, even for Objective-C, for Swift it's even further away.
FWIW I'm still not sure what the BUCK workflow is suppose to look like for most teams. It seems like if you use BUCK you're expected to not use Xcode even as an editor, yet there isn't another editor to pick up the slack (assuming you want autocompletion and decent highlighting). I think there's still a lot of work to be done for it to be a viable replacement, even for Objective-C, for Swift it's even further away.
Can you give some examples of advantages of doing ROR development on Linux vs Mac?
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 his Mac for a full 2 days, until he gave up and spun up a Linux VM on OpenStack to work on the Rails app in there. Sure enough, he got up and running in there in under an hour.
Shit like this is why I do all my development in a VirtualBox with Arch Linux. While my co-workers argue about the best way to install Docker on their Macs, I just `pacman -S docker && systemctl start docker` and get on with my life.
Shit like this is why I do all my development in a VirtualBox with Arch Linux. While my co-workers argue about the best way to install Docker on their Macs, I just `pacman -S docker && systemctl start docker` and get on with my life.
He likely had some old Macports or whatever binaries lying around in his $PATH (it was that for me the last time some libs didn't compile). Would Linux be immune to that, if you had 2 concurrent pkg managers?
You could probably run vanilla macOS in a VM without running into any problems.
You could probably run vanilla macOS in a VM without running into any problems.
> He likely had some old Macports or whatever binaries lying around in his $PATH (it was that for me the last time some libs didn't compile).
He only ever used Homebrew as far as I know.
> Would Linux be immune to that, if you had 2 concurrent pkg managers?
How would that ever happen?
He only ever used Homebrew as far as I know.
> Would Linux be immune to that, if you had 2 concurrent pkg managers?
How would that ever happen?
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.
Not a RoR dev but I imagine his deployment environment is also linux, and many of the tools he uses likely run better on Linux (as OSS usually targets linux first). Correct me if I'm wrong but Docker for example, although I think they brought parity recently, was always easier to get going on Linux then Mac.
Docker is, in fact, impossible to get going on Mac OS. When you see "Docker for Mac", it's launching a Linux VM under the hood, and patching you through to that VM's Docker daemon.
Is that still the case? If so, that's crazy - as bad as the old Windows installs with vbox. However that being said, if that is still the case, they must have a wrapper on top of it since I didn't notice much of a difference at all between OSX docker usage and Ubuntu.
It's not crazy, it's kinda hard to implement containerisation yourself in a proprietary OS kernel that you don't control...
However, as of fairly recently, IIUC Docker for Mac uses macOS's native hypervisor framework rather than relying on VirtualBox as it used to.
However, as of fairly recently, IIUC Docker for Mac uses macOS's native hypervisor framework rather than relying on VirtualBox as it used to.
doing dev in linux, the commands you run locally are the same ones you run in production. You install the same packages and control them in the same manner. I'm more comfortable in production because production is very similar to my local machine.
my dev machine is a VM, which gives me a ton of other benefits, like portability, resizability, backups, versioning, and overall stability. I can (and have) given devs my VM to get up and running immediately on a complex project, without having to do a lot of setup.
With each OSX update, usually stuff broke, needed to be reinstalled, or performed differently. With Linux, that is not the case. And with a linux VM, I can ride out host upgrades and keep plugging away with a machine i know works - or attempt an upgrade on a cloned VM and have a trivial way to backtrack if it fails.
my dev machine is a VM, which gives me a ton of other benefits, like portability, resizability, backups, versioning, and overall stability. I can (and have) given devs my VM to get up and running immediately on a complex project, without having to do a lot of setup.
With each OSX update, usually stuff broke, needed to be reinstalled, or performed differently. With Linux, that is not the case. And with a linux VM, I can ride out host upgrades and keep plugging away with a machine i know works - or attempt an upgrade on a cloned VM and have a trivial way to backtrack if it fails.
I'm not the original commentor but a better package manager has got to be in that list.
Why isn't brew good enough?
Homebrew is rather limited in what it can control, i.e. in Linux almost everything is under the control of your package manager, there's no tracking, updates roll faster if you're on something like Arch and the overall user interface makes more sense.
I've also found that homebrew packages sometimes don't contain the necessary header files for development, (i.e. imagemagick), so you're forced to switch to MacPorts just for that and it's altogether more painful than on Linux.
It also simply just doesn't feel like a lot of the tools target macOS, there's an outdated bash shipped by default and Apple even broke curl recently[1].
1 - https://daniel.haxx.se/blog/2016/10/11/poll-on-mac-10-12-is-...
I've also found that homebrew packages sometimes don't contain the necessary header files for development, (i.e. imagemagick), so you're forced to switch to MacPorts just for that and it's altogether more painful than on Linux.
It also simply just doesn't feel like a lot of the tools target macOS, there's an outdated bash shipped by default and Apple even broke curl recently[1].
1 - https://daniel.haxx.se/blog/2016/10/11/poll-on-mac-10-12-is-...
Have you checked /usr/local/Cellar/imagemagick/7.0.4-10/include/ImageMagick-7/MagickCore/ ?
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?
No, I am completely serious. This is how things work in big organizations.
I worked at Apple for many years, and I'm very aware of how Radar was used internally during my tenure. You're absolutely correct that Radar is taken very seriously at Apple. I won't go into detail, but what we see externally at bugreport.apple.com is almost nothing like the real thing.
It was a big mistake for Apple to ask outside developers to use a bug tracking tool that purports to be a user interface into Radar. I would much prefer a ticket system like those used at other companies. If Apple engineers triage a ticket and decide to open a Radar, that process should be opaque to the outside world.
Once Developer Relations made the decision to allow outside developers to create bug reports, Apple should have given us a modern, full-featured web interface. Instead, they gave us the ridiculous, brain-dead tool that you see at bugreport.apple.com, which looks like it was designed by an incompetent Cobol programmer (apologies to Grace Hopper).
It was a big mistake for Apple to ask outside developers to use a bug tracking tool that purports to be a user interface into Radar. I would much prefer a ticket system like those used at other companies. If Apple engineers triage a ticket and decide to open a Radar, that process should be opaque to the outside world.
Once Developer Relations made the decision to allow outside developers to create bug reports, Apple should have given us a modern, full-featured web interface. Instead, they gave us the ridiculous, brain-dead tool that you see at bugreport.apple.com, which looks like it was designed by an incompetent Cobol programmer (apologies to Grace Hopper).
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-up. I would honestly rather there just be an e-mail address [email protected] to which I could shoot off random issues I run into, from which I know I'd get no response, than Radar.
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.
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.
> The problem is that none of that is apparent to an outsider.
What exactly isn't apparent? How Radar is the way things get done and you need to file a Radar if you want anything fixed? I'd think that's crystal clear given that every single Apple engineer you talk to will explain this to you.
What exactly isn't apparent? How Radar is the way things get done and you need to file a Radar if you want anything fixed? I'd think that's crystal clear given that every single Apple engineer you talk to will explain this to you.
Is it the best tool in the world? No. Is it the only actual tool to communicate bugs and enhancement requests to Apple? Almost. We've all used issue tracking software to add to backlog ("Open a Jira and I'll take a look when I have time"). Doesn't mean it's not being looked at.
I made a conscious decision a while back to simply use a Linux distro (Ubuntu) with easily/cheaply-available commodity hardware for programming. Correct me if I'm wrong but other than iOS development, there isn't anything I can't do on Ubuntu with a 2010-ish laptop that I can do with a 2016-ish Macbook.
In my personal experience, with everything else being equal, iOS development yields on average 6x more income than Android development. I haven't found a decent alternative, yet.
Which is why I feel for a lot of us who don't own Macbooks, it's a major sticking point, and you get a lot of people trying out "Hackintoshes" (which I don't really have much of an opinion on).
I just wish Apple had taken the Google route and made development a lot more open, not sure what they stand to gain by keeping even iOS development a walled garden but hey it's their platform to do with as they please.
I just wish Apple had taken the Google route and made development a lot more open, not sure what they stand to gain by keeping even iOS development a walled garden but hey it's their platform to do with as they please.
And they have every right to build a paywall and make the developers pay for it.
The only redeeming Apple product I found is the mac mini which gives low-budget developers an easy access to their expensive platform.
The only redeeming Apple product I found is the mac mini which gives low-budget developers an easy access to their expensive platform.
Battery life. Battery life sucks on linux, on the same machine it's worse than Windows or OSX. Plus a 2010-era laptop didn't have good battery specs (in comparison to 2016) and that battery is now 6-7 years old.
For programming yes, but there are some pretty neat tools for web designers such as sketch.app and tons of prototyping software.
iTunes.
Subnautica.
That's about it.
Subnautica.
That's about it.
Ableton Live.
Bitwig[1] is a decent commercial DAW that works on Linux and is very similar to Ableton.
1. https://www.bitwig.com/en/bitwig-studio.html
Edit: Not sure about the state of Linux VST plugins/emulation though :)
1. https://www.bitwig.com/en/bitwig-studio.html
Edit: Not sure about the state of Linux VST plugins/emulation though :)
There's also Reaper[1], from the guy who made Winamp, that has a Linux version in testing[2].
And in many cases, Ardour[3], may be good enough.
1 - http://reaper.fm
2 - http://landoleet.org/dev
3 - http://ardour.org
And in many cases, Ardour[3], may be good enough.
1 - http://reaper.fm
2 - http://landoleet.org/dev
3 - http://ardour.org
As a developer who moved from Java and JavaScript (IntelliJ IDEA) to Swift and Xcode about a year ago, the experience has been horrendous. How is it okay for a company as big and serious as Apple to have an IDE and tooling as bad as Xcode? The IDE frequently crashes, there is no refactoring support at all, practically non-existant code completion, syntax highlightning frequently stops working, etc etc.
I've been using Xcode for many, many years now. In the past (~8+ years ago) I've used Visual Studio.
From my perspective Xcode is a really nice IDE. I prefer the lean UI compared to Visual Studio and Xamarin. The only thing that annoys me is that since Swift the syntax colouring and autocompletion breaks multiple times a day. This is a slight annoyance for me, but otherwise I personally think it's a decent IDE.
I don't experience the crashes like you do. And I've never really used much refactoring tools in the past, so I guess I don't know what I am missing out on.
But you might want to consider AppCode from Jetbrains. Apparently it supports both Objective-C and Swift and it's refactoring support -at least- should be good.
From my perspective Xcode is a really nice IDE. I prefer the lean UI compared to Visual Studio and Xamarin. The only thing that annoys me is that since Swift the syntax colouring and autocompletion breaks multiple times a day. This is a slight annoyance for me, but otherwise I personally think it's a decent IDE.
I don't experience the crashes like you do. And I've never really used much refactoring tools in the past, so I guess I don't know what I am missing out on.
But you might want to consider AppCode from Jetbrains. Apparently it supports both Objective-C and Swift and it's refactoring support -at least- should be good.
Yup, I agree. I think Xcode is not bad at all. I wouldn't call it great, but it's good enough. I get a hard crash every couple of weeks. Autocompletion breaks maybe 2 times a week, and this month, I haven't seen syntax colouring break.
It used to be worse, of course. Especially in Swift 1.x and 2.0.
It used to be worse, of course. Especially in Swift 1.x and 2.0.
What's worse... the refactor functionality for renaming used to be great, but when swift came along it stopped working for Objective-C as well...
> the refactor functionality for renaming used to be great
Objective-C did have some basic tools. But even Eclipse was better?
You can always use AppCode, I believe it has the usual JetBrains level of refactoring. I have a copy paid and installed yet I almost never use it.
Objective-C did have some basic tools. But even Eclipse was better?
You can always use AppCode, I believe it has the usual JetBrains level of refactoring. I have a copy paid and installed yet I almost never use it.
I can confirm, Appcode is good enough. Annoyingly, they don't manage to get font rendering to be the same as in Xcode, and that's a bigger issue for me than it should.
@dang Can you add the repo name to Github URLs that point to repos? For example, display the title as "Dear Apple (github.com/dear-apple/dear-apple)".
I thought this was a letter from Github to Apple, but was disappointed to discover that it was a letter from some subset of the Apple developer community.
I recognize that this is sort of pulling at a thread, but since Github is so widely used, perhaps some sort of exception can be made?
I thought this was a letter from Github to Apple, but was disappointed to discover that it was a letter from some subset of the Apple developer community.
I recognize that this is sort of pulling at a thread, but since Github is so widely used, perhaps some sort of exception can be made?
These letters always come off as sounding immature. The open letter, the why I quit, the why I switch letters all do. It is as if you need validation for something.
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?
Sure, I'll have a look and file some bugs.
That's a losing mindset.
I don't think the letter goes far enough.
If Apple is doing something you don't like, put pressure on them. A better strategy than OP's would be to go to greater lengths, like labeling Apple "anti-developer" (the same way Trump uses labels against his opponents), but too many here are too scrupulous and rationally-minded to do this. The basic fact is, the tactics you need to use in a philosophical debate and the tactics you need to use to effect change are different, and, to be effective, you need to be a bit radical and a loose-cannon. Activists who insist on being factual, moderate or respectful, lose. That includes political activists, union leaders, as well as anybody that wants to change corporate behavior or policy as is the case here.
I don't think the letter goes far enough.
If Apple is doing something you don't like, put pressure on them. A better strategy than OP's would be to go to greater lengths, like labeling Apple "anti-developer" (the same way Trump uses labels against his opponents), but too many here are too scrupulous and rationally-minded to do this. The basic fact is, the tactics you need to use in a philosophical debate and the tactics you need to use to effect change are different, and, to be effective, you need to be a bit radical and a loose-cannon. Activists who insist on being factual, moderate or respectful, lose. That includes political activists, union leaders, as well as anybody that wants to change corporate behavior or policy as is the case here.
To expand on this:
Unions are an old-school idea. But unions won't work to protect iOS developers from Apple.
So why doesn't someone build up a brand, blog, or platform as a "developer's advocate"? A Twitter account, speaking on behalf of 100k followers, has leverage influence, and power. They can represent people, organize communities discussing developers' issues, and speak out with a single voice. Why does nobody do this? It's easier for Apple to ignore 100k individuals than for them to ignore 1 organization with 100k followers. The latter will get much wider media coverage.
Social media empowered mobs, why not use that for good?
Unions are an old-school idea. But unions won't work to protect iOS developers from Apple.
So why doesn't someone build up a brand, blog, or platform as a "developer's advocate"? A Twitter account, speaking on behalf of 100k followers, has leverage influence, and power. They can represent people, organize communities discussing developers' issues, and speak out with a single voice. Why does nobody do this? It's easier for Apple to ignore 100k individuals than for them to ignore 1 organization with 100k followers. The latter will get much wider media coverage.
Social media empowered mobs, why not use that for good?
Validation is exactly why 'these letters' can be useful and even necessary. Nobody cares if a lone developer complains, but if he find enough validation (through letters or as others here say, filing a bug report), it very well might make a difference.
I'm honestly curious what makes it sound immature though. Could you elaborate?
I'm honestly curious what makes it sound immature though. Could you elaborate?
Everything posted on the internet is like that.
While I have slightly despised Xcode ever since 4.x when they integrated Interface Builder and everything else unnecessarily into one buggy app, it has only been completely broken for me with the latest version. “Something” makes typing s...l...o...w......a...s......h...e...l...l... and I have never figured out what. The editor became utterly unusable no matter the project and I was forced to do every change outside of Xcode.
I am very thankful that they at least had the wisdom to expose "xcodebuild", etc. as command-line tools, because I have always set up my primary build to rely only on the commands. (Even when “building” from Xcode, the build that I click runs "make" underneath with xcodebuild.) That way, I never need to be in the GUI and can work around its quirks or bugs that make it unusable, which has paid many dividends.
I am very thankful that they at least had the wisdom to expose "xcodebuild", etc. as command-line tools, because I have always set up my primary build to rely only on the commands. (Even when “building” from Xcode, the build that I click runs "make" underneath with xcodebuild.) That way, I never need to be in the GUI and can work around its quirks or bugs that make it unusable, which has paid many dividends.
I've given up on App store development. I wrote a handful of moderately successful apps in the 2009-2012 range, but the market is too crowded and the expectation of free, or near free software isn't profitable for the small team of "just me."
They do fascinating work though. Making a living with Microsoft technology at my day job(s) for two decades, Apple stuff was a refreshing change.
They do fascinating work though. Making a living with Microsoft technology at my day job(s) for two decades, Apple stuff was a refreshing change.
The best way to build native iOS applications is in Visual Studio with Xamarin IMHO.
It pulls in the UI designer from XCode, and you get all of the advantages of Visual Studio which is hands-down just a better IDE than XCode.
It pulls in the UI designer from XCode, and you get all of the advantages of Visual Studio which is hands-down just a better IDE than XCode.
Yeah :/... I do not understand, nor have any sympathy for, all these people who insist upon using Xcode even though we all know how bad it is... there are so many alternative toolsets you can use, including just vim+git+make, that are just so much more stable and easier to customize to get the optimal testing workflow, that to sit around and smash your head against Xcode over and over again while constantly complaining to Apple, as if that is really going to help, makes no sense at all :/.
> I do not understand, nor have any sympathy for, all these people who insist upon using Xcode
> there are so many alternative toolsets you can use
Actually no, if you want the latest, most supported tools, frameworks APIs etc. you have to use Xcode.
Most of us don't want to use Xcode, but we also don't want to use C#, (Swift is actually very nice), which IS NOT a native solution.
> there are so many alternative toolsets you can use
Actually no, if you want the latest, most supported tools, frameworks APIs etc. you have to use Xcode.
Most of us don't want to use Xcode, but we also don't want to use C#, (Swift is actually very nice), which IS NOT a native solution.
How does one define `native`? To me, native is using the platform API's exactly - 1:1 - with zero abstractions. With Xamarin you do exactly that, in either csharp or fsharp. When using Xamarin a UIViewcontroller still is a UIViewController, you'll be directly interacting/pinvoking the underlying APIs that you already know and potentially hate :p (cough Android).
See http://continuous.codes/ for an example of what can be done with F# and Xamarin.
See http://continuous.codes/ for an example of what can be done with F# and Xamarin.
That is one way to define native. Another is to use the platform native source code and provide access to that. E.g. on Android Xamarin includes an overhead due to constantly passing thru the slow JNI bridge when it needs to communicate with the native UI widgets. It also includes a relatively large overhead because of standard C# libraries that need to be included on iOS/Android.
OTOH Codename One ( https://www.codenameone.com/ ) has a very different interpretation of "native". They use their own widget toolkit like QT which makes them "less native" in that regard. But they are native to Android (being Java based) and translate directly to C/Objective-C which means you can literally write OS native code and use native widgets within the hierarchy.
I think native is a worthless word in that regard as it doesn't properly convey meaning in these sort of complex situations. Once PhoneGap started billing itself as "native" this all went out of the window...
OTOH Codename One ( https://www.codenameone.com/ ) has a very different interpretation of "native". They use their own widget toolkit like QT which makes them "less native" in that regard. But they are native to Android (being Java based) and translate directly to C/Objective-C which means you can literally write OS native code and use native widgets within the hierarchy.
I think native is a worthless word in that regard as it doesn't properly convey meaning in these sort of complex situations. Once PhoneGap started billing itself as "native" this all went out of the window...
> Actually no, if you want the latest, most supported tools, frameworks APIs etc. you have to use Xcode.
You can do all of this at the command line without having to use Xcode. All Xcode is doing is running a bunch of command line applications to accomplish what it does... it isn't some kind of evil magic, it is just a project manager; so close that broken IDE that is Xcode and write some makefiles: you can use the same iPhone SDK and use the same compilers and the same programming languages can you can build .apps and codesign things for distribution via the App Store and never once touch Xcode. I'm working on a project right now that uses app extensions and special entitlements and all kinds of crazy up-to-the-latest iOS magic, and I'm not using Xcode: you can too; it isn't even like it is complicated, and so I continue to have absolutely no sympathy.
You can do all of this at the command line without having to use Xcode. All Xcode is doing is running a bunch of command line applications to accomplish what it does... it isn't some kind of evil magic, it is just a project manager; so close that broken IDE that is Xcode and write some makefiles: you can use the same iPhone SDK and use the same compilers and the same programming languages can you can build .apps and codesign things for distribution via the App Store and never once touch Xcode. I'm working on a project right now that uses app extensions and special entitlements and all kinds of crazy up-to-the-latest iOS magic, and I'm not using Xcode: you can too; it isn't even like it is complicated, and so I continue to have absolutely no sympathy.
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.
It's an unrealistic advice. It's easy to say it when your income is not dependent on these apps. But if you have an app in a marketplace that pays your bills, you can't afford to risk it just because you don't like dev tools...
It's only unrealistic if you aren't willing to adapt to changing market conditions.
This may not be what HN readers want to hear, but users, not developers, have the primary influence over what the market is.
is the market still apps? I don't work on mobile, so I guess I wouldn't know, but my feeling was that people install way fewer apps than they used to
As a mobile developer, I can confirm this. They mostly just install all their social networks and a couple of games, but there's still demand from businesses who want their own apps.
But the market conditions are what's holding us in place.
Unpopular advice here in HN but I honestly advice people to think twice about devoting all their career to technologies made and developed for a single company, there are some big risks there, you never know what Apple will do in the future.
You know Apple will sell a ton of iOS devices to people who have enough money to actually buy apps, which isn't yet true of Android.
I'm not advocating for Android instead, I'm personally not a fan of mobile apps myself.
What I'm saying is you never know what's going to happen on a single heavily controlled platform. In 2 years time, Apple can create a competitor to your app and ban you (happened), create new guidelines so you can't publish your app anymore (happened), change search algorithms and your app drops (happened?), remove you for political disagreements (happened), remove your app because of API deprecations and non-backward compatibility (happened).
Developing on a platform like this in inherently risky, this is probably fine for (most) companies but I would advice developers to avoid devoting all their careers to a single platform and try to diversify a bit in case something happens in the future.
What I'm saying is you never know what's going to happen on a single heavily controlled platform. In 2 years time, Apple can create a competitor to your app and ban you (happened), create new guidelines so you can't publish your app anymore (happened), change search algorithms and your app drops (happened?), remove you for political disagreements (happened), remove your app because of API deprecations and non-backward compatibility (happened).
Developing on a platform like this in inherently risky, this is probably fine for (most) companies but I would advice developers to avoid devoting all their careers to a single platform and try to diversify a bit in case something happens in the future.
Absolutely this, the most recent example is the Dash fiasco. It turned out OK for the developer, but had he been only on iOS for example, Apple would've ended his source of income. They also add more and more hoops to install non Mac App Store apps with each macOS release, I mean you can no longer install apps from "Anywhere" for example, like you used to.
What I recommend doing is to learn how to develop solid, cross platform APIs and you then have the flexibility to develop as many clients as you like, web, iOS, Android etc. with no single point of failure.
What I recommend doing is to learn how to develop solid, cross platform APIs and you then have the flexibility to develop as many clients as you like, web, iOS, Android etc. with no single point of failure.
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.
> if they considered this stuff a problem, they'd have fixed it by now
It's not good but it's workable. Which Apple accepts as a reason to focus very few resources on dev tools.
It's not good but it's workable. Which Apple accepts as a reason to focus very few resources on dev tools.
Sure. My point is more if it's good enough for Apple at their scale - I mean, Xcode itself is written in Objective-C with Xcode - and they're willing to work around it, then 25 developers (at time of viewing) in a GDocs sheet and a readme file will probably not be the straw that breaks this camel's back.
They don't really, not ones that they won't delete when they want the problem to go away. Using corporate forums for problems is a losing game.
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.
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.
Unfortunately, studies have shown that developing for iOS is much more profitable than developing for Android.
Customers aren't switching to Android. Apple is making almost all the profits in the mobile space and it's developers are making much more than android developers.
Those are the important things, quibbling about some features in the development system is silly, esp. when Apple has poured tons of resources into Swift and done it really well.
Those are the important things, quibbling about some features in the development system is silly, esp. when Apple has poured tons of resources into Swift and done it really well.
[deleted]
I guess you can only do this when you're not dependent on App Store income or you're big. Tencent has a top hit mobile game 皇者荣耀 that is only Android. They can afford due to China market. Both Facebook Messenger & WeChat has no integration to iOS 10 CallKit and Siri.
> Both Facebook Messenger & WeChat has no integration to iOS 10 CallKit and Siri
Messenger has had CallKit integration for quite a while now.
Messenger has had CallKit integration for quite a while now.
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 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.
That's great to hear & thanks for doing an amazing job with Swift. The language itself is great.
It would also be an absolute joy if we could actually refactor with Xcode.
This is one of the only criticisms of Xcode I'd agree with. And it's a minor issue for me.
It would, but in the meantime, I find AppCode to be pretty great for that[1].
1 - https://www.jetbrains.com/objc
1 - https://www.jetbrains.com/objc
I immediately downloaded appcode when I found I couldn't rename variables in swift
It's kind of sad seeing developers beg for things they could build themselves if the tool was open source.
This is what you get for relying on proprietary software, begging on your knees for crumbles while your supplier is busy pivoting themselves out of relevancy. It's always the same game, and we never learn; as soon as the next new shiny arrives, people get in the same old lines and beg for another round of abuse.
https://developer.apple.com/bug-reporting/
For anyone who signs this, make sure you throw a report at em as well!
For anyone who signs this, make sure you throw a report at em as well!
And see also http://fixradarorgtfo.com
They should recruit the services of Miss Swift, who received a swift response from Apple when she tried this, albeit not on a Git repository. http://taylorswift.tumblr.com/post/122071902085/to-apple-lov...
Oof. This isn't good for Apple, and I say this as a fairly big Apple fan.
From my perspective as a programmer, Apple's success has hinged entirely on the quality and innovation of their OS and dev tools. For a long time, both of these have been ahead of the game (since NeXT came to Apple).
They lose this advantage, they crumble. Mark my words! Go on, mark them.
From my perspective as a programmer, Apple's success has hinged entirely on the quality and innovation of their OS and dev tools. For a long time, both of these have been ahead of the game (since NeXT came to Apple).
They lose this advantage, they crumble. Mark my words! Go on, mark them.
They did develop Swift fairly recently, which is actually very nice, so it's not like they're doing nothing for developers, but the Xcode team really needs to pick thing up.
As someone that has dabbled in Android development, I have to say that Xcode is light years ahead of its competitors re: developer friendliness. It's realistic from a complete novice to setup their environment and create a full app in a few hours. Just getting your environment setup for Android can take a whole day or more.
I'm surprised by how few of these comments actually touch on the suggestions in this letter. Overall, they seem like small improvements that won't really move the needle on Xcode's effectiveness... Breaking up targets to make 15sec compilation times to <1sec would be nice though
Things I do with every project: -Don't use the interface builder, easier to do all UI work programmatically - Use Pods
I'm surprised by how few of these comments actually touch on the suggestions in this letter. Overall, they seem like small improvements that won't really move the needle on Xcode's effectiveness... Breaking up targets to make 15sec compilation times to <1sec would be nice though
Things I do with every project: -Don't use the interface builder, easier to do all UI work programmatically - Use Pods
This is an exageration. Setting up a clean install for Android development takes all of two minutes.
[deleted]
I use XCode for the absolute minimum, and when done with it, go back to AppCode.
I'm surprised I had to scroll this far down to find mention of AppCode. The ESP edition is even free.
I really don't know what Apple gets out of keeping XCode as closed source. Why not open it up?
There's always non-zero work involved with open-sourcing stuff. How would Apple benefit from this move?
In much the same way that Mozilla benefited from open sourcing Netscape's source. If they open source the code, then someone could work towards fixing the problems in this letter, for instance.
Since their tools and software is not improving and each version brings new bugs to enjoy, I am happy to see Microsoft support compilation of other platforms with Visual Studio.
The best would be Apple stops their whole desktop lineup and focus on mobile Devices, making everything easily accessible from other platforms. Maybe the way the Macs are updated is a sign in this direction.
I don't think it's considered a problem by the team at Apple, or even by some developers, but I would love a more stable Swift language. The number of changes per version * the number of projects in the world is causing a large amount of work and instability. This is contributing to the low tool quality as well.
Swift 3 had a purposeful effort to prioritize syntax-impacting changes and API changes as possible with the idea that Swift 4 and beyond would have backward compatibility for Swift 3 code.
Swift 4/5 will establish ABI compatibility, so that binary swift libraries will work across compiler versions
Swift 4/5 will establish ABI compatibility, so that binary swift libraries will work across compiler versions
Finalized ABI has been deferred from Swift 4, if you haven't heard: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo...
Another year of breaking changes, hooray!
Another year of breaking changes, hooray!
ABI != API, I think API-wise it should still be minimal breakage.
Yes I know that's what Swift 3 was trying to do, that's what I don't agree with. In my opinion the tradeoffs are just not worth it.
Whatever happened to graceful deprecation of older language features an APIs? They invalidated all the related example code online and created a ton of mandatory work for all iOS developers within a 1 year timeframe, that's nuts. In my opinion :)
Whatever happened to graceful deprecation of older language features an APIs? They invalidated all the related example code online and created a ton of mandatory work for all iOS developers within a 1 year timeframe, that's nuts. In my opinion :)
Why are you using a work in progress and unstable language? You should have known from the start that, implicitly, that would require a lot of rewrites. Developing a language, especially as all-encompassing one such as Swift, is a very demanding task; what is the added benefit of having to support deprecated language constructs and APIs? Tools are lacking as it is.
This is the other thing that people say when we talk about Swift stability. "It's a work in progress." Apple certainly isn't giving this impression anymore.
1) Apple now has most code examples in Swift. 2) Most talks at WWDC are either in Swift only, or with ObjC as the alternative examples. 3) Swift was made available almost 3 years ago. 1.0 was released in Sept 2014. The Swift team was working on it for several years before that. This is now roughly 6 years that the team has been working on it. So when should we consider it stable? 10 years? Longer?
To release a new language, call it the future of iOS development, but also call it "unstable and beta" is a really poor way to treat your developers. I am then stuck between possibly starting a project with an entire deprecated development environment (ObjC), or one that's going to be changing every year forcing me to spend significant time upgrading and possibly introducing bugs.
It seems possible to have a language change and mature in a more sensible way than this, it's just harder and takes more work by the language maintainers. The easy way is just to break everything, which is what Swift is doing.
1) Apple now has most code examples in Swift. 2) Most talks at WWDC are either in Swift only, or with ObjC as the alternative examples. 3) Swift was made available almost 3 years ago. 1.0 was released in Sept 2014. The Swift team was working on it for several years before that. This is now roughly 6 years that the team has been working on it. So when should we consider it stable? 10 years? Longer?
To release a new language, call it the future of iOS development, but also call it "unstable and beta" is a really poor way to treat your developers. I am then stuck between possibly starting a project with an entire deprecated development environment (ObjC), or one that's going to be changing every year forcing me to spend significant time upgrading and possibly introducing bugs.
It seems possible to have a language change and mature in a more sensible way than this, it's just harder and takes more work by the language maintainers. The easy way is just to break everything, which is what Swift is doing.
Agreed, but just anecdotally: I was job hunting over the last year, and I saw very few posts that said "We're sticking with ObjC for now because Swift is a huge technical risk" although I would have been happy to hear that.
There just seems to be a lot of momentum; everybody's excited about it, everybody wants to be on the bus.
There just seems to be a lot of momentum; everybody's excited about it, everybody wants to be on the bus.
That bus entails both good and bad, and everyone should be familiar with the risks of developing in a language in this state.
Personally, I wouldn't take any job application that only lists "Swift developer" seriously. Anyone serious enough about iOS development should know that you always need both. Also, not a big fan of telling people what technology to use forcefully.
Personally, I wouldn't take any job application that only lists "Swift developer" seriously. Anyone serious enough about iOS development should know that you always need both. Also, not a big fan of telling people what technology to use forcefully.
They're trying to build the best language for the next 20 years and sometimes you can only see what works/doesn't work once you build it.
C++ taught us what happens when you let cruft creep in, so I can see it from. their point of view, however I can also see the developer frustration.
It should be much better with the Swift 4 transition.
C++ taught us what happens when you let cruft creep in, so I can see it from. their point of view, however I can also see the developer frustration.
It should be much better with the Swift 4 transition.
[deleted]
I switched to Swift with version 1.0, it was terrible. Version 1.2 was when I was finally able to ship product. Since then it's just gotten better and better and the changes per version are a minor inconvenience. Usually am able to update a project in less than an hour.
Normalization of Deviance - this is a not uncommon problem with organization that grow as big and are successful. I'm curious on ideas on how a company as big as Apple and it's somewhat unfocused relation with the developer community can fix this? Maybe their CEO needs to call out to Developers.
74 signatures is hardly a blip. I would've waited for at least 5000 signatures before publishing this.
How do you get 5000 signatures without publishing it?
While we're at it, maybe we can put pbxproj out of its misery and get a modern project file format and module system
There's the Swift Package Manager, it should be part of Xcode sometime soon.
Signed. But is there some way you can hide the email addresses on the Google Sheet?
Can we give this HN post a better title? This is atrociously clickbaiting. Granted it just goes to GitHub, but I would like to have at least an _inkling_ of what I'm about to read.
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
- Taking the low road / Scotland's economy
- Back to the desert / Britain in the Gulf
- Still cleaning up the Co-op / Ethical banking
- Errant Flynn / Turmoil in the administration
- etc
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
- Taking the low road / Scotland's economy
- Back to the desert / Britain in the Gulf
- Still cleaning up the Co-op / Ethical banking
- Errant Flynn / Turmoil in the administration
- etc
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 article is worthwhile, they don't have to upvote it.
I like your subtitle idea too. It's definitely better than insisting on keeping just the original title. Unfortunately, it will make for some practical difficulties with the layout of HN pages, which will be able to fit fewer articles in the same space, and it will also be problematic with RSS feeds and the like, which will often still display just one title, not a title and subtitle.
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 article is worthwhile, they don't have to upvote it.
I like your subtitle idea too. It's definitely better than insisting on keeping just the original title. Unfortunately, it will make for some practical difficulties with the layout of HN pages, which will be able to fit fewer articles in the same space, and it will also be problematic with RSS feeds and the like, which will often still display just one title, not a title and subtitle.
HN needs a secondary upvoter system on the displayed title for an article.
"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?
"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?
Dear Apple - Xcode feature requests and bug reports (@dang)
Yet, oddly, not a single reference to a radar report that people can try to support.
Is this a manifesto, or an attempt to get a bunch of Apple developers to put their email addresses on a list as part of someone's marketing campaign for iOS-focused dev tools?
Is this a manifesto, or an attempt to get a bunch of Apple developers to put their email addresses on a list as part of someone's marketing campaign for iOS-focused dev tools?
Especially given the length as well. It's a small, short list of issues that users of XCode/Apple Developer tools have. Why is this #1 on the front page?
Because it's by far one of the most annoying issues every developer has with Apple now. It's so frustrating to see the syntax highlighting and auto completion engine crash continuously as you try to figure out what line causes it just so you can rewrite it the more verbose way for the engine not to choke. You may think this has to be a beta version or a newly introduced bug, but no, these issues have been there in the official release for at least 1 1/2 years now. It got better over time, yes, but it's still far from being where it should be.
> it's by far one of the most annoying issues every developer has with Apple now
Every developer on an Apple device who actually makes apps for Apple devices. There are a lot of devs on Macbooks who produce server applications that run on Linux, possibly more than create iOS or macOS apps.
Every developer on an Apple device who actually makes apps for Apple devices. There are a lot of devs on Macbooks who produce server applications that run on Linux, possibly more than create iOS or macOS apps.
Whoops, yeah that's what I meant to say
1 1/2 years? Uh since day 1 of swift at least. Granted it was beta then but you couldn't go 45 seconds without losing syntax highlighting.
[deleted]
Xcode is 14 years old and Swift is a new language with no baggage that really only needs to target iOS and has new APIs for graphics and more. Seems more likely their goal would be a much-more simplified IDE for iPads that anyone can learn that can only publish to iOS.
They also stopped making computer monitors and routers last year and haven't updated most of their computers in years.
Best reason to host WWDC outside of SF this year is so it won't be a building full of Xcode developers lol!
They also stopped making computer monitors and routers last year and haven't updated most of their computers in years.
Best reason to host WWDC outside of SF this year is so it won't be a building full of Xcode developers lol!