Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Response to “WireGuard: great protocol, but skip the Mac app”

lists.zx2c4.com

Post reply on HN
Print view View original

161–170 of 392 posts

Re: Response to “WireGuard: great protocol, but skip the Mac app”

#161

Post by evgen »

Macha wrote: post #143
evgen wrote: post #111

Earlier quoted context omitted.

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 fro…

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.

Re: Response to “WireGuard: great protocol, but skip the Mac app”

#162

Post by pilif »

DaiPlusPlus wrote: post #129
pilif wrote: post #39

Earlier quoted context omitted.

> 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…

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?

Drivers will be and to some extent are covered by a user-space driver framework (https://developer.apple.com/documentation/driverkit)

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.

Re: Response to “WireGuard: great protocol, but skip the Mac app”

#163

Post by pilif »

seanalltogether wrote: post #58
pilif wrote: post #26

Earlier quoted context omitted.

that's using older and deprecated frameworks including possibly kernel extensions, all of which are going to go away in the future. Wireguard is using the newer and non-deprecated NetworkExtension framework which requires an entitlement that's only given to app-store apps.

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.

Re: Response to “WireGuard: great protocol, but skip the Mac app”

#164

Post by realusername »

plg- wrote: post #113
tasn wrote: post #44

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,…

> it's beyond me why would anyone willingly use an Apple product Final users don't see this mess.

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.

Re: Response to “WireGuard: great protocol, but skip the Mac app”

#165

Post by mensetmanusman »

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.

Re: Response to “WireGuard: great protocol, but skip the Mac app”

#166

Post by pilif »

ubercow13 wrote: post #130
plg- wrote: post #113

Earlier quoted context omitted.

> it's beyond me why would anyone willingly use an Apple product Final users don't see this mess.

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

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

Re: Response to “WireGuard: great protocol, but skip the Mac app”

#167

Post by ubermonkey »

tasn wrote: post #44

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,…

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

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

Re: Response to “WireGuard: great protocol, but skip the Mac app”

#168

Post by kop316 »

rthomas6 wrote: post #136
scaladev wrote: post #116

Earlier quoted context omitted.

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

Android is open source.

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.

Re: Response to “WireGuard: great protocol, but skip the Mac app”

#169

Post by danShumway »

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.

Re: Response to “WireGuard: great protocol, but skip the Mac app”

#170

Post by webmobdev »

kitsunesoba wrote: post #154
webmobdev wrote: post #107

Earlier quoted context omitted.

So essentially, macOS will become ios.

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 userspa…

> 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.

Post reply on HN