Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Roadmap for Sparkle #992

Closed
kornelski opened this issue Jan 10, 2017 · 8 comments
Closed

Roadmap for Sparkle #992

kornelski opened this issue Jan 10, 2017 · 8 comments

Comments

@kornelski
Copy link
Member

kornelski commented Jan 10, 2017

Sparkle is almost 10 years old. I suspect that users' and developers' expectations and requirements have changed since Sparkle was first released, so it might be worthwhile to discuss how updates should work in 2017.

  • Updates in general used to be suspicious, and auto-updated applications outright scary, so Sparkle is very shy about updating anything. OTOH now lots of apps have taken Chrome's lead and switched to be "evergreen" — they're always up to date, period.
  • As people started using lots of apps on smartphones, updates started to look like a chore, and many users would rather not hear about any updates at all. All major OSes (desktop and mobile) have now options to auto-update everything without asking (default on on mobile, but I don't remember what's macOS's default now).
  • Internet-connected applications are common, and for them not being up to date may be a security risk or at least break them due to server APIs changing. There is a tension between giving users control and keeping apps safe and compatible.
  • macOS has now an established UI for app updates.
  • macOS is now also used in "enterprise" where apps may be centrally managed.
  • What else has changed?

Questions:

  • Should we redesign our UI?

    • Do the same thing with slightly refreshed UI? (we could make notifications and update window sort-of look like Apple's for example, or we could provide hooks to have in-app notification like in Spotify).
    • Or maybe completely change approach? Have a separate updater with multi-app window that's just like App Store's.
  • Should we change our defaults?

    • Is it still appropriate to have update check permission prompt? (i.e. not the prompt before download/install of the update, but the prompt that disables all updates forever if the user says no).
    • Should we develop UI that works better with auto-updates? e.g. instead of showing release notes before download, show "what's new" after install.
  • Would it make sense to have a Pref pane, or a standalone app to manage Sparkle system-wide? To apply updates system-wide?

@zorgiepoo
Copy link
Member

Hm... I still think we have the right defaults (or are very close)..

macOS is still a different environment than iOS and should be treated as such. I don't think updates default to be installed automatically on the Mac, but I'm not sure. It's different.

I still think automatic downloading of updates should be opt-in by the user or developer. I don't know about everyone else, but a fair number of apps I use and develop don't have much internet connectivity. I almost feel that what Chrome does may be a special case and they can afford to get away despite their behavior. By nature apparently, updaters even tend to get auto-updating fatally wrong (see past corrupt updates, other popular macOS updater that fails at authorization).

I think we are in need of a UI refresh or alternative along the lines of #127. Not notifications (#924). I may even go as far as saying supporting notifications would allow apps to enable intrusive behavior. Either way, notifications are supplemental, not an alternative. An unread dock badge is another similar idea, but I'm not sure it'd work out well.

Having an update permission prompt.. I think we currently default to the "safe" choice because we can't force a developer to provide a reasonable option to disable automatic update checking. Hm, I do see the appeal of not bothering users with the prompt though.. :/

If we present that an update is available before installing, I believe we should show available release notes right there. If an update has been installed automatically without prompting the user, it may be reasonable to show new features (if the version upgrade was 'noteworthy' enough?). It's questionable how much of this logic should even be tied into Sparkle, as well as noting that the app could be updated manually as well.

I feel that a separate supplemental app would most likely be installed and used by power / administrative users. It could be nice though. We don't want to go down the path of Growl where a pref pane was needed, third party apps installed the pane without user's permissions (against Growl's wishes), etc.. They eventually ditched the pref pane.

@zorgiepoo
Copy link
Member

One more thing that wasn't brought up for that I feel a tiny bit critical about: we default to scheduling updates repeatedly during the updater's lifetime.

@balthisar
Copy link

Or maybe completely change approach? Have a separate updater with multi-app window that's just like App Store's.

A separate updater should never be a requirement; applications should always be capable of updating themselves. However this is an awesome opportunity to develop an optional updater application!

For example:

  • At launch, applications check to see if Sparkle2017 Updater App is installed.
  • If so, the application can register itself with the updater app.
  • If not, then Sparkle2017 can offer to install the updater for the user, but it’s optional because apps should always be able to update themselves.

The Updater App would be a great tool to see all modern Sparkle applications on the system, versions, release dates, and the ability to update anything or everything if an update is available. Kind of like AppFresh or MacUpdate Desktop (I’ve never tried either of these, though, but are mentioned for reference).

@Bi11
Copy link
Contributor

Bi11 commented Jan 19, 2017

It would be great if Sparkle Updater App manages all updates system-widely. It can:

  • Turn on or turn off auto update globally, e.g., when using cellular
  • Turn on auto download and install globally by default, no more bothering prompt in app.
  • Allow user to disable auto update for certain apps
  • Download and update app in background. Do not need open host app and keep it running.
  • Resumable download. If network is poor, or the update is very large.
  • Downgrade app if possible.
  • Restore if host app was deleted unexpectedly.

Updater App can discovery app by scanning SUFeedURL in Info.Plist .

An annoying thing I've experienced with Sparkle is similar to #901. App says it has an update, but download failed after long time waiting because networks is poor. During the download, the status window is unable to hide or minimize. When the next time app starts, same thing happened again.
Usually I don't care the update, and don't want them to interrupt my work. Updates should not takes too much attention, it better be running while I am sleeping, not working.

@adrianthomas
Copy link

Yes, definitely.
We customized the update workflow in VPN Tracker to silently run and just display a smaller "Update ready" button to let users know they can update.

We would really welcome enhancements that offer

  • Silent updates (optionally by default)
  • A release notes after updating view
  • A background updater process, that can also deal with apps that basically always open (see Dropbox's new Dropbox Update feature)

@billymeltdown
Copy link
Contributor

Security is still my No. 1 concern. We are using Sparkle for a Sandboxed application, and thus can offer no "Install and Relaunch" due to the myriad security problems with doing this in current Sparkle and the branches that exist offering to do it while downgrading security. Been following this thread foreverrrrr so apologies if I'm not all caught up on the latest developments completely.

Anyway, that's more important to me than anything else, because as it is now we can only use Sparkle to notify the user that there's an update available for them to download and install themselves. Without that many of the other improvements made to Sparkle are not something I can take advantage of. That said, there's nothing wrong with a nicer UI and the other improvements you're thinking about!

@zorgiepoo
Copy link
Member

@billymeltdown I think #1023 would be most relevant to you; pulling in the secure sandboxing branch I've been working on for a while.

@billymeltdown
Copy link
Contributor

@zorgiepoo thanks, will check it out! Thanks also for all your hard work on this :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants