Sparkle: Replace NSURLDownload use

[bdb]

NSURLDownload is now printing out a console warning on 10.13.

Still works, but the console spam is annoying.

Edit: Building from 1.18.1 source using Xcode 9/10.13 SDK. I checked head and NSURLDownload is still used.

(lldb) b [NSURLDownload init]
Breakpoint 1: where = CFNetwork`-[NSURLDownload init], address = 0x0000000000238543
(lldb) r
...
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x00007fff3536e543 CFNetwork`-[NSURLDownload init]
    frame #1: 0x00007fff3536e5f1 CFNetwork`-[NSURLDownload initWithRequest:delegate:] + 48
    frame #2: 0x0000000107f67ad6 Sparkle`-[SUAppcast fetchAppcastFromURL:inBackground:completionBlock:] + 799
    frame #3: 0x0000000107f6cf46 Sparkle`-[SUBasicUpdateDriver checkForUpdatesAtURL:host:] + 594

[kode54]

Wasn't NSURLDownload deprecated for URL-to-disk in favor of NSURLSession as far back as 10.9?

Reasonably, I'd like to see this updated to use NSURLSession on 10.9 and above, otherwise use NSURLDownload.

[kornelski]

In Sparkle 1.x we still support 10.7, and will continue for a while.

Having two implementations is not so great, as it doubles maintenance and increases chance of accidentally break 10.7, which we already struggle to test adequately. So for Sparkle 1.x the only solution short term is to disable the warnings.

However, If you'd like to replace it, then perhaps it's feasible in Sparkle 2.x. See the branch https://github.com/sparkle-project/Sparkle/tree/ui-separation-and-xpc

[bdb]

You can't disable this this warning. It is printed to the console at runtime by the Foundation framework. There's no warning at build time because the min OS is 10.7.

NSURLDownload was officially deprecated in 10.11. NSURLSession appeared in 10.9 for 64bit and 10.10 for 32bit.

[bdb]

Off topic, but what is the reasoning for supporting a six year old OS? Especially when 10.11 supports the same hardware that 10.7 does and is free. Support could be argued for the 1.x series. You don't want to break existing clients. But why isn't the min OS requirement for 2.x 10.10?

[kode54]

Replying to off-topic, 10.7 is the latest available for machines with Intel GMA 950 graphics, for instance. Assuming you can upgrade them to 2GB of RAM to meet the minimum, or else you're stuck on 10.6.

[kornelski]

Sparkle is used by many projects with very different goals and requirements, so we're forced to support the lowest common denominator. Some users would even like us to support 10.6.

We haven't put much thought into 2.x. I think it may be fine to aim for 10.9+ in 2.x, leaving 1.x for those who need more backwards compatibility.

[nivekkagicom]

Is there a reason why version 1.x cannot detect the AppKit version and use NSURLDownload on macOS 10.8 and earlier and NSURLSession on macOS 10.9 and later? This technique is commonly used in Cocoa applications and would prevent the message being logged to the console since Sparkle would not use the deprecated API when the modern API is available.

[kode54]

It may also prevent the issue I experience now, where my change logs simply display some AccessDeniedAccessDenied mess.

[kornelski]

Technically there's no reason, but it increases amount of code to test and maintain. Are you willing to take responsibility to keep this code in good health for a few years?

[kode54]

Well, the NSURLDownload code is apparently in good health already, just using deprecated API. The newer code would need to be written to perform the same task, and verified to work on at least the minimum version to support it for file to disk downloads, which is supposed to be 10.9. It all depends on if anyone is willing to test that it works on anything that old, and whether dynamic switching causes a working API to be used on 10.7-10.8. Sounds like a job for a build bot?

[bdb]

The APIs are similar too, so not a lot of work. But it would be an ifdef mess. I think it would better to make a clean break in 2.x and use NSURLSession only with a min OS of 10.10 for 32bit or 10.9 for 64bit.

Edit: Knowing Apple, they will remove NSURLDownload API from the 10.14/15 SDK and then Sparkle will be forced to make a change, possibly in a rush, to continue building with the latest SDK. Better to plan for it now I think.

Edit2: Not just NSURLDownload any NSURLConnect API. Just to be explicit for what needs replacement.

[kode54]

It's not intended to be an #ifdef mess. It's intended to be detected at runtime. I want to target 10.7, but support both APIs.

[kornelski]

So another way to have both in 1.x, and minimizing maintenance and ifdefs:

Backport SPUDownloader from 2.x to 1.x, and split it into abstract base class, and 10.7 and 10.9 subclasses.

So then we'll just have one place with SPUDownloader *downloader = 10.9 ? [SPUDownloaderSession new] : [SPUDownloaderDeprecated new];

[bdkjones]

I agree with @bdb. The writing is on the wall for NSURLDownload. Apple is clearly saying, "This is going away. Here's your warning." And the worst-case scenario would play out like this:

---

1. A bunch of apps rely on Sparkle to update themselves.

2. Apple drops an OS where NSURLDownload fails.

3. A bunch of people update to that OS, taking their apps (with an old version of Sparkle) with them.

4. All those apps are now stranded because Sparkle can't update them. Users will miss app updates and developers will have a hell of a time getting people to go manually download a new copy.

---

It's not an issue of, "It makes testing more complicated". It's an issue of lag time.

Apps that use Sparkle need to start including a version of Sparkle RIGHT NOW that's ready for that hypothetical future where NSURLDownload is gone. It takes time for users to update apps and time for developers to update Sparkle. Six months or more. (Especially because devs aren't likely to update Sparkle in their app until they run into a problem.) And users don't install updates right when they're available. Some wait a long time.

If Apple announces the death of NSURLDownload at the next WWDC, it will be too late to get Sparkle updated, ready, and deployed in the wild so that all apps using Sparkle are ready for that OS. That scenario would lead to a massive, massive headache for Sparkle and everyone who relies on it unless you start preparing now.

[kornelski]

That's a compelling argument, thanks @bdkjones.

[kode54]

I already have an app that, on 10.13, displays some AccessDeniedAccess\nDenied\n1239120091324901randomhexcrap instead of change logs now. Of course, it may also coincide with the fact that I now use actual HTML snippets in CDATA blocks, instead of raw text.

[bdb]

While Apple loves to add new APIs and remove old ones, they also make sure the onus is on the developer and not the user. It's very unlikely that NSURLDownload binaries will break anytime soon. There's just too many apps using it. What will break is building against new SDKs.

I still think Sparkle should be moving to an official NSURLDownload build ASAP. What are the release plans for 2.0 @pornel?

[kornelski]

To be honest, the plans for 2.0 don't look good unless someone can step up and do the work. We've lost Zorg who's been pushing the effort, and my current job doesn't leave me much time to spend on Sparkle either.

As I've mentioned previously the best way currently may be to backport downloader classes from 2.0 to 1.x. That will remove one more difference between branches and make it easier to swtich in 1.x, which is a win-win.

[bdb]

The problem is that 1.x doesn't black box NSURLDownload use. The 2.0 port time was minimal. The 1.x investment time would be a lot more. I think we all have jobs where we have to watch our time.