> 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
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)?
> 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.
> 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.
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...
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.
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.
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.
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.
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.
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.
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)
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.
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.
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.
> 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.)
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].
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].
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.
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.
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.
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.
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.
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.
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 reason is in the comment just below yours: Apple is a gatekeeper to ~40% of the US (last I checked, that number is low) and why bother writing an open-source tool if only half of your audience can use it? Especially if it's something like a VPN where infrastructure is involved -- you're certainly not going to set up one gateway for Apple users and another for everybody else.
We're stuck with this problem until the users have a bad enough experience that they move to a better platform.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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'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.
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.
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.
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.
Just because software is made available using a public web server does not mean that you are free to use it as you please. It's distributed along with a ToS agreement that governs its use.
Bringing in words like "illegal" can be fraught because I don't think we've seen a court case (in the US at least) about exactly how binding a "click-wrap" agreement actually is, but there's no question that projects like the one linked upthread violate the terms of the software license.
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.
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.
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).
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 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].
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.
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.
> 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.
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.
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%.
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.
You can't just look at the clients, you have to consider a VPN protocol holistically. Do you think that most VPN installations are going to run two different gateways side-by-side so that they can provide Protocol X for Platforms A and B, and Protocol Y for Platforms C and D? (Even worse: X for just Platform A, and Y for literally every other user.)
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)
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, 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.
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?
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.
> 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.
> 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.
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.
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.
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 ...
> 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?
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.
>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.
>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.
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.
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.
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.
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.
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.
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.
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.
I know that people say this all the time, and usually nothing comes from it, but it really feels like Apple is playing with fire here. Over just the past year I've gone from "I don't see why I wouldn't support Mac" to "I'm not even going to try and build my software for Mac, life is too short to deal with Apple's crap."
It's been kind of a weird transition. I was talking to someone recently about accessibility between multiple GUI frameworks (QT/Electron/GTK/Swift/etc...) and they brought up Mac accessibility differences. And immediately my brain jumped to, "well, who cares if those frameworks are accessible on Mac, because it's not like my software is going to be on there. Only the Linux/Windows/mobile experiences matter." It was a very strange feeling to have that be the first thing that instinctively popped into my head.
And I'm only one developer, and probably no one's really going to notice or care about my decisions, and historically as long as users demand Mac software/releases, developers have had to just put up with it, so I don't have strong evidence that this is going to be different.
But I wonder how long that can hold out before eventually something snaps. Realistically, there's no way that Wireguard can refuse to release for MacOS. But everyone else? If you're making a game, why would you ever target a Mac build if you're worried about running into issues like this? Is the gaming marketshare on Mac really big enough to justify this kind of annoyance and time commitment?
I'm probably naive, but it just seems like at some point developers are going to decide that the only reason to support Mac is if it's their primary market. Maybe Apple doesn't care, maybe they'd like us all to move to iOS anyway.
As a Mac admin VPP/App Store distribution is still quite finicky. I don’t understand why Apple has to flex and restrict NetworkExtension/VPN apps to Mac App Store. More iOS-ification of the OS.
Reading through the explanation IMO the problem is not that Apple wants to force VPN apps to use frameworks and a distribution model they feel best fits their security/safety model. There are good arguments to be made for that. The problem is that the framework itself is just shitty and Apple should improve it.
This is one of the things I dislike most about Apple: even despite the high price I pay for their products and (subsequently) the astronomical profits they make, somehow they seem to be completely unable to simply address these kinds of problems as soon as they pop up and make everyone happy again. It's also in Apple's own interest to make sure VPN extensions can automatically update in case of potential security problems, no? So why they don't just throw enough resources at it to make it work really is beyond me.
There's a lot to like about Apple products but their culture towards addressing problems that affect their paying customers is becoming increasingly off-putting, especially since they have basically been printing money for over ~10 years now and have no excuses to not improve these kinds of things.
> especially since they have basically been printing money for over ~10 years now and have no excuses to not improve these kinds of things.
Apple can't hire enough devs.
I told an SWE friend of mine at Apple that I wouldn't mind working there - then he explained to me how restrictive it is to work at Apple (e.g. you have to close your GitHub account, you can't do any moonlighting or FOSS contributions: even on your own time, on your own hardware, while on vacation) - I can't work at a place that wants to exert that much control over my personal life. I get that secrecy is part of being an Apple, but it feels the same as how I thought it'd be cool to work for the FBI's infosec team before I learned that they have mandatory regular drug-testing even for employees in states where cannabis is legal.
That's crazy and stupid, no argument about that. But even if they refuse to change that culture (which they should) they could still 'fix' that problem by throwing more money at it, everybody has their price.
Apple Inc. has massive profits and they apparently decided that frameworks are good enough and it is not worth to pay more (both in cash - and also indirectly, by less hostile requirements).
That's not a problem for me ... it's all the other issues: the crappy/buggy frameworks, the crappy store experience, no Test Flight, removing the app for a donations page.
Apple's overly protective threat modelling/mitigation is a selling point and not a "flex" for me.
I don't think I'd have had the same patience with a response on Christmas morning to a project I'd sunk endless time into. Well done OP. Can't wait to see more Wireguard.
> Because as far as I know, Apple only allows
NetworkExtension-based apps to be distributed via the App Store,
No, not so. Plenty of VPN apps based on network extensions are delivered outside the Mac App Store. In fact, most commercial VPNs are done this way. My company uses GlobalProtect for example, and I can install it any number of ways, and it’s been NE based for over a year now...
Apple doesn't deserve to have such careful and detail-oriented FOSS developers like Jason, developing for their platform. He is genuinely wasting time in order to work around Apple's developer-unfriendly platform. Not that I should be telling devs where they should spend their time... but I feel like so much effort is being devoted to fix Apple's issues.
> When I'm debugging these issues, I'll often times spend a few hours in IDA Pro (Apple doesn't provide debug symbols, unlike Microsoft, which makes this process even more miserable than it already is), and after identifying the issue I'll often have several ideas for "clever" workarounds. Which of them are acceptable for the App Store? Usually none!
Really, why we need to have very talented people spending their time in dealing with this, instead of contributing actual value on other parts of the project? Apple should be losing devs in favor of other better platforms, not the other way around. With less and worse products at their disposal, Apple users would then be well aware that they are choosing a platform that alienates developers.
Completely agree. Apple has nothing but contempt for its developers, and treats them like indentured servants. "Oh it took 10 years to get your app working right? Well, it doesn't work right anymore after yesterday's patch."
Also you're an open source and free project? If you want donations we're going to need a cut of that. Doesn't matter that you're providing our OS with functionality (for free) that we can't or won't create on our own.
Yes, he says it right in the post. They had a donation link in the about section that Apple forced them to remove because the payments weren't going through the app store payment system where they get a cut.
I guess Windows doesn't break their compatibility almost ever. Linux doesn't break user-space, but of course the libraries you depend on might change in a few decades.
There's a 2004 article about this by Joel Spolsky that can be found here[0]. Obviously it is a "tad" out of date (and I don't work on Windows so I can't comment on the situation right now), but it seems that at some point Windows cared deeply about backwards-compatibility.
I've actually spent about 25 years writing software on Windows, mostly desktop. Stuff breaks all the time and getting it fixed is nigh on impossible even if you happen to be a partner with contract.
What is claimed to be backwards compatibility is only partially true; reality is that bugs and their workarounds will exist forever.
As for Linux and breaking userspace, that's the kernel interface which is stable, not the whole distribution. I really wish people would report that honestly. NT's API is stable too. It doesn't mean Gtk and ComCtl32 doesn't have abhorrent stability problems and bugs in them.
The issue is, on all platforms, the thousands of libraries each containing hundreds of calls and data structures.
Microsoft broke a lot in the past few years when they got rid of their dedicated QA department(s) but they are very keen of fixing backwards compatibility issues. I can still run my desktop application that I compiled in 1998. Try that on a Mac.
Try running 16-bit visual basic, which I was still writing as late as 2000, on a Ryzen and your analogy falls to bits. I remember the entire win16 to win32 porting effort that had to go in. APIs are never stable forever.
Change is the only constant and I've learned to embrace it where possible or suffer later.
It's completely untrue in my experience working with WWW, GNU, and POSIX. Compared to Android, Apple, Facebook, Twitter, eBay, and many other platforms I've developed for, I feel supported and catered to, and if I have a problem or a question, there is an actual human on the other end to guide me, politely and helpfully.
Developing for Windows back in the day, it was about halfway there. I had zero ability to communicate back to the platform owners, but I rarely if ever felt shit on, disrespected or disregarded. In contrast, on Win32, I felt like everything I wanted to do had already been considered ahead of time, thought through, and there was an existing and elegant solution available.
Linux? It's as close to *ix as you can get without time traveling to ancient AT&T sites and beholding original Unix boxen. Good hardware exists, even if it takes more effort to learn how to source it. Penetration shows Linux is about the same minority Desktop OS as macOS is in general (even if statistics among Developers is sometimes lopsided).
Windows? Microsoft hate and distrust aside, they are a company founded for Developers, by Developers and in general the "Developers, Developers, Developers" mantra still resonates through the halls and they try to make life easy as they can for developers. (They publish debugging symbols of the entire OS just about, as a specifically referenced point elsewhere in this thread, which affected the specific complaints of the article. Even all of the "developer unfriendly" complaints about their more recent platforms/SDKs/toolkits have mostly been walked back or are still in the process of evolving.) Just as with Linux systems, plenty of good hardware exists even if it is harder to find. WSL1 and WSL2 provide a bunch of options for how "close to *ix" you want to get. It's hard to beat Windows on penetration, because it is still the majority OS for most of the mainstream world.
Edit: and don't forget that ElementaryOS gets you pretty damned close to the Mac UI experience. I personally prefer GNOME, which seemingly steals inspiration from across the industry, so it's different but also really slick (the use of Super/Winkey as both alt-tab and the launcher is genius).
Hmm...maybe. I know several people who have System76 laptops and none of them would say that they're made well. At best they seem to tolerate poor Clevo-rebrand construction out of a desire to support a libre ecosystem. Complaints like needing to reboot to switch between integrated and discrete graphics, low quality screens, extreme fan noise that then interferes heavily with the microphone, and terribly overpromised battery life are the norm. Has something changed very recently?
I have a Sytem76 Oryx as my personal dev machine and a new macbook pro at work. The System76 was much more trouble to setup initially, but has been better in almost every way since then. The Oryx fan can be kind of loud, but the fan on my new macbook is CRAZY loud when it kicks on.
I like the thicker case as well. The mac just feels too flimsy when I'm banging away on the keyboard.
I don't know about older models, but my Lemur Pro laptop (released last summer) has been pretty awesome so far, and their cousins about battery life were spot on.
Honestly, I was thinking on "better" as in "more developer-friendly", especially regarding the phrase I quoted... i.e. Microsoft Windows.
As for myself, I work on Linux systems, so my preferred platform would be a beefy PC with some Linux distro.
Yes, Apple makes good hardware. Or, at least lets say they worked hard on creating a distinctive perception about their quality on the consumer's minds. On the other hand, for some reason people tend to avoid spending similar amounts of money in the other ecosystems (or that's what I feel in my circles). I mean, try spending the same money that you would pay for the latest iPhone or Macbook, and you will get a fabulously spec'd Android phone or laptop.
Ye olde "Thinkpad + Linux" is unironically one of the best options around. I've owned 3 or 4 Thinkpads, and all of them run Linux like they were designed for it. Considering the security issues and hidden analytics in Big Sur, there are plenty of better platforms around. If you're looking to outright replace MacOS, KDE will mostly do the trick. It's super customizable, and contains all of the MacOS idiosyncratic staples (Global menu, dock bar, you get the point). With that, you get perfect Unix compatibility and software freedom, and you're only losing a few proprietary apps in the migration process.
think pads have pre installed fedora or ubuntu
dells have pre installed ubuntu
system76 was already mentioned with linux preinstalls.
and for those wanting to go a step further into the boot chain (sans chip manufacturer blobs), there is purism https://puri.sm/products/librem-14/
personally, I've been really enjoying the Thinkpad 14s AMD - 8 core / 16 thread / 32gb of ram in under 3lbs, shame about the screen though.
I wish Apple would just integrate Wireguard into macOS itself. macOS has a built-in option for VPNs in the network preferences but it's shit like L2TP over IPSec.
I don't think Apple cares very much about personal VPNs, only corporate ones.
The number of people who gate a mac purchase on the capability to speak WireGuard is tiny.
I now only connect my macs and ios devices to the internet via external VPN router/firewalls on which I have root; I can no longer invest the time to hack macOS sufficiently to permit me to ensure that no unauthorized traffic is leaving it.
This means none of my iPads or iPhones have SIMs in them any longer, as I take this approach even when mobile (gl.inet makes a travel VPN router with an LTE interface that runs OpenWRT).
I would imagine Wireguard usage in corporate networks to increase in the future, so if Apple only cares about corporate VPNs, surely there'd be reason to implement that as well.
My guess would rather be that Apple at some point cared about corporate VPNs but no longer do, and that option is mainly just legacy.
If Wireguard would be certified and you can have a contract with a company to carry the risk of this VPN solution then it will gain traction.
I know that technically it is probably superior and safer, but for regulatory things people might still chose Ipsec
To the point you feel forced to use your Android phone without SIM?
I bought my android phone for less than 150€ and it does what I need (phone calls, navigation). For everything else I use a debian based distro on my laptop (in some rare case, I dual boot windows).
I really have no issues and I spent way way less than any Apple fan ever will to do basically the same thing.
Let's be honest, most people are willing to pay hefty prices for Apple's products just because of the social status they provide.
The displays on iOS devices already ruin the experience for me nowadays. The perceivable smoothness from a 90-120Hz display still surprises me but now I can't really go back to an older display for daily use. Flagship Android devices also have far more hardware features in general (faster charging, more interfacing options, more cutting-edge "gimmicks," etc.). To be honest, I don't mind iOS, but I'm not really sure what iPhone hardware you think is better or even on par at a comparable price point.
This is exactly why I won't use or develop for Apple products for any amount of money.
I can't justify wasting that much time and stress on a platform that clearly is more concerned with meeting the needs of casual users and media professionals rather than developers or those concerned with freedom, security, or privacy.
> can't justify wasting that much time and stress on a platform that clearly is more concerned with meeting the needs of casual users and media professionals rather than developers
It’s because Apple prioritizes users over developers that they have so many users.
Apple has poorly documented APIs and locked down platforms and app stores.
Windows has decades of cruft and the OS itself is basically adware at this point with "recommendations" and shit showing up constantly, un-removable foistware, dark patterns to herd you into MS cloud, and loads of gratuitous telemetry. Windows drivers, driver signing, and installers are all horrors that can reduce one to a gibbering lunatic like the poor souls in Lovecraft's fiction. Networking is horrific too, and NTFS is slow.
Linux has fragmentation, fragmentation, fragmentation. There are at least three package formats, two or three inits (though I think we're converging on systemd in spite of its many warts), and loads of gratuitous distributions and sub-distributions and spins of distributions that have no reason to exist except for some minor holy war over some minutia or license holy wars. Oh and the most popular package formats, dpkg and RPM, are arcane nightmares from the pit of hell.
Every time I get mad at Apple I try working with another platform and realize Apple is not that bad. They all suck.
What about BSD? They tend to be less fragmented than Linux. The only showstopper for me with BSD is the lack of docker, but if you are happy not using docker or using jails instead BSD can be a good experience.
I like it, but the fact is that not many people use it and the ecosystem is small. That makes it hard to convince more people to use it due to difficulty hiring, staffing, getting answers on forums, etc.
My dearest Jason, please just stop wasting time on the closed crApple platforms with all the censorship these days. Your talents can be put to better use. If crApple users want to use wireguard, they can switch to linux or windows. In fact, this will benefit all of us.
dang: What was the purpose of removing "Developer's" from the title? Previously it was 'Developer's response to “WireGuard: great protocol, but skip the Mac app”'.
Neither of these are the actual title, so that can't be the rule it was operating under, and the fact that it's a developer (as opposed to some other user or Apple/Wireguard fanboy/hater) does change the context, at least for me.
Maybe dumb question but why are they distributing through the Mac App Store? Seems like a lot of these problems are due to the review process. It is possible to just do direct downloads on the Mac.
Couldn't a lot of the Apple pain be avoided simply by ditching the Mac App Store? It's not a requirement for distributing software on the Mac, so why deal with the pain, the limitations, the 30% cut, the slow approvals, if you don't really have to? The Windows Installer is distributed as an MSI, there's no reason the WireGuard installer for Mac couldn't just be distributed as a self-hosted .pkg.
Cisco doesn't host their VPN packages on the MAS either.
One problematic thing about App Store reviews as a developer is on each submission, Apple does a cursory review of the whole app. This means a one-line bug fix that is an improvement in anyone’s eyes can get caught on a detail that has been present for years.
It would be fine if these complaints about old details were reported to developers as “blocking any future app releases”, but blocking immediate bug fixes really hurts.
The following suggests a technical solution and expresses no opinion on the policy issues of supporting the Mac App Store:
Jason implies that Mac apps that use the Network Extension can only be distributed through the App Store, but this appears to be a misunderstanding. This page at Apple purports to document a way to build an app for distribution outside the App Store:
Perhaps this would allow WireGuard to support the Mac more easily without having to rely on the App Store. (It still requires an Apple Developer account, but that's already a requirement for the App Store.)
I for one think the Mac app is awesome. I much, much, much, SO much prefer telling people to install from the App Store as opposed to, well, anything else. Especially I would never, ever tell anyone to use Macports. It's just not the way forward.
I didn't know about WireGuard before the initial post on HN, since then it's replaced my OpenVPN solution to access things on my home network stuck behind a 5G mobile CGNAT (no wired service available)
I haven't had any issues with the Mac app, but for where the app may be lacking because of the circus that is developing with Apples frameworks and app store it makes up in being absolutely amazing behind the scenes.
All the other solutions I've tried have taken weeks of learning and tweaking configs. Had the entire WireGuard solution going end to end in a few hours.
It's super simple, lightweight, reliable and easy to understand.
It's a shame Apples app store policies and being forced to work with buggy frameworks is holding back developers abilities to write first class native software for MacOS.
Dumb question 1: Why not do what Apollo for Reddit (and many other apps) does and add in-app "tips" and/or other purchases? With minimal UI support it'd be orders-of-magnitude more effective at raising money for WireGuard than a web link, regardless of Apple's markup.
Dumb question 2: Why isn't it a good idea to create a non-profit, or distribute via a partner non-profit, to reduce the App Store take to 0%? (Even without that, Apple's take would be 15% until the app hits $1 million in annual net sales there.)
I see people in the thread asking for special treatment for this (important and worthy, of course) project, which Apple obviously can't do that without creating a thousand other problems.
My, what a very polite maintainer! It makes me a bit sad that I couldn't ever figure out how to submit my bug report to the WireGuard project (if I recall I had to sign up for a mailing list? but I just want to submit one bug, not become a maintainer). Although, perhaps that added friction is what saves Jason the energy to be so polite when a nasty blog article hits the front page :)
On the off chance this post is read, the bug report is simple: WireGuard for Mac doesn't respect /etc/hosts.
In an alternative universe, one could imagine macOS developers being so frustrated that they only bother with updating their windows/linux versions.
In which case, only apps like parallels would have to be working, then the bugs of macOS could be bypassed for many and focused for a set of well-funded developers.
All apps would have a translation layer, but that seems to not be an issue with the m1.
Couldn’t you just change the url to /about instead of /donations? Seems sort of the thing sketchy sites do to say one thing and link to another.
If I want to donate to a project I want to browse the site and learn more about rather than straight to the donation page. Seems like a money grab to take me to the donation page.
> Seems sort of the thing sketchy sites do to say one thing and link to another.
There is no misleading link. It's only a "Donation" button on the About window that opens a hyperlink, similar to this one [0]. How is it supposed to be a money grab? TBH, I don't think anyone ever bother to click it to begin with...
Yeah, I am willing to admit it was a loose interpretation of "sketchy" but it was that it's titled "About WireGuard" then takes you to a donation page that I was thinking about. Why not just call it "Donate to WireGuard" or link it to an /about page. You could have donation information on the about page in addition to information about WireGuard.
To defend Apple here - if they allowed “donations” with only a 5% fee you’d have thousands of developers offing “free premium” to “donators”.
What Apple needs is a curated system to support open source development for apps - for example, after proving that you really are a non-profit (think Mozilla foundation) Apple could still charge the 30% but then rebate 20% back as a donation from Apple itself. Win/win.
Apple already has such a process - you may not agree with the criteria, but they do outline it quite clearly:
3.2 Other Business Model Issues
[..]
(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. [https://developer.apple.com/apple-pay/nonprofits/]
Mozilla Foundation would be fine, but WireGuard is in hot mess as the "Donation" is not actually going to a non-profit organisation - it has in fact taken steps to avoid identifying _who_ the money is going to.
That hot mess is interesting (and obviously never brought up by the Apple is Evil crowd) - if you don't want to identify the destination of funds just don't call it a "Donate" button and let Apple take their cut. 70% of something is still more than 100% of zero.
App Store gatekeeping needs to burn. It may be helpful for the tech-illiterate who want simple and safe apps, but it's not a viable for a healthy ecosystem of broad ranging applications. It's crazy to think I can't install an app from a developer I trust from their website.
> I woke up this morning with my inbox lit up by netizens outraged
Wait, are there people reading random blog post about piece of software and deciding it would be a good idea to nag author of the software by retranslating someone other's opinion? Isn't that, how to say, inadequate?
How fast is wireguard on windows? OpenVPN is fast on linux but disastrous on windows, you really have to tweak the settings to go beyond 5 MB/s and usually not much more.
This was very interesting to read. It contributes to my sense that MacOS is not really a top priority at Apple any more. Recent OS upgrades there have been quite painful.
There are bugs of course, but let's not loose scope of the fact that "Apple has restricted" usually means Apple is preventing bad actors from doing the wrong thing.
As a developer, I usually find it rewarding to work with the Sandbox and not against it. Making this part of the product conception very early on results in much smoother experience at the end. Of course, if submitting to the store is an afterthought there are surely some challenges to tackle.
> "Apple has restricted" usually means Apple is preventing bad actors
Thanks for the laugh! "Apple has restricted" usually means Apple wants to retain complete control in order to extract maximum profit. That's all it is.
I agree. For me the biggest win is much less maintenance in the long run. Sandbox hacks will eventually stop working and will have to be replaced. If someone can't make the app they want without going around sandbox, then they should avoid App Store distribution instead of betting the product on "clever" workarounds.
> That sort of suggests another question, though: why are we in the App Store at all? Because as far as I know, Apple only allows NetworkExtension-based apps to be distributed via the App Store, according to their developer relations guy [6], so we're locked in. And even if they were to change that someday somehow, and we went to standalone distribution, we would then have to support two parallel distribution channels so as not to abandon former Mac App Store users, presumably, which means we'd still be limited by App Store restrictions.
> Because as far as I know, Apple only allows NetworkExtension-based apps to be distributed via the App Store, according to their developer relations guy [6], so we're locked in.
Mods don't/can't read every comment posted 24/7, and don't actually get pinged if you put an @ before their name. Best way to actually contact the moderation staff is to send an email to hn@ycombinator.com
Note that it is currently 1:33 AM on the west coast, so they may not see it for a number of hours.
I don't get it. You cannot write a VPN app for MacOs and let people just download the executable from your website? Pretty sure I've never opened the app store on my laptop and still have a VPN installed.
Apple can't possibly get rid of kernel extensions - that's the only way to really extend a system in new and innovative ways (user-mode drivers are more like glorified serial-port applications). So much of Apple's platform today is made up of features that were only possible by extending the OS (e.g. Multi-Finder).
Apple's going to have trouble if they keep on hindering the people that made their platform and support their ecosystem.
Here's to the crazy ones.
The misfits.
The rebels.
The troublemakers.
The round pegs in the square holes.
They're not fond of rules.
And they have no respect for the status quo.
Apple 2021:
> Follow our poorly-explained, underdocumented, and arbitrarily applied rules or we'll ban you from the App Store.
> Apple can't possibly get rid of kernel extensions
they are though. It's getting harder and harder to get them loaded (on an M1 Mac, getting an extension loaded will require 4 reboots and a journey through the recovery environment).
I'd say that within the next 2-3 macOS releases, kernel extension won't be loaded at all any more and only user-space APIs will be available for third-parties (including drivers).
From a security perspective, this is a huge benefit to users of course, but I agree that at least for advanced users, the ability to patch the kernel at random would still be beneficial for some use-cases.
There's a lot of software which runs on macOS that depends on kernel extensions: think about hardware accelerated operations in Photoshop, or how does Apple plan to support any PCI Express expansion cards in the Mac Pro line - or Thunderbolt accessories for their laptops?
hardware accelerated operations will be covered by whatever drivers ship with the OS or can be written by DriverKit.
The times when Photoshop has required kernel extensions to be loaded are long gone. The UX around kernel extensions has been very bad for years already (granted - just a trip to the system preferences, but still), so Adobe really couldn't afford such requirements already.
Not quite, given that macOS has userspace replacements for some kernel extension functions and has been gaining more as time goes on.
iOS is far more restricted in this regard — for instance, writing a driver for your USB HID device isn’t possible there, but it is on macOS, and that capability isn’t disappearing. I don’t think iOS has any of the new virtualization APIs added in Big Sur, either.
That said, the userspace APIs need to be made much more robust before kexts are deprecated, and so to me that is what Apple should be pressured to do. Kernel extensions should be a last resort, not the go-to solution, because the reality is that they’re a security nightmare and have been readily abused (remember the mess with Dropbox of all things installing a kext?)
> Not quite, given that macOS has userspace replacements for some kernel extension functions
Similar to ios - you can't install any kernel extensions to it without Apple's special permission, and have to do everything with whatever API they have implemented snd exposed.
(In macOS's case crippled APIs with backdoors - e.g. application firewalls that use these new API cannot block some Apple apps.)
> I don’t think iOS has any of the new virtualization APIs added in Big Sur, either.
It will - Apple is moving both ios and macOS towards the same goal of converging them into one product. We saw that with multi-tasking advancement and other features in ios with iPad Pro's, and the crippling of macOS from Catalina onwards.
> for instance, writing a driver for your USB HID device isn’t possible there
It is possible through the "MFi" (Made for iPod/iPhone) programme: that's how custom iPhone accessories that use the Lightning port work: they get to write their own user-mode driver for the USB port. Ditto for "Classic" Bluetooth devices.
> Apple can't possibly get rid of kernel extensions
Have you seen what Apple's been doing for the last few years? They don't care if your app or workflow breaks. If you make enough money on your app, you'll jump through any hoops they prepare.
I don't believe that is correct. It's true that you need to configure your code signing and entitlements through the Apple developer portal, but I don't believe it has to be distributed through the mac app store to run with those entitlements.
the original article quotes https://developer.apple.com/forums/thread/81281, so I guess the App Store requirement is a thing at least for some people. Not all entitlements work the same way - some can be configured through Xcode, some require special signatures provided by Apple through other back channels and some are only available to Apple themselves.
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