Hacker News new | past | comments | ask | show | jobs | submit login
Response to “WireGuard: great protocol, but skip the Mac app” (zx2c4.com)
925 points by motiejus 7 days ago | hide | past | favorite | 373 comments





> We faced rejections in submitting the app, because they decided to change their policy on the app having a link in the "About WireGuard" tool window to www.wireguard.com/donations/ (which they previously had allowed explicitly; now they want 30% or something)

Last year Google started to ban donation links in FOSS apps, WireGuard was one of the first victims [0], completely removed from the store. I didn't know that Apple also started doing the same and hit WireGuard again. Extending the definition of an "in-app payment" to a link to the project homepage in the "About" window that doesn't buy any good or service related to the app is an overzealous restriction. Especially so when that button is clicked by, perhaps, only 10% of the users. This is just evil.

[0] Open-source apps removed from Google Play Store due to donation links

https://news.ycombinator.com/item?id=21268389


> when that button is clicked by, perhaps, only 10% of the users

10%? I think FOSS developers would be extremely happy if even 1% clicked on that kind of button. I reckon the actual stat is closer to 0.01%...

This is absolute scroogerism from our mobile overlords. We badly need a really-open alternative to the Google/Apple world of feudal taxes.


> We badly need a really-open alternative

F-Droid is a thing


For now.

When they change that optional setting they introduced recently which blocks sideloading applications outside of the official store and make it non-optional, what are we going to do? Use special Chinese Android builds with Ali store (or whatever it's called)?

Boiling the frog slowly and all.


> When they change that optional setting they introduced recently

What setting was introduced recently? I remember such settings all the way back to the Nexus One.

In fact, things were more closed back then as Android phones bought from AT&T had it hard coded to disable third party apps. I'm not aware of a US carrier doing that any more.


Might be talking about their "Advanced Protection Program": https://landing.google.com/advancedprotection/

It would be interesting to know if the APP protections "bleed" from APP profiles to the regular kind when they're both on a given device.

I could be mistaken, but I'm not seeing a connection between that and third party app support.

> On your Android phone, only app installations from verified stores, like the Google Play Store and your device manufacturer’s app store, are allowed.

To be fair, from a security standpoint if you want *the highest security* allowing third party installers is one of the first things I would disable as well.

Oh, thanks, I somehow missed that line.

GrapheneOS, on whatever devices have proper security models at the time.

Android is open source.

The builds your phone comes with are not, and replacing them with your own assumes availability of things like unlocked bootloader.

And then, of course, applications like your banking won't work, because they require Google SafetyNet attestation for your security.


If your bank decides that your business is worth less to them than a compliance checkmark, that's on them.

All my phones are rooted and it has never been an issue with any banking app I use. It's all about priorities. For some people, that's going to be the roman numeral name suffix dropdown in the registration form. For me it's the bank not telling me what I can do with my devices.


It is not just what the bank wants and pushes on its clients, because f them. At least in EU, they are pushed into it by PSD2 ("Payment Services Directive 2"). Even if you are happy with accessing the bank via browser on the computer, you are going to need the second factor for auth, and SMS isn't going to be it.

Because it is pushed centrally, banks do not have a choice. Hence, you as a customer, won't have a choice either, unless you consider not using the bank online at all as a choice.


Actually, the EU is being used as a scapegoat here (as usual). SMS is perfectly allowed by the directive. As would be even a old Google Authenticator-style OTP code which does not need any propietary software to work.

Banks are forcing you to run proprietary software on proprietary operating systems with draconian "security measures" that would make the latest DRM-enforcing-rootkit look like a children toy. They check whether your device is rooted, whether it has any non-Google-approved programs installed, whether Google Play notifications work, etc. And if you fail any of these checks, good luck using your credit card!

Open-source operating systems are basically dead in the water at this point, since failing to run these proprietary programs is not going to be a minor "I can't play this game" level- nuisance, but rather a life critical issue. And so far more and more banks keep enforcing these measures.

And for some reason there is no big outcry about this.

Even Korea's "all banks require ActiveX" situation was very mild compared to where we're going...


Moving away from SMS is good. SMS is cleartext, equipment to fake a number and get their messages is maybe hundreds of dollars at this point.

Encrypted push notifications are much better.

PSD2 lets you do basically whatever you want. Fingerprint is enough, or confirm in phone app if making a transfer from a desktop banking UI.

U2F would be nice but with banks being banks that's not going to happen this decade.


I hate to say it, but if you have a phone that you can flash, I sincerely encourage you to do just that.

Why? Because even with "Google" phones, installing pure AOSP cripples the phone (and by that mean SMS breaks with LTE, you lose voLTE, Wi-Fi calling, etc.) A lot of Android ROMS have to scrape official images to get the binary bits (and it is nor a fun needle in a haystack excerise) to get basically phone functionality in Android.


What is your point?

This kind of response completely ignores the fact that the vast majority of the drivers required to just run on modern hardware are closed source and that the vast majority of phones these days have their bootloaders locked.


> that the vast majority of phones these days have their bootloaders locked.

I don't know if that is actually still true. Back in the day nearly every phone in the US was bootloader and carrier locked. Now basically every phone is carrier unlocked and anything besides Samsung can have the bootloader unlocked very easily. I guess Samsung phones are the most common but there are certainly many other options that are more open.


This seemed unlikely since S10 is maybe the most mainstream flagship phone but it appears that Samsung does indeed make it painful to take control of your device: https://topjohnwu.github.io/Magisk/install.html#samsung-syst...

Many manufactures make it easy to unlock and root your device (shout-out oneplus), but many others do try to make you brick it if you try doing anything out of the ordinary. Like the HMD rebrands Nokia, Sharp, etc.


Oneplus requires you to wipe your phone to root it. Add to this that there is no way to backup the phone without rooting it.

Of course, everyone requires a wipe. That's to protect normies' data when they inevitably get their stuff stolen on a trip to Paris. Easy to live with, just root it first thing after unboxing.

You can get the same backups you would have if you never rooted it to start with. I agree in some cases that's not enough but it's not no backups of any sort. Mostly just more hassle to restore.

Samsungs are locked there?

Here in europe, you go to developer mode, check the OEM unlock button, reboot and hold some weird button combination while booting, phone asks you again if you want to unlock the bootloader, does a factory reset for security reasons, another reboot, and it's unlocked.


Only by the letter of the law, the android that ends up on your phone consists of mostly closed source binaries from Google that you don't get without installing the play store as well.

You mean the Google add-ons to Android.

Regular Android works great in GrapheneOS/CalyxOS/other AOSP variants.


You may as well celebrate TiVos running Linux. If the device is locked down, it's hardly a victory that it's running obstensibly free software.

If you opt into Google's Advanced Protection Program you can no longer install apps from F-Droid.

Is there an easy way to make F-Droid install updates automatically? I use both F-Droid and Google Play on my phone but manual updates are a huge usability pain.

That permission is only available to preinstalled system apps. If you have root, you can install the F-Droid System Extension and it'll do all it automatically.

Otherwise: send complaints to support@android.com (jk, there's no actual support)


I meant 10% click the "About" button, how many of those actually donate is another question...

Jason was planning to challenge the App Store rejection after the fix for the WireGuard regression has been published, though I'm not sure what's the current state of the issue.

The rejection is wrong, because the App Store review guidelines clearly spell out that apps may request donations through Safari. On the other hand, apps cannot use in-app purchases to request donations, unless they are published by an approved nonprofit.

3.2.2 Unacceptable

(iv) Unless you are an approved nonprofit or otherwise permitted under Section 3.2.1 (vi) above, collecting funds within the app for charities and fundraisers. Apps that seek to raise money for such causes must be free on the App Store and may only collect funds outside of the app, such as via Safari or SMS.

https://developer.apple.com/app-store/review/guidelines/


The wording is vague enough that having a link in your app for donations could easily be (and apparently is) considered a violation.

Having a link to an external web page to receive donations is not considered a violation on the App Store, this is a mistake by a reviewer.

Collecting funds "within the app" means that the payment flow is completed without leaving the app. They explicitly list two ways for any app to accept donations, by redirecting the user to an external web service opened in Safari, or by collecting payments using a text message.

You obviously have to somehow communicate to the user that donations can be made, and that is allowed to happen by showing an external link.


> "Having a link to an external web page to receive donations [by a registered charity or a non-profit] is not considered a violation on the App Store"

Which e.g. "PayPal@zx2c4.com" is not, clearly.

The words you are missing are important.

One of the reasons why I do not gift money to WireGuard developer(s) is that they have taken the steps to obscure where and to whom the money is going, which is in and of itself fishy. Just labelling something as 'donation' does not make it so.

[Edit: line breaks]


Why though? What do you forsee the issue being with where the money could be going?

If Jason is recommending a way to donate to the project, who cares where it goes? If he puts it straight in his pocket and uses it to buy pizza or a computer game, it's still serving its purpose as far as I'm concerned. I have donated, and will do so again, and I'm perfectly happy with the money being used that way.

In a sense, for me, it's a thank you for the work thus far, not an payment for more work.

I imagine many see this differently, so I'm interested to hear some other opinions.


Only nonprofits are allowed to use in-app purchases on the App Store, while other apps must use Safari for fundraisers, read the guidelines in their entirety.

> One of the reasons why I do not gift money to WireGuard developer(s) is that they have taken the steps to obscure where and to whom the money is going, which is in and of itself fishy. Just labelling something as 'donation' does not make it so.

Your remark about WireGuard developers being fishy and obscuring where the money goes is ridiculous, and the way you framed it, just... wow.


I actually read them, and they also happen to be quoted upthread.

3.2 Other Business Model Issues [list is not exhaustive] 3.2.1 Acceptable (vi) Approved nonprofits may fundraise directly within their own apps or third-party apps, provided those fundraising campaigns adhere to all App Review Guidelines and offer Apple Pay support. These apps must disclose how the funds will be used, abide by all required local and federal laws, and ensure appropriate tax receipts are available to donors. Additional information shall be provided to App Review upon request. Nonprofit platforms that connect donors to other nonprofits must ensure that every nonprofit listed in the app has also gone through the nonprofit approval process. Learn more about becoming an approved nonprofit.

3.2.2 Unacceptable (iv) Unless you are an approved nonprofit or otherwise permitted under Section 3.2.1 (vi) above, collecting funds within the app for charities and fundraisers. Apps that seek to raise money for such causes must be free on the App Store and may only collect funds outside of the app, such as via Safari or SMS.

It would appear that the current understanding is that if you are not a nonprofit, you don't fundraise within the app nor do you provide a link where you can transfer funds. If you are a nonprofit, you can register through the nonprofit program to use Apple Pay (which comes with actual checks of the status). This matches the intent every other point regarding payments, where soliticing money from within the app, even by way of link, is generally prohibited unless specifically allowed under one of the small list of exceptions. Remember when "reader" apps also had to remove links to purchase individual items and replaced it with, at best, "visit our website"? Same intent, same result.

As for fishiness, compare these examples: * Signal Technology Foundation is a registered nonprofit foundation, I can check if the money is going to development of Signal (it is). They even do it right by providing the EIN so it is trivial to check. * Mozilla Foundation is a registered nonprofit foundation, I can check if the money is going to the development of the browser (it is not). * WireGuard developers decided it is important for them to keep the information where their business is located private (this is what I am referring to as fishy: I would challenge you to find where that particular "Edge Security" firm is actually operating, as a company, or what zx2c4.com is beside a name that Jason used to tag some files and host a domain, and both are used as "this project is from") and to keep the profits.

See the difference? Two are genuine nonprofits entitled to donations, one is a business disguised as one (how much money that business makes is immaterial, it could be $1, it could be millions - I sincerely wish them the latter). Every developer has to make a living somehow - or at least recoup some costs, for FOSS projects - but this is not the way to go about it if you want to claim moral high ground over Apple.


I'm confused. Wireguard and Jason/zx2c4 are not a non-profit, nor do they advertise as one. Why are you making it sound like he is doing something nefarious?

The argument for the ruling being bad is: the app links to the wireguard webpage (not within the app) which contains information on how to donate. That's like if in my app, I linked to my twitter profile, and my twitter profile contained a link to donate to me. It shouldn't be a problem.


If you are a business, wth a few defined exceptions ("reader", multiplatform, _physical merchandise from outside of the platform_ etc.), you accept payments through Apple Pay, don't direct people to your website to to send you money regardless how you decide to call it and pay Apple the cut they desire. FOSS developers are still businesses, not charities, much as we like to pretend otherwise - and "tips", "donations", "patronage" and similar verbiage does not change that.

If you are an actual nonprofit, you get to ask for donations both via app and your website and have Apple not take the cut.

Don't like it - don't deploy on the platfrom, but if you persist you will soon run out of platforms. Note that particular point has also caused WireGuard to be delisted from Google's Play Store before so it should not come as a suprise to anyone (https://news.ycombinator.com/item?id=21268389).

Note that some of those distinctions are legal - where I am, I need to know if I am gifting you money or donating to a nonprofit to report it on the tax record (and I certainly need to know if I were to get my own limited company to "donate"), as going above certain limits makes _me_ liable for tax on gifts as well, including reporting who the recipient is. "I sent that money to a random functional email PayPal@zx2c4.com I can't say much about" does not cut it. Yes, Jason might be at the other end of it - but as is, it fails the smell test compared to other FOSS projects. Simple as that.

Can we go back to discussing why Apple is bad due to their ever changing APIs, general disregard for backwards compatibility and for that matter general compatibility with anything else and not one of the few things in the whole process that make sense? Or, for that matter, why Google effectively making GMS and locked bootloader a requirement for corporate and/or finance apps is ensuring that in many areas the existence of unlocked devices/alternative AOSP distributions is and will remain a fig leaf purely there to avoid being considered the one true dominant player?


> FOSS developers are still businesses, not charities

I mean, maybe in a technical sense? But the ones who publish these apps are usually just "non-profits run by single individuals who can't afford all the bureaucracy required to run a non-profit."

Keep in mind that FOSS apps like WireGuard are 1. entirely free, 2. with no ads, restrictions, or nags to donate. There's nothing you get from the app, or from the developer, by sending them a "monetary gift." Other than the fact that you can't claim it on your taxes, they're effectively working for a non-profit that produces this software.

If you consider someone offering a link to send them "monetary gifts" to pay their own salary to allow them to continue to work on an app they don't charge for, "a business" — I'd hate to see what you call a church, or a library, or PBS.


PBS (and BBC in the UK, and other equivalents) enjoys extra privileges to accept tax-free funding in exchange for the mandate or promise to stay non-commercial and not give priority to specific donors' requests. [0] Libraries, should they accept donations to operate (or public funding!), accept some restrictions as well. There are commercial libraries as well, incidentally, which don't get to accept donations, but are funded by some associated commercial business - my local bookstore had one before the current pandemic has started, though it is unknown if they will continue to have one by the time it ends.

Churches are "complicated" - and less said about the funding the better, especially in context of the US. Suffice to say I very much prefer the German model - which happens to come with quite stringent accountability requirements.

I have no problem sending money in appreciation for the work with no expectation of any return on it (not even a tax deduction). I do not have a problem with someone making a profit on those "gifts" - I wish them all the best, in fact. I do, however, firmly believe that you can't have your cake and eat it too: you receive the ability to accept donations in a way where you enjoy various exemptions (in this context, from Apple/Google delisting you or taking their cut) in exchange for actually going through that bureaucratic rigmarole to get registered. It's not a $DEITY-given FOSS right.

Side note - as I wrote before, my local tax office would like to know who the money is going to, to either try to get their pound of flesh (cynical and realistic view) or to identify the money going to 'bad actors' (take your usual terrorists/criminals/think of the children BS excuse the politicians always make up to pass the relevant law), doubly so when the money is sent internationally - if I wanted to actually send an one-off gift to Jason/zx2c4, I can only assume he is not in my country.

[0] https://www.pbs.org/about/producing-pbs/funding-standards/


> I do not have a problem with someone making a profit on those "gifts"

You seem to be assuming, though, that "not being a registered nonprofit" automatically implies that there's some non-trivial probability that you'll be profitable.

Every FOSS developer I've met who is accepting "tips" for their work, is not anywhere close to "breaking even" from those tips (insofar as you'd treat the FOSS project as its own business with its own balance sheet, rather than as a marque of the owner's hypothetical individual-proprietorship IT consultancy.)

Sure, some of these are side-projects they do in addition to a full-time job, and therefore the self-employment-wages they get paid out for this effort are "pure profit" in the sense that they already make a living wage. But that would be just as true if they worked full-time for a business, and then worked as a part-time paid employee of a nonprofit.

Profitability of a FOSS-project-as-corporation, is what's left over after you pay yourself (the sole employee) out at a working wage for all the labor you put in. As such, in legal terms, these side-projects almost always would qualify as non-profits.

FOSS developers aren't YouTubers with a fanbase of millions and a platform where they can directly, incessantly plug their Patreon to that captive audience with embedded advertising. They're just people publishing apps, where the app almost never event hints at the "personal brand" of the developer.

And so, I think a critical difficulty in the communication here, is that you might be imagining this thing on the wrong scale. We're talking about maybe 200 people per year, sending the developer maybe $5 apiece. Not about individual transfers of hundreds/thousands of dollars; nor about enough transfers to pay a living wage. That's why it makes sense to call these monetary transfers "tips", rather than "funding."

And that's also, partly, why people are so confused/appalled — Apple and Google do not serve their own bottom lines by getting in the way of people "donating" to these FOSS projects. The labor-cost required to enforce this directive probably costs more than they'd ever make by taking a cut of these tips!

> in exchange for actually going through that bureaucratic rigmarole to get registered

It's not the "rigmarole" (labor), it's the cost. A nonprofit corporation is still a corporation — and most FOSS developers, as individual proprietors, don't receive enough in tips to actually be able to afford the fees involved in incorporating and registering a nonprofit.

(I mean, they can probably afford it themselves. But the hypothetical nonprofit that is the FOSS project can't afford to pay for it out of its own treasury. I.e., incorporation would just put the FOSS project further "in the hole" in being revenue-negative, and therefore in being worth the developer's time to contribute to.)

There's a reason that governments allow individual proprietors to just "do business" without incorporating: it's a fiscal stumbling-block that trips up the people governments most want to encourage to start businesses.

The same thing should be true for nonprofits/charities, intuitively. Even if there is no legal recognition for "individual proprietorship nonprofits", everyone acts like those are a thing. (They don't expect their donations to be tax-deductible, but most people in the middle class don't donate to formal nonprofits enough to realize "donations" are their own, tax-deductible, class of thing, separate from regular monetary gifts.)

And most of all, people expects corporations to go along with it — and most corporations do go along with it. Microsoft with Github Sponsors, etc. That's why everyone is so up-in-arms that Apple and Google aren't going along with it.

Of course, Apple and Google are technically, legally in the right — these are not donations. The problem is that common sense disagrees with the law: by common sense, these should be donations, tax-deductibility and all. If push came to shove, the law — not common sense — would be what bends. But nobody's pushed that far yet.

> Side note - as I wrote before, my local tax office would like to know who the money is going to

Is there some problem I'm not seeing, tax-wise, with sending small monetary gifts to people you believe to be individuals who are online acquaintances of yours (e.g. people you talked to on a forum once)?

If I want to send money to a FOSS developer, it's because I view them as, effectively, an acquaintance. Someone I'd buy a beer at a conference. By "donating" to them, I'm just buying this acquaintance of mine a beer asynchronously.

Most people make small monetary transfers to individuals they aren't sure of the identity of all the time. For example, buying hand-made jewelry at a pop-up street bazaar. There's no "business" name — it's just an individual proprietor — and you might never learn the proprietor's name, either!

Because there are so many situations like this that can arise in every-day life, it's never the job of private citizens to prevent money from being unknowingly laundered into the hands of trade-embargoed states or entities. It's not your legal civic responsibility to avoid shopping at a store just because you haven't ruled it out as being a money-laundering operation.

Instead, it's the legal duty of banks and payment processors — with their fancy KYC/AML databases — to do that: to identify the transfer recipient through network-analysis at point of fan-in. Money launderers aren't fought by starving them of demand; they're fought by deplatforming them from the financial system they depend on.

(That being said, if you were acting as your own payment processor, ala https://en.wikipedia.org/wiki/Hawala, you might be on the hook at tax time.)


So, is does this mean for a charity they take 30% also? For example, here's United Way for Chester County (wherever that is)[0]:

https://apps.apple.com/us/app/united-way-of-chester-county/i...

They have a donate button (last image on right). Does Apple take 30% of all that is donated? If so, I find that to be repulsive.

[0] I picked Unite Way because they're a large org, not because of any other reason.


Not sure about Apple, but I know Google has special treatments for formally registered 501(c)(3) orgs and they are allowed to seek donation directly without going through Google Play's commission.

Update: Apple Pay appears to have similar policies [0].

[0] https://developer.apple.com/apple-pay/nonprofits/


What if the non-profit is located outside of the US (and is considered a non-profit in its local jurisdiction)? Do they need to apply for a 501(c)(3), that is if they even can?

"proof of registration with the relevant country's regulatory bodies and authorities" also counts. You can read that HN discussion about donations in FOSS apps in my original comment, link [0].

Lol does that mean Ikea can sell on iOS without fees?

Same for Signal? They have a donate button in android app.

Signal is actually registered as a non-profit (which means accounting for where the money is going as well), so iOS version is perfectly fine to have "Donate to Signal" link opening in Safari.

I couldn't agree more. You're not paying for the app, or the service, those are free and you are simply making a donation.

I can imagine that Apple may want to define 'FOSS' to some extent (donations need to go to a non-profit with a board, software needs to be licensed under one of the following licenses, etc), but there should be some room for supporting FOSS that is included in an App Store.


> Apple may want to define 'FOSS' to some extent

"The stuff we won't pay for, but will make other people pay for, even tho we did nothing for it"


"... therefore we should take our cut."

Funnily enough that’s how everyone views FOSS including us HNers and developers.

Yeah, I can imagine that payment links can potentially be used as a loophole for selling unauthorized in-app payment items outside the store. But this is not the case here, nothing is sold, it's literally only a link to the project home page, https://wireguard.com/donations/.

Simple solution, there are human reviewers for this kinda reason and if the rule is "Open Source Apps get a donation button" then not any random can loophole around.

Heck, if both Apple and Google offered a solution by which you provide the source code to build, any necessary secret variables for the build and then it gives you those extra privileges, it would be nice. But that costs money the open source apps don't have.


Apple could win a hole lot of points here by processing the donations themselves. The upside for them is that it would close the loophole.

Only if they don't take a fee, to effectively steal donation money for themselves.

I think Apple/Google see that as a distinction without a difference. You're providing thing, the app, and because of that app and via that app people are giving you money. And since you're not a registered charity they want their pound of flesh.

Ive got a dumb phone and an awesome laptop, fuck the apple and google duopoly and their overpriced locked down ecosystems!

As a Russian movie quote goes, [after someone disapproves of a pair of boots] "Aha, so the boots are good, gotta buy them".

On the flip side, Apple is hosting and distributing this app for free

This could be normalizing effort; no end runs around allowed in software from our repo?

It’s rather our fault though, yeah? For popularizing their kit and agreeing to pay for “package management as a service” as devs in the first place.


IANAL - but I'm pretty sure the app platforms are breaking many laws here, not allowing people to freely donate. Like free speech, able to ask for help, freedom to do business, abuse of monopoly. They might be able to get away with a transaction fee, and a store fee, but they should not be able to censor text, links, etc. This is the new Mafia. If you don't play by their rules (theirs, not the law) your business dies!

Yes, you are obviously NAL. The rules are clear and are applied evenly; it is the even application of the rule that is causing the problem here. FOSS-advocates think they are special snowflakes who deserve an exception to the rule about asking for payment. The app stores (both Apple and Google) clearly disagree and think that this is something that will be easily gamed and abused.

Nothing is preventing these apps from simply saying 'if you want to learn more or support our project go to <some top-level URL>' instead of directly linking the URL to a donation. Do that and there is no problem.


The Apple guidelines clearly state that donations through Safari are allowed. Nobody's being a special snowflake here, much to your chagrin I'm sure.

I have certainly heard of apps removing all links to their website because Apple reviewers have followed a help/feedback link, gotten to their main website, and then found purchase/donation links there and rejected the review.

Any references for this? I have only heard of this happening when the page is clearly for donations (like this case) or almost exclusively composed of 'give us money' content.

https://news.ycombinator.com/item?id=24192021

1. App links to developer's blog. At one point the top post is about their patreon. Apple removes app until post is amended.

2. Also apparently the bandcamp app has no links to their website, for the same reason.

https://news.ycombinator.com/item?id=19378914

Amazon Kindle app could not link to amazon.com as users could purchase books there without giving apple their cut


Amazon.com is nothing but a sales site so I cannot imagine why anyone would think it is anything other than a path to try to route around in-app purchases, same with Bandcamp. The one with the developer blog and a patreon link is a lot weaker, but the other two examples were explicity not allowed according to the rules at the time.

FOSS developers should simply stop developing good software for Apple devices.

The absolute opacity of Apple's technical policies and their arrogant i-dont-care/its-your-problem approach against developers are quite renewed in the community. This ends up costing a lot of development time to developers who mostly work for free, who struggle to reverse engineer or debug what happens on MacOS/iOS, and (like Wireguard's case shows) it harms the reputation of their software because people tend to blame the application rather than the OS when things don't work as intended.

If people want to use FOSS software, then they should be able to do so on systems that support the FOSS ecosystem, that provide developers with appropriate tools to debug what's going on (ON ANY PLATFORM) and sufficient documentation for them to understand how a certain component of the OS is supposed to behave.

I know that in the past 15 years lots of tech-savvy people have opted for Apple products because "they're still UNIX under the hood, and unlike Linux they just work out of the box". But being Unix-like DOES NOT mean to be developer-friendly! Apple is still an opaque developer-unfriendly company even if it provides you with a native bash!


> I know that in the past 15 years lots of tech-savvy people have opted for Apple products because "they're still UNIX under the hood, and unlike Linux they just work out of the box". But being Unix-like DOES NOT mean to be developer-friendly! Apple is still an opaque developer-unfriendly company even if it provides you with a native bash!

That was true over 10 years ago (was certainly a big factor for me), but i'm not so sure it is for most people anymore. I remember back when I bought macs (more than 11 years ago now) they used to proudly advertise their "UNIX" certification and tout the BSD/Mach origins, I think this is when most of the original OS team was still there.

But today it seems to be one of the most neglected aspects of the system. Each time one of my colleagues with a mac tries to run one of my considerate bsd/gnu friendly scripts I discover most of their userland has not actually been updated in 10 years. I end up getting them to install brew and replacing every binary used in the script... and yet bizarrely things like ZSH suddenly pop up as the new default shell.


I’ve been developing for Linux using Macs for the last 12 years or so.

At first I was really into setting up everything just-so on the Mac, with an environment so closely mirroring the production servers that I was confident I could deploy stuff from there to staging.

But in the last few years, I ended up just having a reproducible set of dev and stage-like Docker containers. That way I can do all my coding in my nice shiny Apple UI, and all the build/test/run stuff happens in a place I have full control over.

This probably doesn’t solve everyone’s problems but for me it was the best way to have my Linux cake and eat my candy Apple too.

And yeah, the ZSH thing was super annoying.


Funnily enough, if FOSS developers abandoned the platform, Apple itself would make sure no programs could run after a few releases because they just love changing core APIs.

The iOS and macOS apps have been the biggest point of stress and frustration when building EteSync[1]. The API is buggy as hell and very limited (if at all available) and the review process is arbitrary and can cause updates to be rejected. You can never know if your workarounds will be accepted or rejected. Sometimes they can even get rejected in future app updates.

The EteSync experience is subpar on Apple devices, and there's almost nothing we can do about it. We already spent countless of hours trying to fix things, but Apple just make it impossible. We have more ideas on how to fix things, and we will keep on trying, but it's beyond me why would anyone willingly use an Apple product.

Edit (adding one more point): that's one of the more annoying parts about Apple being the gatekeeper to 40% of the US population and in effect, to 100% of businesses (because one bad Apple in the org is enough to spoil the whole bunch). As a developer, you are just stuck with no way out.

[1] https://www.etesync.com


> it's beyond me why would anyone willingly use an Apple product

Final users don't see this mess.


Hiya! Former mac native developer here, moving to a new company. My new corp gave me the option of a thinkpad running windows or a Mac, and I chose the mac just so I could have a sane terminal experience, UNIX-like tools, etc.

I would vastly prefer to use Linux, but unfortunately that's just not an option for a company-issued machine at this juncture--and in my experience it's easier to spin up a VM on a Mac than a Windows box.

Being a Mac native dev, I'm very acutely aware of the pain other devs go through with Apple and their APIs, but unfortunately Macs remain a better platform to write code on in my personal experience.


My experience is that Windows Subsystem for Linux has been amazing on Windows and just keeps getting better. I've also never noticed any difference in spinning up VMs.

But anyway I get keeping with familiar tools but, I just disagree that MacOS is a better or even "sane" terminal platform. All the ancient GNU tools Mac ships and BSD-style "but Posix!" pedantry drives me up the wall.


In my personal experience, git crashes about 1 in 3 commands I run on windows. Haskell takes ~10 times longer to compile on a ~4 year old desktop windows machine than a ~6 year old mac laptop. And I usually spend hours trying to get simple tools installed, vs. minutes on macs.

> git crashes about 1 in 3 commands I run on windows.

I've been using git over 2 years on windows with no issues at all, it seems you have a buggy version?


Definitively a local issue between the chair and the computer.

The whole developers world would be up in arms if Git actually crashed in 1 out of 30 commands on Windows, _whatever the configuration, git bash, powershell, or WSL 1/2_. There would be yearly top hacker news post about "one year and still not fixed"

Heck, Git would not have reached its dominant position if it was such a buggy mess.


Are you using windows git, or linux git inside WSL? The latter seems a lot more reliable in my experience.

I have not used a current version WSL, but it was terrible when I tried it. Could not find files saved in the WSL terminal in explorer (I understand that is a limitation). The was so much unknown going on in the "integration" that I wished I just used a VM and took the perf hit instead of digging to figure out where Windows was mounting the FS and figuring out permissions.

I have no desire to look at WSL ever again.

I experienced the same thing with on F# on mac a year or so ago, the dotnet CLI tool was effectively broken and official onboarding docs didn't work.

I tried revisiting when they announced F# 5 late last year, but same thing, docs don't work/broken on Mac. Turned me off for F# development and leaves me a bad impression on anything Microsoft releases.


WSL2 has fewer "magic unknowns". WSL1 used the NT Kernel emulating the Linux kernel so there was a lot of (seeming) magic in that interop, because it relied on low level NT details that don't look like "normal" Windows to Windows.

The files, for instance, were stored in NTFS but with Linux metadata in alternate data streams. Akin to what macOS used to call Resource Forks, except alternate data streams are far more rare in Windows and most native Windows apps trample over them. Microsoft didn't advertise where to find those files specifically because they didn't want people using Windows apps on those files and breaking Linux metadata. Instead, Microsoft heavily encouraged using /mnt/{drive letter}/normal/windows/path (like /mnt/c/users/me/Documents) and normal Windows paths and keeping files you worked on in both environments in the Windows plain old NTFS without alternate data stream weirdness side (because those /mnt drives didn't use the Linux metadata alternate data streams).

Eventually, Microsoft added a Plan9-based file server to WSL1 serving on the \\wsl$ system path for browsing those files and some smarts around it. (Launching a Windows EXE from a WSL terminal would convert the Linux path to the \\wsl$ path for instance.)

WSL2, on the other hand, is an extremely lightweight (Hyper-V based) VM, uses a real Linux kernel, and generally uses VM tech. Files are stored in a standard VHD, which can be explored with plenty of VM tools (including Windows File Explorer). They are still accessible in File Explorer through the \\wsl$ service. (Though in that case Windows can mount them using standard VHD mounting. The direction of the Plan9-based file server winds up reversed from WSL1 in that it is used instead by the VM to access host machine files through the VM barrier.)

As for F#, F# itself is an open source project with possibly a lot more of a "community project" mentality than it is an "official" Microsoft release. I don't know if that changes your opinion, but it is one of the projects where Microsoft has best embraced open source. (Including some of the potential downsides of open source, like needing Github Issues filed on broken documentation or it will go unnoticed/unfixed.)


You can literally just run 'explorer.exe .' in a wsl1 shell to get an explorer to show up in whatever directory you are currently in. The wsl files are not hidden from windows, and can be edited from there just fine.

F# (and most of Dotnet core) is also a mess on linux, so no surprises here.


> Could not find files saved in the WSL terminal in explorer (I understand that is a limitation). The was so much unknown going on in the "integration" that I wished I just used a VM and took the perf hit instead of digging to figure out where Windows was mounting the FS and figuring out permissions.

You can explore the files stored inside wsl partition by going to \\wsl$ using file manager.

You can now also mount an external drive formatted as ext4 directly.


In very recent versions of Windows 10 WSL will even add directly to File Explorer a shortcut in the usual Locations pane (left-hand panel with quick folders/PC/whatnot) to \\wsl$ with a Tux icon. It's amusing seeing Tux every time you open File Explorer, and possibly even more amusing that Microsoft is installing that shortcut themselves.

Compilation is the bane of my existence on windows. I have a few large cross platform projects (using CMake) I work on (at work), and the builds on Linux are a night and day difference. My 16 core Linux workstation does the build in like 80 seconds, and the same machine booted into Windows takes 15 minutes.

The developer experience on my Mac is IMO vastly superior to that on my Windows machine with WSL because of the complication of configuring IntelliJ products to use environments in WSL. When I use VSCode, the experience is about the same in both machines.

Fair enough! I have run into an annoying number of issues that were because the flags for `cp` varied from mac to other *nix systems, which was very annoying to debug.

You should give Windows Subsystem for Linux a try. It's what I'd choose in your scenario.

https://docs.microsoft.com/en-us/windows/dev-environment/ove...


I'm heavily invested in Linux for years already, a i3+terminal+firefox+emacs guy.

I forced myself to work on Windows 10 Enterprise for a week and left kind of feeling OK about it. It's a bit slower than Linux, a bit too many moving things by default and I definitely prefer the env vars and config files over registry and control panel. But. I didn't use WSL or WSL2. I just had nushell and Microsoft's terminal app, with winget and all that. Some keyboard shortcuts and multiple desktops enabled, writing Rust software with emacs, firefox and a good terminal was not bad at all. I would not dislike working more in there, but in the end find Arch Linux to be the end game OS for me, so keeping the installation just when I need to debug some Windows issues.


I actually have been trying this recently! I've been using VS Code via SSH into a WSL2 container running on my windows box and it's been going surprisingly well.... but that was after a moderate amount of effort to get WSL2 working to begin with, which was partially complicated by my past efforts of getting WSL1 to do similar behavior. I'm also not 100% confident NewCorp's IT would be kosher with me spooling that up. I could be wrong, but it seemed easier to go with the lower-number-of-abstractions-to-get-an-acceptable-experience via mac at the time.

Though who knows! Maybe I'll change my mind and get a new machine :)


> that was after a moderate amount of effort to get WSL2 working to begin with, which was partially complicated by my past efforts of getting WSL1 to do similar behavior.

Could you explain more?

I know installing and switching to WSL2 isn't as straightforward on windows stable. Is that what you are referring to?

If so, on insider - you can run wsl --install and it will work.

If not running wsl2 by default, wsl --set-default-version 2

I think they could make it easy to onboard users by setting better defaults and decreasing friction.


I had to fight with enabling/disabling Hyper-V in windows features for a while, and also somewhere I flashed the BIOS on my motherboard and it reset my virtualization-enable switch to "off" (which I guess was the default?)

50/50 PEBKAC and Windows being difficult, IMO, but my total unfamiliarity with troubleshooting windows made the process a bit more annoying than I felt it ought to be.


There is the other issue that Windows is full of spyware. Most of the mac's telemetry is inadvertent and leaks much less data to the OS vendor.

I would assume any IT-issued devices are full of spyware regardless of OS vendor.

I chose the mac just so I could have a sane terminal experience, UNIX-like tools, etc.

Well, that’s on you. You could have had WSL2 which is amazing.


While I think WSL is an option worth investigating, it is not the answer for everyone.

I jumped from XP to Windows 10 with WSL1 and had used Linux and macOS in between. It took me a few days to come across a bunch of pain points I was surprised had not changed; I do not like the install/uninstall scatter-shot method, monthly reboots for updates, control panels feel like archeology digging older UIs for settings, the window freezes and I cannot resize/minimize when the app is busy, I do not like Explorer or the windowing UI. PowerShell in practice seemed too verbose for interactive use and the learning curve/adoption was too steep to be productive (everyone else on the small team was writing BAT files). I got tripped up by odd things like offline documentation and you had to wrap it in a BAT file to automate it. I also don't like compiling stuff for Windows. I don't begrudge anyone who likes Windows, but I have a very strong preference for the other OSes. I might have some of those details wrong, but that's what I remember from the transition. I wished I had kept a diary because I forget a lot of it now.

WSL (admittedly v1) was a bit odd and hefty to install. The account/permissions and locations of files was awkward. I found myself ssh-ing into a Linux box to do a lot of things.


Yes and that's not vendor specific for sure.

I occasionally look after a fairly large Windows WPF application which is half integrated with Microsoft Word and there are hundreds of lines of code dedicated to quite horrible workarounds for issues caused by API changes and weird ass behaviour. There are a lot of if statements for different Word versions as well.

For example: when saving a file "safely" (i.e. without weird ass side effects such as locking or document metadata corruption), if your word version is 7, 8, 9 or 10 you must use SaveAs2000 API call. If your word version is 11, 12 you must use SaveAs API call. If your word version is any other one then you need to use SaveAs2. This is entirely not documented past telling you that you are told not to call half of them and most of the reasons behind using them were discovered by taking the VSTO libraries to bits.

At the end of the day, the objective is to make sure the end user never sees the hell you had to go through and entirely takes your efforts for granted. They don't care and efforts to appeal to them are frowned upon, even if we whine and complain about it in our own circles.


I also had enough, I now consider the Apple ecosystem a legacy platform, similar as Internet Explorer in the web world. I still do port my software but as a "best effort" scenario, nothing guaranteed basically, their ecosystem is too much out of touch with proper development practices to be able to guarantee anything, and I do warn people that I cannot guarantee much as well.

I'm sure there's going to be some people annoyed just by reading that but if you dabbled just a bit into their ecosystem, you'll certainly know why I have this opinion.


But it seems they do, eg. rachelbythebay stopped using Wireguard because of the mess.

she stopped using Wireguard (and ranted about it) rather than stopped using Apple's products (which are ultimately responsible for the failures she complained about in Wireguard)

Right. And Rachelbythebay is way more technically inclined than most users; if she wasn't able to correctly apply the blame to Apple, then normal users are definitely not going to be able to do that. Developers need to be more up-front about why these issues exist, we need an education push.

For all the criticism about how Fortnight framed its issues on iOS (and some of that criticism was warranted), coming out of the gate strong with a consistent message that Apple was to blame was likely the only way to get any 'normal' user to even consider that there were multiple issues and viewpoints at play. There's no such thing as subtlety or nuance when you're trying to talk to that demographic about why their phone/desktop doesn't do the thing they want it to do.

In the long term, I don't know. On one hand, these issues do affect final users, but communicating with final Mac users is difficult.

But on the other hand, Wireguard isn't going away, it's a clearly better protocol. So right now, final Mac users assume it's the devs' fault. But are they going to assume that when literally everyone around them has decent VPN clients and their Mac experience is just miserable? Mac users aren't completely isolated from the Linux/Windows world, at some point they're going to realize the pattern if all of the software on their platform is just worse.


> if she wasn't able to correctly apply the blame to Apple, then normal users are definitely not going to be able to do that

This isn’t a moral judgement. I apply the blame to Apple. But I also choose to keep using their product. Their products are less dispensable to me than another VPN protocol.


> But I also choose to keep using their product.

I think the issue is less people who understand the tradeoffs and decide that the Mac platform is still worth using -- it's people who do not understand that there is a tradeoff at all, or who think that the root cause of all of this is just the developers being lazy.

If you're aware of the reason why Wireguard can't do updates while it's running, and you say, "that's fine, I still want to use it on Mac", that's a very different reaction than saying, "the devs don't know what they're doing."

I suspect that average nontechnical users are currently in the latter category rather than the former, but I could be wrong.


People have been choosing usability over security forever - don't be ashamed.

It's funny because the reason anyone cares about this whole episode is that some people felt the need to play a white knight in the developer's mailbox.

The smarter people will quit the Apple platform, and the dumber ones will quit the software whose creators refuse to put up with the Apple bullshit (plus some that try to put up with it but Apple arbitrarily fails their review anyway).


You're mixing up intelligence with morality, or something similar to morality. Just because some interfaces are bad and the company is anti-competitive doesn't mean using it is a dumb choice, you have to weigh up the pros and cons.

Perhaps it's an axiom that the open alternative is better in the long run, but that's too long a run to really care.


It's gradually becoming a ghetto. They do somethings well, and at one time it was a much better experience than Windows, but I don't think I would say that today. When I replace my Macbook Air, it will probably be with a Windows or Linux device.

Until the give the app a poor rating, when ultimately the root cause is the arbitrary reviewer's decisions making a fix harder to make than it should.

It's not the user's fault, bit it's the developer taking all the heat while it's business-as-usual for the reviewer.


That's a fair point, I was picturing developers (who are Apple users) in my head when I wrote this.

"it's beyond me why would anyone willingly use an Apple product"

With respect, then, you aren't making much of an effort to understand.


I have an iPhone and macOS for development. I clocked a lot of hours on them over the years.

I admit, I was sometimes jealous of mac hardware, for example the new M1, magsafe, and etc (though not the terrible keyboards). Though I was never jealous of an iPhone's hardware. I was never ever jealous of the software. I always found it buggy and user-hostile.

The line you quoted was specifically about the user-hostility. You are using a machine that you can't control and actively fights you. It's mind boggling to me that developers agree to use such a system. Is this such an unreasonable opinion?


My Macs and my iOS devices are neither hostile nor obstructive to me. Again, if you are confused by this, you aren't trying hard to understand.

I control my Mac just fine. I've built tools from source; I run whatever I want; I can automate tasks I find tedious using the same shell tools available on Linux, and I still have access to MS Office (and no, open/FOSS "alternatives" don't work sufficiently well for me) and other COTS tools I depend on.

The Mac is absolutely the right platform for me, and I don't find it limiting or broken or hostile AT ALL. And neither do millions of other folks.

I also work regularly with Windows, and have a higher-end Dell XPS on my desk for that purpose. Windows is so profoundly broken and un-discoverable and inconsistent (not to mention unstable over time) that I cannot fathom choosing to use it over anything else -- and it's the only OTHER platform where I could get access to some of the tools I rely on. Linux isn't there, and hacks to try to make things like Win software run there imply a level of tedious fiddling that I'm 100% retired from.

>Is this such an unreasonable opinion?

I guess it depends on whether you consider an unstudied, single-POV opinion reasonable.


I've used both platform, and I find iOS user friendly and easy to use. I also found iOS easier to develop for than Android, though admittedly it's been a few years since I've developed on either. Opinions are funny like that.

I think it depends on what you're doing. Are you developing native apps with one or two person teams? iOS seems easier to start. Are you developing multi platform apps with teams of hundreds of engineers? Well, Android is much much better.

Just to give an example, it is quite easy to build Android apps in a CI, while iOS is a pain (specially because there is no way to build an iOS app in anything other than a Mac). Also, most bugs specific to a platform happens in iOS (they happen in Android too, but my experience is maybe 10 bugs in iOS for 1 in Android).


This sums up my experience developing on macOS as well. Apple forces you to use broken API's and then you have to find workarounds to make your app usable.

Someone should start an Apple developer support group on appledevsupport.group or something and get users to upvote broken API's (and broken terms of service: like mentioning donations are accepted in a free app!) that need fixing. Getting enough developers in one place to embarrass them might be the only way to make Apple care.

Filing onerous radar reports to help Apple is not my job.


I don't think I've ever run into a "broken" API on MacOS.

But I haven't seen a "well documented" one either. There's a lot of arcane knowledge in targeting MacOS.


I've run into broken API without even trying…core things in like AppKit and Foundation, even. Many of them get fixed, but I find it difficult to believe that you've never run into buggy API on the platform.

First off, what a level-headed friendly response from a developer who is clearly frustrated by Apple's bugs and policies. As someone who has had to support commercial software this is not easy to do consistently.

Second, this has significantly tempered my lusting over the new M1 macs. I think I can be content with my ThinkPad's running Linux.


This worries me for a similar reason - I get requests to port some software I wrote over to the Mac from time to time, and the new M1 Mac Mini is cheap enough that I might have bought one to do this development. But I'm not keen to spend any money or time on an ecosystem which might be closed down in the future.

I fell into the same trap a while back. Bought a mac, fixed some OSS I maintained (and I do note the documentation was quite crap "Well, Apple. I made it... despite your directions"), the next OS X update killed it again, gave up, sold the mac.

Felt like an enourmous waste of money and time.


> Felt like an enourmous waste of money and time.

And it certainly was. But sometimes you have well-appreciated macOS users that you have not yet managed to convert out of it. In that case, instead of throwing away your money you can easily [0] install a Catalina vm inside linux or windows. With a quite small effort, you can readily check that your program compiles and runs on that shitty system.

[0] https://github.com/myspaghetti/macos-virtualbox


Is it legal? I thought you can run MacOS only on Mac hardware.

This is a TOS problem that I could personally not care less about. The bigger issue is that even though you're running in a VM, you're not going to get all the necessary hardware working for Mac OS. For me, I couldn't get my graphics drivers properly set up and as such couldn't get any OpenGL stuff to work as it would be on a real mac, so it was a no-go.

At least you can XCode working and do macOS builds.


It's against the Terms of Service, which may or may not have legal implications based on where you are. However, Apple doesn't really give a shit unless you're going to profit off of it. The Hackintosh community has been around for ages and Apple doesn't do anything unless someone starts selling pre-installed Hackintoshes.

I don't see how such a thing might be illegal, but the current century never ceases to amaze me. In any case, it is just a (very popular) shell script that downloads a few publicly available files and runs them in a controlled environment. It does not harm anybody.

It's technologically doable, but running MacOS on non-Apple hardware is against the ToS.

Is it? Anyhow, it does not mean that it is illegal, which was the original question. I guess most ToS are not enforceable in practice. The worst that may happen is that you "lose the warranty" of your macOS install and you cannot ask Apple for support. No big deal.

So I'm not an expert, but isn't it still simply pirating software? I mean what's the difference between this and pirating Photoshop for example?

Adobe sells Photoshop, Apple does not sell macOS (and freely publishes download links for the latter.)

Apple does sell macOS (as a part of MacBook, iMac etc).

The difference is that the cited shell script downloads software that the copyright holder himself makes freely available.

It is like downloading binary freeware.

The ToS are a separate issue, but I doubt they'd hold in Europe for example.


Aeah, how much more proprietary and strange are the Apple API's going to get? They'll have control over the entire vertical, and can put all kinds of undocumented crap right in the silicon.

even to the syscall level, like the MAP_JIT flag to mmap() https://developer.apple.com/documentation/bundleresources/en...

not optional and requires special app entitlements to enable. So you are not going to write portable code that has a JIT without apple-special code.


And that JIT has additional considerations on Apple silicon, where there is specific hardware that needs to be taken into account: https://developer.apple.com/documentation/apple_silicon/port...

I ran into another quirk with MAP_JIT recently, but going the other direction in time.

If you supported an older platform (High Sierra, which up until recently was... valid...), you would need to explicitly _not_ pass MAP_JIT into mmap there. It makes total sense once you find the bug, but it was also an easy one to overlook.

Tracking that down was kind of annoying.


A JIT is a major potential source of malware enablement and thus a security consideration.

applogies if its an ignorant question but, if the os had proper access protections, even with a buffer overflow or other exploits to an app itself, how can that enable malware just by having a JIT?

It cannot; Apple's security policy towards third-party JITs is misguided. Such a feature is useful if you are interested in providing defense-in-depth for a JIT that you have taken effort to secure and would like stronger, hardware-backed mitigations for. The API should really be opt-in for the apps that want it–the real consumers of it are going to Chrome and Firefox.

JIT requires bypassing exploit mitigations e.g. W^X. JIT doesn't make an app that's already been subverted any more dangerous than it would otherwise be, but it makes it easier to exploit the app in the first place.

Yeah, I'm wondering if my next work computer will be something different after almost 20 years of working on NeXT/Mac OS X/MacOS because I'm not sure general development will continue to be viable on the M1s.

Spent another weekend moving my wife over to a new Windows machine ... not interested in that environment.


> I'm not sure general development will continue to be viable on the M1s.

I'm not trying to carry water for Apple here but what types of development are you talking about that won't be able to continue on the M1? Sure a lot of stuff wasn't there at launch but it looks like even docker (which was speculated to take a long time to get working) is getting close to a solution for arm and x86 containers to run on the M1. Brew is another one that wasn't ready at launch but my guess is that within a year or so the M1 (or it's successors) will be nearly identical to my current dev setup (which is one reason I'm waiting for the dust to settle).


Maybe nothing, but every cycle this gets harder and how long I have to wait for the dust to settle gets longer.

I'm in the very fortunate position of being able to afford the luxury of running multiple laptops at the same time, and being relatively price-insensitive. I've supported and recommended Apple as long as I can, but they're repeating their core strategic mistakes when they were riding high in the Apple // era, and I've been to that rodeo before. This time, I'm getting off the bull before it gores me. Last time, I clung on like a limpet long past the time it made sense, and I'll pass that mantle to the younger generations who have the time and energy budgets to do so.

Apple's core strategic weakness is being the dominant market participant for too long. It is as if hardwired into their corporate cultural DNA is the absolute need to be the underdog. Once they dominate for awhile, they start seeking out easy answers, and it takes strong leadership that demands finesse, class and taste in solutions to steer them past the answers within their immediate grasp, and uncomfortably reach for the ones that pleasingly engage customers. This starts with their relationships with partners, then developers, then customers, then it corrupts their products, in roughly that order within their overall ecosystem. We have another decade or two to go before it gets that bad, if it gets that bad (I really hope I'm wrong, their corporate culture otherwise from a customer perspective is highly desirable).

I'm getting out while the getting is still good and migration paths are not quite so painful. Part of this is because the raw hardware capabilities of my dual-track alternative (Dell Precision 5500 fully tricked-out) are a quantum leap over Apple's offerings. I have simultaneously put up with non-Apple trackpads, keyboards and OS's on Wintel laptops I simultaneously carry (hazard of consulting) while my main daily driver is an Apple, so those don't faze me.

There was a brief, glorious period in the 00's when Apple locked in users by being a superlative superset of delighting capabilities above Wintel gear that compelled users like me to share with those who asked me about my quirky non-enterprise choice in the enterprise consulting space, "I use a Mac because it is a very good mobile Unix slab", and they came away impressed and agreeing with the choice, "if only we had the money". As a consultant, I got a pass for having the money to make that choice. Mac laptops for a brief 2-3 years had the densest memory, mass storage and top-of-the-line mobile chipsets, making many light "server-like" tasks upon it feasible. I heavily leveraged those capabilities to run rings around other consultants, able to deliver results in a fraction of the time because while they were requisitioning servers, I was already coding, debugging and running tests. Haven't had that experience since.

I'm hoping I can catch some of that fire again with a Lintel setup. The general lack of developer infrastructure discipline I see across the board is leading many corporate cloud environments to enshroud themselves with all sorts of cost containment approval procedures, and most of my clients have already lost the agility cloud promised. Better security postures within my clients' sites also makes it increasingly difficult to access my own cloud accounts. So my own development deck once again makes sense for my own specific use case.


I'm being silly here but what if the Raspberry Pi became beefier over time? That would be a great platform.

I cross my fingers for a well-performing and open-source-hardware RISC-V CPU.

>from a developer who is clearly frustrated by Apple's bugs and policies.

Are there any developers who aren't?

>this has significantly tempered my lusting over the new M1 macs.

What sad is that when it comes to locking down computing devices Apple really is the vanguard of where things are going.


I'm going to bookmark this reply as an example of how to take feedback and respond appropriately. Jason's explanations both take responsibility for the issues at hand and provide adequate information to understand the difficulty in resolving them. He takes responsibility for a failure in review, which is a common problem I see in engineering orgs. I'm not an Apple user but I have a lot of love for the wireguard project (our company has donated) and the commitment shown here makes me confident that my feelings are not misplaced.

I was going to simply upvote this comment, but I'm chiming in to agree with you because I want to complement Jason for being the kind of developer that I really respect. He provides a tool that so valuable to so many and does so while dealing with a difficult set of requirements imposed by Apple. His response to a frustrated user isn't defensive but helpful and informative. Jason sets an example that the rest of us developers should strive for.

Precisely. Too often I see bad behaviour in open source communities justified with the lazy reply of "being nice does not produce good software" (multiple examples of this in yesterday's thread about suckless) and Jason's handling of this situation is a great refutation of that theory.

Going to chime in here as well. Jason's attitude here is commendable. I am going to add this to my collection of "things to read when I am unreasonably mad at something". Here is one from Greg K-H in case anyone is interested [1].

[1] https://news.ycombinator.com/item?id=25515566


Honestly, I don't get it.

Apple makes big money from their ecosystem. Wireguard developer provides high-quality solution for free, helping to grow proprietary ecosystem, essentially helping Apple to make more money indirectly and directly (by giving 30% from donations).

In return developer gets tons of hate from users and from Apple itself in the form of delayed reviews, rejects and constant threat of violating some rule and getting dev account banned.

In my opinion, the only solution for this is to stop providing services for free and put a price tag on the app.

I understand, that developer is a kind, not-yet-burnt-out person who wants to be the world a better place by providing the free way to exchange information securely, but doing so for free for corporate ecosystem is clearly not sustainable, neither financially nor emotionally.


Users demand it. You can't have a popular VPN app without Apple support (because at least one person in the org will have an iDevice), so you have to do it. I made another comment in this thread about my experience building EteSync.

That's one of the more annoying parts about Apple being the gatekeeper to 40% of the US population (and in effect, to 100% of businesses). As a developer, you are just stuck with no way out.


Oh you absolutely can. You'll lose 40% of your users, but for a free project, that shouldn't matter much.

Many apps (e.g. EteSync and WireGuard) are almost useless if they don't work for everyone within a certain group. A more extreme example is a messaging app. Will not having iOS support for a messaging app lose you 40% of your users? No, it will lose you 100%.

In WireGuard's case it's maybe less obvious than messaging, but if WireGuard doesn't work on macOS, it's enough to have one Apple user in your whole organisation in order to make it a non-viable solution.


What organization is it, that can't order an employee to use a different OS on a work computer?

When the employee is the CEO who wants to use his iPhone or an owner who wants to use her MacBook, the IT department bends.

And yes, the users are smart enough to see there’s an iOS client so you can’t just tell them “it’s not available”.


We're talking about an open source project.

So if bigcorp wants OS X WireGuard support, they should be able to pay handsomely for it.

If they aren't willing to pay, then I believe the project should just avoid offering it, to avoid getting burnt out from unreasonable requests.


> So if bigcorp wants OS X WireGuard support, they should be able to pay handsomely for it.

Who says they're not? A lot of the companies on https://www.wireguard.com/donations/ ship their own macOS software. Just because the Wireguard Mac app is free doesn't mean nobody's giving them money that's earmarked for Apple development.


Video editors, designers, and sound mixer are a few example professions where users mostly use Apple products. Most companies have designers.

Additionally, companies don't choose their whole software stack based on their VPN solution. They would just change a VPN solution if it's incompatible with what's there.


That was 5 years ago.

By now, video editors and sound mixers are heavy windows users, because there's no halfway endurable Apple machine that you can purchase that supports 128GB of RAM and 8+ CPU cores and NVIDIA CUDA. Because like it or not, almost all video editing plugins use CUDA for acceleration.

https://avid.secure.force.com/pkb/articles/download/Pro-Tool...

The industry standard for movie mixing supports: macOS Catalina (10.15.7), macOS Mojave (10.14.6), and High Sierra (10.13.6).

In other words, they didn't even bother with Big Sur yet.


> video editors and sound mixers are heavy windows users

Source? This is not reflected in any of the studios I know.


You'll lose more than that. If there wasn't a viable Apple solution, half my dev team wouldn't be able to use it, so 100% of my org wouldn't be able to use it because I can't maintain half a solution. You'd be left only with tinkerers. I'd say you'd have lost about 95%.

It's much less than 40% outside the US.

Does the free and open source Wireguard need to be a popular VPN app? One benefit of being more popular is that they get more contributions, but given that they barely get enough contributions to fix macOS-specific bugs as it is, it's not clear that the benefit outweighs the costs.

Apple and Apple users respond to tangible consequences; appeasement doesn't seem to be working, and it doesn't seem to be benefiting the project either. Like OP said, it's magnanimous of the developer to do this but I don't think "users demand it" is a great justification, nor is it quite in the spirit of open source.


Why build it in the first place if you don't want people to use it? Also, a lot of VPN services are moving to WireGuard, they will hopefully contribute to WireGuard development in the future. You can't really do cost/benefit assessment based on current contribution values. If you did that, no startup will ever start, and no open source project will ever be created, as upon creation the usage is almost always zero.

Windows & Linux users will still be able to use it. Most popular VPN services seem to develop their own custom desktop clients (they do this for OpenVPN); they will definitely contribute to Wireguard, but I'm not sure that they will contribute much to the desktop-specific parts of the "official" apps.

Edit: I should add that there is another cost/benefit assessment here: if Wireguard developers continue to appease Apple, Apple will continue to make life difficult for them as there will be no pressure for it to behave better.


My understanding is that WireGuard do _not_ give 30% of their donations to MacOS, so Apple are only indirectly making money from WireGuard being on their platform.

See:

> We faced rejections in submitting the app, because they decided to change their policy on the app having a link in the "About WireGuard" tool window to www.wireguard.com/donations/ (which they previously had allowed explicitly; now they want 30% or something)


Selling an app brings even more burden and responsibility than a free app though.

This appears to be a very typical response from an Apple user who doesn't understand the lengths and hoops developers have to jump through to work around Apple's many, many restrictions, bugs and limitations.

In my day job, our Apple developers have spent years finding solutions to iOS restrictions around CallKit, Push Notifications and NSTodaysProblem, and those are just the things Apple has intentionally restricted, once you get into the bugs and poor documentation for some APIs it's another story.

If our users knew the half of what our Apple Developers have to do, the meetings, discussions, concessions and re-design that has to be done to make things just work, even on par with the Android equivalent, they might be a little bit more understanding.

WireGuard has been excellent, and as a Linux user, I haven't needed an app, I have a couple of aliases in my shell to start and stop my tunnels. I've used WireGuard daily for work since lockdown and I used it daily for personal use, while commuting to work before lockdown. In all of that time, I've never had a single issue due to WireGuard (and there isn't even a Linux app to be seen). The expectation is often different between Linux and Apple users though.

When I was setting up for the first time, Jason even found time to help me himself on the IRC channel, something I've never expected, and for which I am eternally grateful.

I made a donation to WireGuard last year, I'll be doing the same this year and I encourage others to "put their money where their mouth is" and show a little support for the people making and sharing this software for free. I expect an Apple user can afford a small cut of their or their employer's money to do so.


I love Jason’s response and think it carries the right tone and is delivered near flawlessly. It’s clearly frustrating to deal with Apple’s platform lockdown, and he captures such in a professional and rational manner. Bravo.

What bothers me is that I’ve experienced an increasing number of maintainers of supposed cross platform projects simply not care about macOS anymore to the extent that they’re openly hostile towards macOS users. I know what you do is free and I have no entitlement to anything from you, but don't antagonize me when I add suggestions to open discussion and feature requests to your issue tracker to try and help participate in improving the way your project works on macOS. I’m probably willing to do some work but also need to get the lay of the land first.

I would challenge those maintainers to be honest. Yes, it’s your time, but if you’re not interested in spending it actually supporting macOS, don't market your project as a cross platform. Like it or not the macOS platform is changing and if you’re not along for the ride don’t grief everyone who is (either by choice or by requirement).

Just to be crystal clear: Json does not fall in this bucket, but this topic in general seems all too familiar lately.


You can be "cross-platform" in many ways. In practice if you don't run MacOS yourself, there's just no reasonable way to support MacOS at all. It literally costs hundreds of dollars to get a compatible test environment, while most other systems (including Windows) you can download and run a in VM for free.

In practice if the MacOS support takes more than a quick headers / types update, it will likely need more care in the future as well. That means you need not just a driveby fix, but a continued commitment from someone to ensure compatibility. This is not out of hostility towards the users, but I'll keep calling things that don't work on MacOS cross-platform. (Yes, it sucks; You can vote with your money to stop that situation)


> It literally costs hundreds of dollars to get a compatible test environment, while most other systems (including Windows) you can download and run a in VM for free.

Not even that; I've developed for Windows using Wine plus a mingw cross-compiler packaged by the Linux distribution I was using. Another alternative would be ReactOS in a VM.


agreed, as a developer i don't need an android device to test, just open a simulator and most things will work. on the other hand you cant even compile for ios with a linux/windows pc.

You can put OS X in a Windows or Linux hosted hypervisor, but the Apple doesn't want you to know about it.

You can, but it's illegal. You're only allowed to virtualise MacOS on MacOS host. You also have to obtain the system which as far as I can tell you can't buy anymore - you can only upgrade to.

Just because something is unauthorized or breaks EULA (mostly void here in EU anyway) doesn't mean it's illegal.

Even if you don't expect EULA to be enforced (will you pay for my lawyers/fine if it is?), you still need a copy of the system which you can't buy directly. You're left with unauthorised copies if you don't have any MacOS hardware and the same question - would you cover my legal costs?

You can download MacOS directly from Apple for free.

How do you legally download Big Sur without having an existing Mac machine? I thought that option was gone for some time now. A quick search doesn't bring up good solutions.

On the flip side, why would it be legal? It's looks like a pretty cut case of copyright infringement. It's their software, you're not authorized to use it, but you're using it anyways.

First it's illegal but secondly the performance is atrocious anyways (at least last time I've tried) so it won't even help you that much.

