As someone who has (re-)implemented and shipped quite a few native applications across ecosystems (Apple, Android, Windows, Linux) all I can say about this is:
Xcode development, the Apple Developer Program, and the whole experience of trying to ship your application on the Apple ecosystem is the fucking plague.
I will do it if I'm paid for it - I generally charge twice my hourly rate for anything Apple - but I certainly won't go through the trouble of trying to get any of my hobbyist projects into Apple's walled garden. I like to do enjoyable things in my free time, and the timesink that is Apple's proprietary clusterfuck is anything but fun.
Apple's desktop market share being what it is, I cannot comprehend how they're generally getting away with this.
>Xcode development, the Apple Developer Program, and the whole experience of trying to ship your application on the Apple ecosystem is the fucking plague.
That's because you're a developer that works in different platforms ("Apple, Android, Windows, Linux"). So you probably spend most of the time working in some other platform, and doing macOS work for you is just an annoyance, having to context switch to another process, etc.
Apple tho wants macOS developers (and users prefer apps from people dedicated to macOS). That's because such vendors (e.g. Panic, BareBones, Omni, and so on) won't do lowest common denominator apps, they keep up with the platform, they understand it, they hook in to new platform-only capabilities, etc.).
>Apple's desktop market share being what it is, I cannot comprehend how they're generally getting away with this.
Apple's market share is what it is, in part because they enforce things like this. This means they can add new OS/hardware features and devs will add support for them fast (instead on relying to 1000s of half-ported apps, with shared functionality on Windows and Mac, and horrible cross-platformy UIs).
That's also why (forcing more people to use XCode, and thus the official APIs, BitCode, and so on), they can introduce a whole new architecture like AS, and have macOS apps support it from day one, or old x86 apps running smoothly translated.
I’ve used Xcode for many thousands of hours at this point and I have to say I actually think it’s pretty good now that I understand how it is supposed to work. But for a web developer who just shipped some JavaScript for Firefox and Chrome…just no, this is stupid however you look at it. The fact that you have to download a dozen gigabytes just to get access to what’s a glorified shell script, then packaging some web code in an app bundle for no reason and mandating that it is signed and distributed on the Mac App Store is just dumb. It’s an awful experience from Apple all around if they are trying to get people to port their extensions to Safari.
IMHO Xcode is at most "barely acceptable" when compared to most other IDEs, there's a lot more bad things than good things.
Why is it such a hassle to install a vim extension, requiring code-signing shenanigans? In other IDEs and text editors this is at most a few button clicks to install an extension.
The "Scheme" system to manage per-target options is a joke even when being used to it.
The debugger variable-view-panel is extremely bare-bones.
Xcode used to be slick, but since a few years everything gets bigger, slower and laggier. Starting up, loading projects, starting into the debugger all takes much longer than it should.
It's unclear how the "new" build system is any better than the "old" one. Apart from being slower than the old one I haven't found any differences so far.
The one thing where Xcode shines and was ahead of the competition is the easy integration of C/C++/ObjC validation tools like clang analyzer, ASAN, UBSAN and TSAN.
Xcode is…not very extensible IDE, I'll grant you that. The true impact of XcodeGhost is felt to this day :( I wish it was more extensible, and have myself done sketchy things to make it so, but I entirely agree with you that this is not a positive by any means.
If you are dealing with Xcode settings, move everything you can into xcconfigs, full stop. Just do it. It will save you countless merge conflicts, you'll be able to do mix and match and inheritance easily, and you'll actually understand what your build process is doing rather than it being a black box. I have no qualms blowing away targets and schemes now because I can just make them on demand and let Xcode autocreate the rest. I can "rebrand" an app in seconds and undo the changes in the same amount of time. Things which get used by other people always have ⌘B do the full build rather than some strange dance of "oh CocoaPods changed those settings so you should try to not set your development team on these targets and the dependency analysis is a little broken so…".
Debugger variables are…fine, I guess? I think the biggest issue I have with it is that it's placed in a not-so-great place, where it is generally to small to really see things. So usually I grab that information myself through a combination of p/po.
Xcode is still slick, IMO. Performance wise I haven't seen a huge change–it gets steadily bigger and slower and more complicated, but at about the rate that I update my computer. The people testing Xcode are clearly not using an Early 2015 MacBook Pro like I am, so I write off some of the features like Playgrounds or Previews or many simulators, but other than that I guess it's fine? I certainly value that it opens "immediately" rather than "initializing" (looking at you, Java-based IDEs…).
Where Xcode really shines is the things you touched upon: its integration with LLVM is first-class. It's certainly my preferred frontend to LLDB. The ability to flip on a bunch of diagnostics with one click has surely found many bugs, and the the built-in tooling for debugging memory graphs and view hierarchies is quite good–yes, it breaks sometimes, but it gives me useful results that I can't quickly get anywhere else nine times out of ten. Instruments is certainly unparalleled on macOS for external developers, and in comparison to tooling elsewhere it's a very solid offering.
Finally, of course, it's a nice native Mac app that plays well with all the other ones. That has to count for something :)
Multi-cursor support is something I want maybe once every few months? Certainly nowhere near a crucial feature, and barely one that makes a list of nice-to-have things.
Or even just test things in safari. Guess I have to spend at least 200$ on an ipod touch if i want to test in some sort of version of safari, significantly more if i want to test on a non iDevice (with an actual console etc)
Obviously for a business this is a neglegible cost but for someone just making a hobby app, it's ridiculous. microsoft at least offers VMs with edge and ie on it
Because you want it to be cross-platform? Just because it's a hobby project doesn't mean you don't give a shit about the user experience. I mean it's not like you have to recreate it from the ground up to make your webapp work in safari, it'll mostly be small tweaks.
All three of those developers started writing Mac software (or NeXT software, in Omni's case) in the 80's and 90's, before Xcode or the Apple Developer Program. The wider Mac developer community was hollowed out by the iPhone in the late 2000's-early 2010's and never really recovered. Who is starting a Mac-only software shop in 2021?
Are anyone doing Windows or Linux only software shops in 2021 (web services not included)?
Even the ones reaching hacker news seems to fiddle down after just a couple of years and die out.
I’m starting to wonder... here around 4 out of 5 business close down within a couple of years, how is that ratio for business making a software product? Is software a victim of its own success? The market is clearly there, but the competition is ruthless, the stacks ever changing and the risk seems to increase year for year.
At the same time we code on our free time and happily give away our code for free.
Tried to find a study where they showed that gambling addiction and programming addiction operated similarly but it seems to have been scrubbed of the internet.
IMO median(!) salaries will go down relative to other diciplinaries. coding is just too fun.
I'd argue that the Mac developer community was hollowed out by mandatory Sandboxing in the Mac App Store, introduced in 2011, not by the iPhone (2007). Sketch, arguably the most successful third-party Mac-only app since OS X, was released in 2010, several years after the iPhone, but almost immediately before mandatory sandboxing.
I believe the reason sandboxing destroyed the Mac software ecosystem is because it's too restrictive to support the kinds of productivity utilities that have historically thrived on the platform. And those apps are too small to handle promotion without Apple's help, Apple's help now being reserved for apps in the Mac App Store, which are by extension sandboxed.
Sketch is an interesting one, gained so much traction for having a superior interface but after several years in the lead it's getting devoured by a cross platform web app with superior collaboration.
It's relevant that has also been essentially 10 years of stagnation on the frameworks that Sketch is built on, i.e., AppKit, as Apple focuses on UIKit. In this case specifically Apple hasn't added best-in-class collaboration features to AppKit (or UIKit). I'm not sure whether it would have made a difference in Sketch vs. Figma, but the fact that they haven't has made it difficult for Sketch to compete, as Sketch's MO is leveraging Apple's built-in technologies.
On one hand I think macOS sandboxing can be a bit too restrictive and buggy, but on the other I think it's somewhat unreasonable for developers to continue to expect unfettered access as a given on the desktop, because it's been proven time and time again that unfettered access will be abused, often by big companies that users tend to implicitly grant a higher level of trust to.
I agree 100% in principle, the problem is Mac App Store apps compete with non-Mac App Store apps that have unfettered access, and macOS itself competes with other OSes where unfettered access is expected.
>I believe the reason sandboxing destroyed the Mac software ecosystem is because it's too restrictive to support the kinds of productivity utilities that have historically thrived on the platform.
And yet, MS Office, Lightroom and others are on the App Store.
I'm not quite sure what your point is, but those are 100% the most interesting cases of apps conforming to the Mac App Store that I wouldn't expect to. Here are my explanations:
1. Lightroom is easy, Lightroom Classic is not in the Mac App Store and is still supported. Anecdotally Lightroom Classic appears more popular than Lightroom, especially among professional photographers where it's fair to say Lightroom is shunned. So Lightroom is Adobe's attempt to have it both ways.
2. Office is much more interesting. I honestly find it shocking that Office is in the Mac App Store, since I don't think it's in Microsoft's best interest. I think the reason is that the Mac versions of Office are really stripped down and separate code bases than the PC versions, and I'd guess that this decision was in some way made possible by that separation (e.g., if there's a feature that's not possible in sandboxed version, it can just be stripped from the Mac version, which would be more difficult with a shared code base). I'd also guess that this will eventually be reversed as Microsoft is on a path to making cross-platform web-based (Electron/React Native) versions of all their software, and I don't expect those to be sandboxed.
For the record, by productivity software, I didn't mean things like Office and Lightroom (my fault for not being clear). I meant utilities like LaunchBar, Keyboard Maestro, Moom, etc... e.g., launchers, window managers, and the like, which generally need more privileges than sandboxing allows, because they involve scripting, interacting with other apps, etc... A lot of the indie Mac app community centered around these apps because they allowed users to get a lot of value without much code (relatively) by adding smaller, system-wide, features.
Document-based apps work much better with the Mac App Store, but those apps tend to be an order of magnitude more work to make, therefore there were always much fewer of them. Document-based apps also have a lot of problems with Sandboxing, but at least they're possible to make sandboxed.
Name them. This is a serious request. I'm a longtime professional Mac developer who knows a lot of other Mac developers.
> There are more Mac users (and thus app buyers)
The premise is true, but the conclusion is not necessarily true. The crap store and the iOSication of the Mac have really hurt the Mac software market.
>Name them. This is a serious request. I'm a longtime professional Mac developer who knows a lot of other Mac developers.
I get all kinds of great new Mac apps from new devs, so not sure what you mean. Some examples I've personally use and bought in the past year or so: Darkroom, CleanShotX, Bear, Amadine, Wipr, Keka.
If we can go a few years back there's tons of other stuff that's still going strong too with new versions regularly and everything...
You mean like web devs ship websites only tasted in latest Google Chrome? How Microsoft ships Windows tested only on a handful of hardware configs? How game devs ship games only tested on the latest graphics card?
The whole point of having standards, conventions and stable interfaces is that developers do not have to test their code on every "platform" (in this case browser). If there are platform-specific differences from the standards, that is the platform developer's problem.
And keep in mind we're mostly talking about individuals here - companies rarely develop extensions and those that do can probably afford an old mac to use as a complie box. Extensions are usually developed by individuals in their spare time and rely on beta testers anyways, as it is already impractical for one dev to test them on every possible config.
>The whole point of having standards, conventions and stable interfaces is that developers do not have to test their code on every "platform" (in this case browser).
Well, we don't have standards for native apps, only partial standards for different APIs and protocols, so there's that.
And the change Apple made, to allow for Chrome-like extensions, is already more "standard" than before (where it was Safari-only extension APIs). It just requires one more step.
That is my whole point though: the WebExtensions API is a standard, so it's not like you can't test your extension without owning a Mac. If your extension works on both Firefox and Chrome, it really should work on Safari too. If it doesn't, that's Apple's fault for violating the standard, not yours for not testing on their broken platform. If you want to specifically test it you can, but if you don't see a reason to, you should be able to just port it over and let people use it and beta test it for you.
>If your extension works on both Firefox and Chrome, it really should work on Safari too. If it doesn't, that's Apple's fault for violating the standard, not yours for not testing on their broken platform.
Chrome is notorious for building this that are not standards and forcing them into standards bodies later. That's part of "but it works on Chrome" web issue.
So not working on Safari doensn't necessarily mean it's the fault of Safari for "violating the standard". Could very well be for upholding the standards over Chrome ad-hoc/de-facto "standard" additions...
Which is why I mentioned both Chrome and Firefox, as while both implement some non-standard features, those tend to differ, so the intersection of their feature sets is pretty much the standard itself.
I was actually referring to "your extensions following the standard", but since you can't exactly test against the standard directly, I used testing against both browsers as a good approximation.
I think the point of standards is portability. You still have to do testing on different platforms, especially when porting the first time.
I maintain a cross browser webextension (chrome and Firefox) and I would not release it on a new platform without testing. I have already found bugs in the API implementstions on Firefox and confident I'll find more. There are also differences in implemention between just those two browsers that I have to work around.
I mean, I guess... since among the things I've shipped are, uhm, WEBSITES, yes?
Because there are more browsers than any person could conceivably have time to rigorously, thoroughly test. Yes, things like Browserstack exist.
But why do I have to test my Web Extension differently from my website. Should Safari start blocking websites whose TLS certificate lacks a "issued-to-a-mac" extension?
Developers can and should test their code in a high-fidelity simulator for some configurations–limiting myself to just Apple platforms, I certainly don't have every Mac, iPhone, or Apple Watch in every combination of versions in front of me. I shipped support for iPhone X and Apple Watch Series 4 without having either of those devices on hand–for the latter, as you probably know, without even recompiling it. None of my personal Macs have a Touch Bar, but that hasn't stopped me from writing code for it.
It's completely fair–actually, it should be expected–that extensions targeting standardized APIs should function correctly regardless of platform. If you're coming from a position of trying to incentivize people who largely don't care about a tiny, strange platform to begin with, locking them out entirely based on hardware requirements is frankly about the worst thing you could do to drive adoption.
Those are top-tier professional staples. Mac users can't chose another Photoshop, because there's no other at that level (Affinity and co are great, but nowhere as comprehensive).
But even so, Photoshop, Premier and co, has ties to native functionality, gets the native look and feel for things like file dialogs and such, is quick to move to Apple Silicon / M1 natively (and even has a native iPad version, complete with native UI) and so on.
It's not some lowest-common-denominator cross platform affair, like most cross platform lesser GUI apps are.
Also, Word and co. Microsoft apps are not cross-platform. They are special codebases for macOS, complete with macOS native UI and everything.
As true as this is, when it comes to Adobe products there's also no shortage of griping about things like UIs getting progressively more glitchy and less responsive and bad or nonexistent hardware acceleration… gripes that largely didn't exist 15 years ago when those same Adobe products were more closely tuned for the platforms they ran on instead of going all-in on one-size-fits-all.
While you might be true in that Apple tries to cater to a different band of Devs dedicated to their eco system, let's also not kid ourselves that they have had their experience at heart when making decisions about their platform. Are you telling me that dedicated apple devs have the greatest dev enviroment and experience there is? Or are you merely saying that they have a less shittier experience because they decided to drink the coolaid and get into a one sided relationship with Apple?
> Are you telling me that dedicated apple devs have the greatest dev enviroment and experience there is?
The have some approximation of the best environment given Apple's priorities, where customer experience, security and privacy, and the bottom line are considered significantly more important the developer experience.
>instead on relying to 1000s of half-ported apps, with shared functionality on Windows and Mac, and horrible cross-platformy UIs
Most people I know day to day who insist on Macs spend all their days using Chrome, VSCode and Slack with little else.
The days of the Mac UI apps built by passionate Mac developers being the Mac advantage are over. People like myself who still use native Mac software like TextMate, Safari, Transmit for the Mac UI are absolutely a small and shrinking minority.
I think while Apple has been looking the other way to iOS the past 10 years this moat of MacOS better 3rd party app experience through native ui frameworks has been completely eroded and now most MacOS users are just doing their work via Chrome wrappers.
> That's because such vendors (e.g. Panic, BareBones, Omni, and so on) won't do lowest common denominator apps, they keep up with the platform, they understand it, they hook in to new platform-only capabilities, etc.).
What about thousands of small devs/companies who are not Panic or others having contacts inside Apple and a privileged position? Here on HN there's at least one horror story a month about issues someone had with Apple, from ever changing terms, to review process that takes for ever - while still doesn't manage to catch many real offenders (especially in terms of privacy issues), but slows down legit devs trying to quickly fix bugs and close the security holes in their apps. It has become a layer over a layer of bureaucracy which more and more seems to be it's own purpose. Honestly there are much easier ways to make money as a programmer.
Here on HN there's at least one horror story a month about issues someone had with Apple, from ever changing terms, to review process that takes for ever..
Looking at that pragmatically, if Apple are managing to keep "media worthy" problems down to about 12 cases a year they're doing an amazing job.
>Here on HN there's at least one horror story a month about issues someone had with Apple
With 2 million programmers, a marketplace of 100billion, and millions of apps, "one horror story a month" (i.e. "somebody was annoyed on the internet and posted about it") sounds like a huge success story. And many of these are non-stories, or stories of the kind "Me, one of 1.5000.000 programmers on iOS/macOS stores, had an app rejected for some reason".
We never hear the Linux horror stories of commercial developers trying to sell native apps. If we did it would be more like:
"I tried to make a living with a native desktop app - FOSS or proprietary - for Linux, but nobody seems to care and fewer would pay, plus between GNOME, KDE, XFCE, and 10 popular distros, the landscape is a fragmented mess. Oh, god I wish there was an App Store for all, and $100/year to give me access to customers who will actually pay and a way out of this mess".
>while still doesn't manage to catch many real offenders
Why would one expect it to? No system is perfect, it's enough that it catches most offenders, or more offenders than alternative systems. E.g:
+ There's plenty of commercial software available for Linux
+ Desktop environments aren't the issue, they're just graphical shells. It's the rendering toolkits like Qt or GTK which matter more. And even then, you basically just pick one and move on.
+ Yeah the multiple package managers situation can be annoying for non-free software. But then that's still better than a monopoly like on iOS.
I've seen you've posted multiple comments attempting to defend Apple's ecosystem (ironically some of them contradicting other posts of yours in the same thread) but you're still missing the point that developing software for Apple platforms is a massive headache and a massive drain on the wallet in ways that isn't true for any other platform. I honestly don't think Apple care much for developers outside of their own in house teams because the process is so mindbogglingly shitty for everyone else.
You are right, multiple desktop environments are not an issue -- unless you are toolkit author; the different corner cases in different Wayland compositors can be issue, but only for toolkit authors. We are talking about such a layer in the stack, where Apple or Microsoft won't even let you play. Anyone, who uses the multiple DEs as an excuse is firmly put into doesn't know what he is talking about box.
Multiple package managers are not an issue either. In this day and age, you should be using Flatpak. That would also allow you to target very specific ABIs in a cross-distribution way, thus removing the fragmentation excuse.
> "I tried to make a living with a native desktop app - FOSS or proprietary - for Linux, but nobody seems to care and fewer would pay"
And how is this different for AppStore? More and more abandonware, and more and more cheap/freemium clones and garbage - noise to signal ratio is much lower than on say Linux. From a dev perspective, unlike a decade ago, now there's very little room to make any significant money just by building and selling simple desktop apps as indy dev. Now you need a SaaS, or some freemium upsell scam and a lot more marketing skills, plus Apple takes their share of every possible income channel you have and gives very little in return. That's at least my experience.
Okay, but then you're going to have to be content with the fact that extension developers are largely going to just ignore Safari.
There's a little bit of mutual blindness that happens here both with anti-Apple commenters and pro-Apple commenters. It's absolutely true that Apple's tight integration and control over how developers work allows them to do things with their platform that no one else can do. It is also true that Apple is playing a very dangerous game with the MacOS ecosystem, and a lot of developers are looking at it and saying, "this is not a healthy relationship, there's zero reason for me to ever support this platform."
To a certain extent, Mac users don't care -- many of them are happy to be part of a diverging software ecosystem and to use apps that only work on their computers. Apple critics sometimes underestimate just how OK Mac users are with the idea of living in an isolated software world. To many Mac users, being in their own isolated, incompatible world of software is the point. But, it is also true that browsers like Safari are tangibly suffering for this, that Open Source developers and tool authors are starting to look at Mac as a losing battle, and that ultimately, if things continue in the same direction, this is going to mean that there is a lot more pivotal indie software/games/tools that decide not to support Mac -- and some of those will be programs that people on Mac actually want.
As an Apple critic or at least an Apple skeptic (even though I do some development on Mac hardware), I am curious what the future of Mac as a development platform is going to be. There was a period where I recommended Macs as a next-best alternative to Linux because of that Unix base. Now it is a very cautious recommendation, if it is a recommendation at all. I've run into more than a few really weird dev problems on Mac over the past year that have been kind of disruptive, and I haven't even updated to Big Sur yet -- which, from what I can tell introduces even more problems. In contrast, developing software (especially web-based software) on my Linux machines is pretty painless. And when I need to test in Windows, I can spin up free, official VMs. I don't have to have a special secondary computer to run tests on. So unless I'm building software specifically for Mac, it just kind of doesn't make sense to support anymore.
And frankly, if you're a solo developer who's into Open Source development or tools development or game development, you're very probably not going to be building software specifically for Mac, and you're probably willing to drop Mac if it means you can easily target Linux/Windows -- given the choice between MacOS and Windows, most devs are not going to choose to drop Windows. I mean, we can debate OpenGL and Vulkan, but I'm sure as heck not going to write a game that targets Metal, that would just be a colossal waste of time for realistically a rounding error in market share. This is something that Mac users are currently able to just shrug off (in no small part because of 'lazy' cross-platform apps/games that use Electron, QT, and Unity), but it might be a harder problem to ignore in the future.
> As an Apple critic or at least an Apple skeptic (even though I do some development on Mac hardware), I am curious what the future of Mac as a development platform is going to be.
As an Apple fan -- albeit one who came back to the platform after years with FreeBSD, Windows 2000/XP, and BeOS (yes, full-time for over a year) and who uses Linux via ssh daily -- I am concerned what the future of the Mac as a development platform is going to be. I think your first paragraph is right on point.
I don't mind Apple going their own way with Safari to some degree, and there are things I just like about it as a browser -- it's fast, I find its minimal UI a bit more to my taste than either Chrome or Firefox, and I like that it syncs tabs and bookmarks between all my devices. (Yes, I know I could get that if I fully committed to either Firefox or Chrome.) But adapting WebExtensions support and then requiring developers to wrap those extensions in Xcode-built Mac applications that have to be published on the App Store just seems like Apple shooting themselves in the foot. It may be a handsome space gray gun milled out of a single block of aluminum, but it's still a problem.
(I'm also not sure why Apple won't at least support Vulkan in addition to Metal, but that's probably a different discussion.)
> I'm also not sure why Apple won't at least support Vulkan in addition to Metal, but that's probably a different discussion.
Likely for the same reason Microsoft doesn't support Vulkan - they want to have full control over their own graphics API.
The only commercially licensed/supported platform that requires Vulkan AFAIK is Android 10+ on 64-bit devices. However, I don't believe Google ever stepped up to standardize high performance graphics, so Vulkan was their best jump after OpenGLES started to sink.
> am curious what the future of Mac as a development platform is going to be.
iOS is the future of Mac as a development platform. You can't develop for the iPhone without a Mac, many more developers care about iPhone than Mac, and Mac now offers (bad) support for running iPhone apps and cross-platform apps with Catalyst.
> Apple tho wants macOS developers (and users prefer apps from people dedicated to macOS).
This is a very strange argument to make in the context of Safari Web Extensions. Safari already had its own Apple-specific app extensions API, but it seems that Apple decided this was not sufficient, so they implemented the cross-platform WebExtensions API too. Clearly Apple is trying to recruit non-Mac developers with their command-line conversion tool for existing Chrome and Firefox extensions, and automatic generation of a Mac app wrapper.
If Mac developers were sufficient for this purpose, then WebExtensions support would not have needed to be added to Safari at all.
So many Apple complaints boil down to "it's not Windows or Linux". If you learn the platform, little about Xcode/the dev program/etc is surprising. Perhaps slightly annoying in an extra step or two, but nothing too unmanageable.
IMO, the bigger problem with developing for Apple's side of things is documentation - particularly, for things that need to exist outside of Apple's "blessed" path. If you're just in Xcode, things will mostly work - if you're outside of it, it can be confusing at first, for sure.
That's also why (forcing more people to use XCode
and thus the official APIs, BitCode, and so on),
they can introduce a whole new architecture like AS
and have macOS apps support it from day one, or old
x86 apps running smoothly translated.
It's a failure of HN culture that posts like this get downvoted. You can like it, loathe it, or feel somewhere in the middle. However, this is factually true, and it is a relevant and legitimate response to issues raised by the parent poster.
Yeah but there's nothing that says the Xcode experience has to be so painful[1] or that people have to pay Apple or that software has to be approved by Apple in order to preserve this flexibility. Purchasers should have options, including the option to write software (for themselves) that works on the computer they paid for but might not work if Apple introduces computers based on a new architecture, which the existing Apple customer may or may not choose to buy in the future.
1. Painful for the parent commenter. It is painful for me, too. It might, or might not, be painful for others.
I haven't used Xcode much, so it's not for me to say if it's good or bad. However, I would assume that Apple uses Xcode internally, if it was a pain to use, in general, would Apple fix it? At least to save on development cost internally.
Of cause it could be that Xcode is very finely tuned to Apples needs, which may be radically different from those of 3. party developers.
They do use it internally and a lot of teams do complain about it. I hope there is some real work going on to improve some parts of it (how about shipping patches rather than an entire 11gb binary every version). I think a lot of devs also pin certain issues on Xcode that are actually issues with the Swift compiler (slow or missing autocomplete, unhelpful error messages or slow compilation times for example) ObjC is far far quicker to compile.
Apple uses Xcode internally very heavily, and it's less about it being tuned to Apple's needs (which it is, but as an app developer your needs and Apple's match pretty closely) but that Xcode tends to not scale very well.
XCode (with swift) seems to crash on me regularly just with normal usage. The last time I used it occasionally it would lag so badly that it sometimes lost characters I was typing, and my code would come out completely garbled (what!?). A few weeks ago I tried to do a local build of Signal's iOS app and the swift compiler errored out on some random function. Apparently it spent so long doing type inference that it decided to just generate a compilation error instead. I guess I'm not wealthy enough to even compile swift code slowly. (For reference, this on a $3000 (AUD) macbook pro from 2016 with 16 gigs ram, the latest xcode and nothing else open).
Back in the objective-C days I used to really like XCode and loved interface builder. The documentation and ecosystem seemed top notch. But in the last few years its gotten much, much worse. Its like the old guard have left and a young generation have come in to develop the swift ecosystem - and they just don't have good judgement yet. The documentation is halfbaked at best. The whole environment is an overcomplicated, buggy, laggy mess. Its a pity too, because I think Swift is a lovely language and I love what they're doing with SwiftUI.
In comparison I find microsoft's tooling around their languages to be excellent. Visual studio + vs code are fast, stable, feature rich and responsive. Particularly with microsoft's own languages: C# and typescript.
Xcode with Swift is a bit odd in that its performance varies greatly depending on project structure and as nonintuitive as it may be, the way the developer writes code.
For instance a sprawling project with an even split of Objective-C and Swift that constantly call into each other can bring SourceKit to its knees, as can some CocoaPods setups. Going Swift-only or even just reducing the surface between Objective-C and Swift to the absolute bare minimum can speed things up a lot.
As for writing style, there's a few things that can trip SourceKit up but I've found that the main things to avoid are chaining optionals too deeply and nesting closures too deeply (recommend keeping both to 2-3 tops) as well as casting to/from Any too often.
Not quite - the origin of "You're holding it wrong" was a response to someone who was quite literally trying to illustrate the cellular signal attenuation issue by pressing down with their fingers on the gap between the two antennas.
I believe the parent was saying that the performance of xcode varies based on the project. This is true - breaking projects up into more modular setups has long optimized project build speeds. The quality you get out of your tools is in many cases based on how you use them.
"You're holding it wrong" would apply if you were deliberately using the tools in a sub-optimal way to try to prove a point.
Yeah its 2021. There's no excuse for shipping software you know crashes every few hours of normal use. Or lags so badly you can't type sometimes. I doubt XCode in its current form would make it through Apple's own app store review process. Fix your software or replace your staff with people who can.
I choose to abandon programming for Apple's devices entirely rather than put up with xcode.
I’ve noticed similar issues, it’s especially a problem with SwiftUI as nesting closures often feels natural there, my brand new M1 mini will still give me the “expression too complex” error on larger SwiftUI components.
You can't beat Hyrum's law by simply "forcing more people to use official API", with enough code people still depends on every implementation details in your code.
>You can't beat Hyrum's law by simply "forcing more people to use official API", with enough code people still depends on every implementation details in your code.
That's neither here, nor there though. You can still beat the biggest part of fragmentation by "forcing more people to use official API".
Doesn't have to be perfect, just good enough to make moving forward, porting to your new architectures and APIs, etc, easier.
In fact, Apple just showcased it works with the move to M1 (and to a lesser degree earlier with the move to x64 and the move to 64bits).
Given that Apple has explicitly stated this benefit and given that Apple has explicitly utilised these exact benefits in the real world on multiple occasions, it's rather bold to propose that it might not be factually true.
Obviously it's not the only reason that Apple does things the way they do. It's probably not even the number one reason. But it's certainly one significant reason which seems to fit the objective criteria of being factually true.
(To be clear, I am stating no personal opinion about whether Apple's approach is "good" by any criteria.)
The barrier for entry to the Apple ecosystem is extremely high though.
Xcode is extremely hard to use. I've been programming for over 20 years, and used lots of different editors and IDEs and languages.
But Xcode is just TOO HARD. Swift was nice and easy to understand. But just editing (or even typing) code on the editor is a huge pain. Even things like selecting text, or moving the cursor around are super non-standard and complicated (and this is coming from someone who's managed to become proficient with vim).
Well, I have been programming for 30 years now. I started with Apple when iPhone SDK was released. Had no problem with Xcode then, have nor problem with it now. How can actually IDE or editor be HARD (memes about quitting vim aside). I've used a bunch of them: HomeSite, SKEdit, Textmate, Sublime Text, PHPStorm/RubyMine/WebStorm, NetBeans, Xcode, AppCode, VSCode, Nova. I liked some more, some less, but neither was HARD.
How is moving cursor not standard? Mac OS has a very consistent way doing that, across the system.
>Even things like selecting text, or moving the cursor around are super non-standard and complicated
This doesn't even make sense. Those things in XCode are as bog standard as it gets, and I've also used vim, Eclipse, Idea, ST and nowadays VSCode.
I'd buy the UI setup (with connections between actions etc) being confusing in XCode (especially things like Storyboards), but text editing? Cant even understand what you could mean. Any concrete example?
Apple cannot justify their transgressions against the modern development workforce as "a matter of platforms". The future cannot be segregated by platforms - that's part of the goal of a private and secure web. We need to work together to create secure infrastructure that everyone can trust, not huddle away and say that "Apple isn't looking for people like you". I understand that you're probably pretty impartial on the topic, but even you can acknowledge that their treatment of developers is unhealthy.
>Apple cannot justify their transgressions against the modern development workforce as "a matter of platforms".
Sure they can, and I for one, am fine with their justification. I don't want everything to be "secure web apps", I want to have native apps, and I want to have a choice of different platforms (Windows, macOS, Linux, etc.) each doing its own thing their way.
I don't want to use Linux as my desktop because I don't like their choices, the same way I don't want to use Windows or macOS as my server, because I don't like their choices.
>The future cannot be segregated by platforms
That's a monoculture dystopia then, not a future where many competing ideas about what platforms can be, what OSes offer, what their core tenets are, etc. flourish.
To top it off, if you put a donation link in your about box when you release your totally free software in their App Store, they will reject it in review. Free apps are not allowed to include a donation link to their own website.
It's to the point where they won't even let people enrich their ecosystem for free unless you dance to their tune. It's very, very hard to take anything other than a dim view of such despicable behavior.
Donations is just another model of making money from software. So you're going to use App Store for free and make money without Apple getting their cut. It's understandable why Apple does not accept it.
It's not free. There's a $99 membership fee every year, even for an altruistic person offering nothing but a single useful extension/app that makes zero income.
---
Let's imagine a feature request on GitHub:
USER: Safari supports the WebExtension API now. Please port your cool extension to Safari.
DEVELOPER: Cool. I'll maybe try doing that this weekend!
USER: Oh, by the way, you'll need to be on the hook for $99/yr for the rest of your life, so that Safari users can install the extension.
I still can't get my head wrapped around the complaint that the developer program costs $100/yr, as though this were some great barrier to entry. To put it in perspective, I subscribe to <deep breath> Prime, Netflix, Hulu, Disney+, HBO Now, Apple One, Office365, PS+, and Xbox Live, and that's just off the top of my head. Most of them are for purely-optional entertainment, and all of them cost more money than the developer program. I suspect most people who frequent this board pay for several of these too. In comparison, the $100/yr for the developer program is not a lot of money. It's certainly comparable with other optional digital services. It's less than a single restaurant lunch per month.
You can complain that it's not right to charge for the program, but the developer program has a cover charge to keep out the riff raff. I don't think this is a bad thing. We all know how much junk is in the App Store as it is, and how long it takes to get a review. Imagine if they didn't charge for the opportunity to submit apps? How much soon-abandoned junk would suddenly appear, and how long would it take for proper apps to get approved?
A Chrome/Firefox user expending some effort to make their existing extension available to Safari users is doing those users a favour. Generally one doesn't have to additionally start donating money to someone's preferred charity when already doing them a favour.
You're going to have plenty time to Wrap Your Head Around this dynamic by simply observing how the Safari WebExtension ecosystem plays out.
I'm struggling to understand how I could have been misunderstood. $100/yr is $8.33/mo. Even a burger meal at a fast food joint is that much now. Ergo: less than a single lunch PER MONTH. Where did I lose you?
If you believe that donations accepted by authors of entirely free/open source software are "just another model of making money from software", I don't know what to tell you.
I don't understand it, so I don't think it's fair to call it "understandable".
Would the hobbyist projects whose development is effectively inhibited by Xcode and the Apple Developer Program, i.e., the hoops Apple makes programmers jump through, be more interesting than the apps people pay developers to create.
I think capitalism works. That's how apple does it.
That said, I was attracted to computers since an early age because it's fun to make them do things.
But I think apple's ecosystem takes the MOST EFFORT of any of them to actually do anything.
For example, on linux there are probably 100 scripting languages that can do fine-grained automation of just about anything you want to do.
With apple.. ugh. It's either applescript, or you're into xcode and a compiler and a license agreement and high complexity and lots of only-apple-does-it-this-way.
Here's a simple one: how do you have two icons in the dock - one to open an 80x25 terminal window, one to open a 140x50 terminal window. This takes way too much energy to automate.
You can do it in applescript, but it's such a horrible language.
tell process "Terminal" to click menu bar 1's menu bar item "Window" menu 1's menu item "Open Window Group"'s menu 1's menu item "group1"
I know there are shell scripts and python, but apple treats them like the jackling mansion - no gui, cmdline is non-essential, everything is rotting.
Writing AS is not a pleasant experience, I agree. IMO, it was internally abandoned long time. There was a push to move the automation framework to JS with JSX, but after the initial half-broken release nothing came and as far as I understand, the team was dissolved. Shortcuts on iOS may be the model for future automation on MacOS.
This said, one of the biggest reasons I still clamp to macOS is, actually, the state of automation tooling - even in this half-abandoned state. Your example would be trivial to implement with tools like Keyboard Maestro or hammerspoon. Then there are tools like Alferd/Launchbar, Karabiner elements or bettertouchtool for touchpad gestures... It is really a vast ecosystem which is to match.
Xcode development, the Apple Developer Program, and the whole experience of trying to ship your application on the Apple ecosystem is the fucking plague.
I will do it if I'm paid for it - I generally charge twice my hourly rate for anything Apple - but I certainly won't go through the trouble of trying to get any of my hobbyist projects into Apple's walled garden. I like to do enjoyable things in my free time, and the timesink that is Apple's proprietary clusterfuck is anything but fun.
Apple's desktop market share being what it is, I cannot comprehend how they're generally getting away with this.