Hackintoshes break the TOS last time I checked.

Some stuff can be built for Macs from Linux, stuff like the Godot game engine supports this.

It is however a guess if they're going to allow that build or not.


Godot doesn’t build Mac binaries on Linux, the export templates provided include the platform native binaries.

> In practice if you don't run MacOS yourself, there's just no reasonable way to support MacOS at all.

I think this is the key insight. I tried to do a similar thing with Windows. The free VM expired every 30 days or so and bootstrapping a build environment each time (even just downloading it) sucked. The build environment is an outlier compared to macOS/Linux/Unix. I eventually ended up paying for Windows. I still couldn't test things like OpenGL inside a VM.


> while most other systems (including Windows) you can download and run a in VM for free.

For what it's worth there are many "click and run" virtual machine creators for OS X. It's not acceptable for corporate use because of the license violations, but to be honest I see very little issue for open source developers using such a solution if they don't have a Mac.


The problem is that you're not a reviewer at apple, or an apple lawyer...

> What bothers me is that I’ve experienced an increasing number of maintainers of supposed cross platform projects simply not care about macOS anymore to the extent that they’re openly hostile towards macOS users.

So blame Apple for it - why do you blame the developers?

Apple wants you to forget that it is the developers that add value to a platform, and yet it charges them for the "privilege" of creating apps for their platform. And then they are openly and increasingly hostile to developers who do not conform to their business model and do not want to pay them or distribute the app through their app store - and thus they keep crippling API after API to make sure that the developers toe their line.

It is because of Apple's hostile attitude to developers that they no longer want to invest (or rather waste) their time on Apple platform.

Here's a real life example of an app that is now no longer viable on macOS because it doesn't suit Apple's goals - https://medium.com/tripmode/apple-started-hiding-the-traffic... ...


My condensed point is that it would be both a lot more clear to users and a more powerful middle finger to Apple if projects just dropped support for macOS.

Apple isn’t feeling the heat for the dumb decisions they make with their platform, users are because they get berated as idiots for ever owning an Apple device by frustrated maintainers.

I mean I’ve seen things like “the problem is not the $99 developer fee, it’s paying it to Apple”. If that’s how you feel then my offer to cover the fee so your project can publish notarized releases isn't going to go anywhere and your project wont ever properly support macOS. Sorry.


While Apple isn't right on everything, they are a business, and they have the responsibility to decide what they will provide and what they won't.

If they can't change X because it will screw over critical application group Y, then developers can complain as much as they want until they have some practical way to deal with that. If they were constantly screwing over Y, where Y was different depending on the problem, they could eventually screw up all of the apps, users, and developers.


Yes, developers on Apple platform need to be more vocal with their criticism and, if necessary, even boycott their platforms to be heard.

These are people that are not Apple developers however, they're cross platform developers, and support Mac OS so long as the burden is not too great (or simply allow others to do the work of supporting Mac OS in some cases).

As a long-time Apple user, I agree with developers on this. Give it time and they will abandon the platform, which is not geared to be anything more than a vertically integrated channel for money. "but if you’re not interested in spending it actually supporting macOS, don't market your project as a cross platform" This is again Apple driven effect. Most of the Open Source projects are cross-platform because of Mac Os X, not what Mac Os is now. I advocate for Linux as a platform with real control over computing and hope developers realizing that this is a chance for Linux to become desktop heaven. My main workflow is design-focused and if software like Affinity Design or Sketch was available today I will remove anything Apple-related from my job.

There is a lot of graphic design and video professionals that will jump the ship. We have Blender, and Resolve is working under Linux, but Inkscape and Gimp are not capable enough to replace Sketch/Affinity/Adobe Illustrator/Photoshop.


I agree and I try to use Linux as much as possible, just to be clear. I want Apple to feel the effects of their lockdown on their platform. Right now just directing grief at macOS users who are trying to contribute to a project that claims support for macOS in their readme is not really fair. Give Apple the middle finger and drop support for their platform officially!

What average or semi pro user (the core New Apple User) have not contemplated is that technologies on a macro scale at the current moment are a step towards the political agenda of control of governments and corporations over people.

This is not a conspiracy. This is the official plan for the 4th industrial revolution by WEF. (https://tinyurl.com/yyfmj7gk). The goal is to abolish private property and live in a real time data driven world which is clearly a Communistic Agenda "The theory of the communists may be summed up in the single sentence: Abolition of private property." - Karl Marx.

In this context big corporations are cooperating with governments under supervision of WEF to implement general control with global AI infrastructure (actually there is EU program for supercomputers network already in place). Apple, Google, Microsoft and Amazon are part of this network of influence and they will sell user data to governments on demand.

The idea of personal computing without authorisation(Digital ID https://tinyurl.com/y5he2qr9) and oversight (telemetry) will be contrary to the values of the new Digital Utopia. Obviously big tech is politically driven and will be protected from scrutiny in the future in this context.

Literature: "A Framework for Developing a National Artificial Intelligence Strategy" - WEF link - (https://tinyurl.com/y6lwfdcy).


FWIW in the projects I've involved in we do get macOS-specific requests and reports from time to time but I have yet to see a macOS dev step up and contribute.

There is lots of cross-platform software, which works on Linux, Windows and even BSDs; you can't expect (or feel entitled for) open source maintainers to then also go ahead and buy expensive Apple hardware just to support their idiosyncratic almost-BSD-but-not-really-UNIX OS.


This is especially annoying when getting to the lower levels of programming. I'm maintaining a Rust client for SQL Server, and in recent OS X versions Apple decided with their secure framework to not support the measly TLS certificates of SQL Server (Azure, Docker). Now I have a ticket with no real help.

How I finally solved this is I got a Mac Mini from cloud, I could with a lots of trouble finally start docker in it (needed a desktop to click some icons) and test my code. This meant statically linking OpenSSL instead, which is not the greatest from a security point of view.

All of this took six months, and it was really hard to get Mac users to commit anything. It was ridiculously annoying to write and test without buying an Apple computer.

After this experience I just don't want to support any of their products anymore. Too much time wasted.


One thing I've noticed, as someone who's helped out on the macOS side of things for an open source project or two, is that the Mac/AppKit/Cocoa documentation issue is a barrier here.

There are absolutely OSS maintainers who wouldn't mind patching things for macOS... if they could figure out the expected behavior/etc. I've fixed things for projects that I only know about from plumbing around in AppKit for a few years now.


Being cross-platform is not the same as supporting every platform in existence

Perhaps they turn hostile because of macOS users. Such users have submitted sloppy this-works-for-me-style build patches to my project, which later were deemed incorrect by actual macOS experts. I had to do everything over again.

Then I was rudely accused of not using cmake, when autotools perfectly support cross builds (better than cmake on Linux).

It is not my problem if a purported Unix does not ship gcc or if clang cross builds are painful. Go and install gcc!

If Apple were interested in being supported, they'd fix their tool chain and provide free testing infrastructure to OSS developers.


> What bothers me is that I’ve experienced an increasing number of maintainers of supposed cross platform projects simply not care about macOS anymore to the extent that they’re openly hostile towards macOS users

This is not bothering. This is a very fortunate situation. I hope this process happens faster!

What I don't understand is your point of view. It is not these sane developers who are "hostile" towards users. It is Apple who is callously hostile towards users and developers. By degrading the macOS experience, these developers are making the world a better place.


>> if you’re not interested in spending it actually supporting macOS, don't market your project as a cross platform.

That is ironic, since for years I have seen "Cross Platform" to mean Win + Mac, and exclude linux users.

now that is Win + Lin due to how hostile the Apple Ecosystem is to anything "not invented by apple" and you want to blame the open source devs for that...


"Cross-platform" is not a promise that it will work on every platform, and saying that to be cross-platform without that including MacOS is "hostile towards MacOS users" is unreasonable. The most you can reasonably hope for, in something you can get for free, is that if it says it works on a given platform, then it is reasonably functional there.

You know, I thought I was the only one who felt this way - but it is really annoying.

I help out on an open source emulator/game project and wound up becoming the de-facto "Mac guy". I don't mind it, but I do find myself annoyed with the people who deride the platform for not being either Windows or Linux.


> I made a donation to WireGuard last year, I'll be doing the same this year and I encourage others to "put their money where their mouth is" and show a little support

Imagine, Apple even wanted 30% of any donations!!

> We faced rejections in submitting the app, because they decided to change their policy on the app having a link in the "About WireGuard" tool window to www.wireguard.com/donations/ (which they previously had allowed explicitly; now they want 30% or something), and then after removing that ... Well, finally they approved the fix ...


That is how you become a $2 TRILLION company. Nobody gets a pass on giving up the cash.

There really is such thing than too much greed though.

> This appears to be a very typical response from an Apple user who doesn't understand the lengths and hoops developers have to jump through to work around Apple's many, many restrictions, bugs and limitations.

Eh? Isn't that a description of the original complaint, and the 'a response' submitted here is from WireGuard creator/lead Jason/zx2c4 explaining much as you do the restrictions, bugs, and limitations he's tried to work around?


Apologies, I indeed meant the original post to which Jason was responding.

By "response" I meant the response of the user to the WireGuard Mac app.

Again apologies, I somehow jumped a few mental hoops of my own when commenting.


Ah, but the original post, which triggered the uninformed ranting against WireGuard, was not itself from someone who was ignorant of the lengths and hoops developers have to jump through to work around Apple's many, many restrictions. Furthermore, its author outlined how to work around the problems with the app by using Macports instead.

What about the problems? Well, it's free. They owe me nothing. But, you should still be aware what you are getting into when you choose to [use the app]. That's why I wrote this post: to serve as a warning to others. Let my frustration save you the same in the future.

When it comes to WireGuard, just stick with the tried and true low-level Unix approach, even on your Macs. Your sanity will thank you.

I just hope the iOS version never flips out on me.

Anyone who has a problem with that state of affairs has a beef with Apple, and should not be posting their displeasure to the WireGuard mailing list.


Agreed, the beef needs to be with Apple, developers targeting the platform are trying their best, and to say that they shouldn't support the platform if they can't deliver a quality product is disingenuous; you can have a quality product and Apple's policies and restrictions can absolutely destroy your UX; I've experienced this first hand.

It's not that Apple doesn't budge, if people shout loud enough; their Push/APNS change deadline was pushed back twice, it can happen again if enough people push enough for them to start treating their 3rd party developers like first class citizens.


Ah no worries, just misunderstood since between you and the submitter both sides got called a 'response'. Bloody English language, eh!

Yeah, the parent to your comment is discussing Rachel's post, not Jason's response.

I think he meant the author of the original blog post that zx2c4 is responding to.

>This appears to be a very typical response from an Apple user

Nothing Jason from WireGuard wrote invalidates anything that the original blogger wrote. The Mac App sucks and Jason merely explained why. In other words, both Jason and Rachel are correct.


> I encourage others to "put their money where their mouth is" and show a little support for the people making and sharing this software for free

Just went to donate for myself, and happened to spot Rachel’s name in the list of donors too, so that’s a nice little end to the story :)

(Not as nice as “apple either fixes their APIs or permits people to work around them”, but still...)


Also consider giving to Jason's Patreon[0]. He works on many open source projects including the original Git web interface and the `pass` tool.

[0]: https://www.patreon.com/zx2c4


I blame Google. Had they made Android good, they would've crushed the iPhone eons ago.

>If our users knew the half of what our Apple Developers have to do, the meetings, discussions, concessions and re-design that has to be done to make things just work, even on par with the Android equivalent, they might be a little bit more understanding.

It's frustrating, but it's also great job security.


This is a response to the Rachel by the bay blog post

https://rachelbythebay.com/w/2020/12/24/wg/

Personally I rarely use a mac, and don't do wg on demand, but one thing that did annoy me was being unable to set dns search domain, which wasn't mentioned in the blog post, but I believe is also caused by OSX deficiencies.


DNS search in MacOS is managed by their DNS infrastructure which is documented under resolver(5).

That lets you route the resolution of particular domains to specified nameservers. The files live in /etc/resolver but can also be manipulated with scutil.

So it's not an OSX deficiency, it's an OSX difference, similar to launchd vs systemd.


when I type "ping foo" or visit "http://foo", I want my search domain to add ".my.domain.com" to the end as configured in DNS.

I can do this on the OSX networking tab where I set DNS server, but from what I read that feature isn't available for the wireguard client.


As an iOS developer I can relate, Apple makes amazing hardware, but their software development is often meh. I don't think it's malicious, its just they have so many thousands of teams, often working independently of each other, and your experience with them is like dealing with sightless people describing an elephant. Some teams do amazing things, some mediocre, some downright awful, like any company, but exaggerated because of their central importance in so many other peoples/companies lives. Some of this could be fixed but even there Apple is a huge operation and executives are of all kinds. I work for a F50 company (non tech) with an infinite set of teams and execs and its another mix of amazing/stupid.

No one company can uniformly manage so much code and hardware to boot and do it perfectly. There are things Apple could do to make it less irritating—the hard problem is picking which subset of horrifically irritating things to fix.


> makes amazing hardware

Louis Rossmann would disagree


In case the author is reading this, I recently started using Wireguard in Mac OS with the Mac app and the experience has been great.

Not only is it much faster other VPNs that I used in the past, but compared to other clients (Forticlient and Tunnelblick), the overall experience feels much nicer, IMO.

Thank you so much for your work!


> Not only is it much faster other VPNs

IPSec is as fast as Wireguard. And there is native client in MacOS. As for bloated codebase, there is an OpenBSD iked rewrite.


iirc, ipsec is considered somewhat of a security nightmare by modern standards, given that it difficult to fully understand and very easy to misconfigure in an insecure way. I would only recommend using ipsec over wireguard when legacy compat matters.

It is. Even the companies I integrate with that require it know it's full of pitfalls. When you've been doing ipsec for two decades and it's a checkbox in your compliance sheet though, you check the box and hopefully you're good at it by now.

IKEv2 can be configured securely, but by someone that that is familiar with that particular minefield. Both on Windows and MacOS the GUIs configure weaker security by default (the cynic may wonder why!).

On MacOS you can use Apple Configurator /Apple Profile Manager and on Windows Powershell, to configure stronger security.

The nice thing with WireGuard is it’s either secure or it’s off.

As you say, it’s easy to misconfigure IPSec and the number of experts gets smaller day by day.


Doesn't IPSec need a "clean" network connection, without any NAT in the middle? Wireguard was designed to work well even in the presence of NAT.

In IKEv2 it’s optional but IPsec NAT traversal (NAT-T) uses UDP port 4500.

If you enable UDP encapsulation, it will work over NAT.

With IPSec native client in MacOS, there are several problems:

- multiple users on the same machine cannot have their own credentials for the same tunnel; you have to create several tunnels and each user sees all of them. Obviously, you cannot save password then.

- if you want to setup routing for your L2TP split-tunel, you have to create bash scripts (ip-up, ip-down) in /etc/ppp. Not even Linux makes you to do this by hand.

Compared to this, Wireguard for Mac is much more polished.


Why L2TP and not IKEv2?

Depends on the other side, too.

Otherwise, a good question for Ubiquity, why they don't support IKEv2 (among other things), when they are using strongswan underneath anyway.


Is IPSec as fast as Wireguard if I'm running it on a potato like a Raspberry Pi 2?

Yep

I wanted to add this. We have had a nearly flawless experience and the macOS app is really nice and polished. It feels like a nice native app, which is rare these days.

However, I've had issues since I upgraded to Big Sur. I can't edit my tunnels anymore.


Seconded. I can't comment on the Mac app but I have tried it on unix, windows and android and I'm extremely pleased that it allowed me to fairly easily create my own secure VPN that connects my home network laptop and phone.

Absolutely agree. The app just worked. The connection is fast and stable.

That is a fantastic showcase how to respond to negative criticism in a friendly, constructive and polite manner. Good work, Jason.

Yup. I rarely use WireGuard but it’s a great app and the response here made me go and donate on their website.

Incredible that people are so wired and ready to be outraged that they'd send off angry emails on christmas eve after reading someone else's problems with a piece of software.

+1, really can't understand that. If I want to rant about something, perhaps I'll post it on blogs or forums, I couldn't imagine that harassing the author with angry mails is also an option...

I think a good part of it is that you can be annoyed by a piece of software and not be able to articulate it beyond “it sucks” - and then you find someone who wrote a detailed article that explains all your pain perfectly.

And even though it was Christmas Eve you send it off partially in disgust and partially in a “maybe this explanation makes it clear”.


> I woke up this morning with my inbox lit up by netizens outraged at me for having allowed the WireGuard Project to produce such terribly subpar and dysfunctional software for the Mac. That was a weird way to wake up on Christmas, considering how much I really do care about delivering polished software.

The response is much nicer than deserved. I would not have blamed him for a less friendly reaction.


In that situation I’d take the emails in a “welcome to my hell” frame of mind instead of a “why are they pissed at me”.

It’s also true of much enterprise software - it’s often as good as the developers could make it given the constraints they were working with.


I'm laughing right now trying to imagine how Linus would have replied to this.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: