any plan about auto update? #233

This is on our todo list since it's an important feature.

It's a little bit tricky since we need to figure out a way to support both updating node-webkit itself and packaged apps by our users. Comments are welcome.

You probably should start by making some relatively simple first step, which is writing just a node-webkit's engine autoupdater that downloads the necessary archive (remotely hosted at http://s3.amazonaws.com/node-webkit/node-webkit-latest-sysname-procname.arcname) and unpacks.

The autoupdater should also deal with the necessity of application's restart (because you cannot replace a running executable in Windows) and have a toggle for automatic or manual updates (the latter is for users with limited and/or expensive traffic).

The next step is, I guess, adding some simple update object to the package.json manifest, and enabling the autoupdater to use some custom update sources (listed there as URLs to archives):

"update": {
   "linux32": "http://example.com/myapp-linux-ia32.tar.gz",
   "linux64": "http://example.com/myapp-linux-x64.tar.gz",
   "mac": "http://example.com/myapp-osx-ia32.zip",
   "win": "http://example.com/myapp-win-ia32.zip"
}

The autoupdater may be made to support the three different possible package variants inside those remotely hosted archives:

• folder of files,
• .nw file,
• .nw attached to the node-webkit's tail.

The autoupdater may alternatively be made to expect always a folder of files inside a remote archive, because the autoupdater may deal with the rest by itself:

• the autoupdater may create an .nw file by itself — if and where the autoupdater discovers that it's updating an .nw-packed application,
• the autoupdater may afterwards replace a former .nw tail behind the node-webkit executable — if and where the autoupdater discovers that it's updating an application attached to the node-webkit's tail.

Might be a stupid remark, and please do correct me if I'm wrong... Though why not utilize what's already there? a.k.a. the (html5) manifest functionality for the apps themselves? Granted, it involves a bit of rethinking regarding the implementation of the packaging itself. It does make it easier to maintain application updates, just publish a new version on the webserver (manifest change)...

@rogerwang I hope we see a simple implementation in the coming months, this is important for security.

I think when a new version of node-webkit is available/detect, it should prompt the user and update itself with the nw content from the previous executable.

The most difficult part of this is backwards compatibility. However it shouldn't be a big issue as long as you use Semantic Versioning. Perhaps the manifest file could allow for further restricting of versions (locking from updates until user-code is compatible).

@RobertLowe Could you please elaborate on the importance for security?

On the prompt thing, we'd like to consider application -- since application's developer may or may not want the prompt (or update) from node-webkit.

@rogerwang Without auto-updates the client is vulnerable to un-patched exploits. (For example: the recent SSL vulnerable).

On the prompt thing, we'd like to consider application -- since application's developer may or may not want the prompt (or update) from node-webkit.

This could be an option in the manifest (prompt_autoupdate - true: updates are prompted immediately when detected. false: updates auto patched on load). As auto-updating forcibly could effect application state.

@RobertLowe I understand your concern. And we'd like to implement this feature soon. But please be noted that as a native runtime, we take a very different security model from Browser or other Web runtime.

[...] (because you cannot replace a running executable in Windows) [...]

On windows the executable could be renamed and posteriorly deleted when the new version runs.

On windows the executable could be renamed and posteriorly deleted when the new version runs.

Generally you are right. However, renaming node-webkit may prevent some modules from running, see #199 and #344 for details.

@zhchbin ,is there any plan about this issue?

@roughsoft Hi, for myself(a student), I didn't have any experience about enabling auto update for native application though I had read some code which are relative about chrome update and its packaged app.

This is a very important feature for node-webkit!!!

Vote for this feature too. Very important thing!

I fully agree this is certainly needed for an enterprise application, due to the frequent Chromium security updates.

On Sat, Mar 30, 2013 at 11:39 AM, reznikartem notifications@github.comwrote:

Vote for these feature too. Very important thing!

— Reply to this email directly or view it on GitHubhttps://github.com/rogerwang/node-webkit/issues/233#issuecomment-15676465 .

is it possible to integrate with Sparkle on OSX and AutoUpdater on Windows? Google has also open sourced there update tool Omaha.

Voting for this feature as well.

Note: Omaha does not support OS X, Linux, non-NT versions of Windows, or any NT version of Windows preceding Windows 2000 SP4.

Rather then going native...

I think Light Table implemented it's own auto-update.

@ibdknox could you elaborate on it?

This could be a script/npm module, I think it would be the best approach as it allows for easy access/modification. Other then a couple of hooks, it's just a matter of downloading the new kit & patching assets into it.

A generic Build module & Update module could be useful.

Just my two cents.

EDIT: a Build module may also help clean up some of the nw-test code.

I push all of my assets into ~/.lighttable on startup if it doesn't exist and then just have something that looks for a tar and unpacks it into ~/.lighttable when there's an update. This works well enough for the times when I don't need to update the version of node-webkit.

My auto-updater doesn't currently handle the node-webkit replacement bit, but that should be relatively trivial as far as I can tell. Just not worth the potential cross-platform headaches right now

Hi. I'm creating a HTML5 game that will be released with NW. And it will be great to have an updater for patching my game. Any new on that feature ?

I wrote my own auto updater too. Currently it's a seperate node-webkit application that the main application launches when there's and update, then the updater downloads a zip and overwrites old files. It works pretty well on windows and linux, haven't experimented with OS X yet. I plan on implementing different update strategies, one for replacing the updater itself, one for replacing node-webkit binaries, and one for just updating assets. I might opensource it when it's a bit more mature, together with the node server that manages the updates.

The only issues i've run into are filelocks on windows and zombie node-webkit processes on linux, but it should be rather trivial to check for those and notify the user.

@miklschmidt I know its only been 12 days but would you be willing to share what you've started for your auto-update?

@danielmahon sorry for the late response. Here's the gist of it.. it's a little.. rough around the edges.

http://gist.github.com/miklschmidt/5903434

No worries, Im just glad you were able to respond! Ill take a look, thanks!

Just to remark, I currently use node to simply launch a sub-process, which replaces the files and launches the updated version. Obviously, this won't help on the large scale, but for a temporary fix, it works quite well.

@jonathandelgado So long as you do a delta patch of some sort (only downloading changed stuff) that's not going to be so bad. If you're redownloading the entire thing though...

I'll just leave this here: Sparkle http://sparkle.andymatuschak.org/ Windows port http://winsparkle.org/

In the mean time I'm building a node-webkit javascript solution. It would be great to join efforts.

I have built my own version in JS, it seems to work well - however i'm now looking at signing the app and i'm 99% sure that this will break the updater as the contents of the package can't change.

Vote for this feature too. Its not good if everyone writes his own solution!

Vote too. This will really be a great feature.

vote too

what's the progress about this feature now ?

+1

+1 any news about it?

I wrote my own updater too, but only for the app (html, js and assets). So a NW updater would be great. But not an auto-updater !! Why ? Because my app is goaled to be used in prod, and I don't want NW to be auto-updated if my app doesn't support it. The best would be an auto-update only for critical issues, and a manual update (with overwrite of the package.json by the app ?) for other updates.

@StudioQuendi care to share your code?

+1 for autoupdate

Just, fyi, I was about to put up $50, but then realized I wouldn't get access to the product for that, and didn't.

On Mon, Jan 13, 2014 at 3:46 AM, Jakub Szwacz notifications@github.comwrote:

Since almost everyone needs autoupdate, and it looks like no one have time to actually do it, I started crowdfunding campaign for tool with such capabilities (among others). http://www.indiegogo.com/projects/nwt-development-tools-for-node-webkit Maybe you would like to paricipate with me in this effort.

Note: Please discuss my post on the campaign page, not here.

— Reply to this email directly or view it on GitHubhttps://github.com/rogerwang/node-webkit/issues/233#issuecomment-32162482 .

+1 for autoupdate

Another vote for updating. This is similar to how Adobe AIR manages the update process.

+1, pretty critical feature IMO

An example from another open source project that deals with updating a system very similar to how node-webkit runs:

TL:DR:

• Docs: https://wiki.mozilla.org/AUS:Manual
• bsdiff/packaging: https://wiki.mozilla.org/Software_Update:MAR
  • src: http://mxr.mozilla.org/mozilla-central/source/modules/libmar/

Its an older system and new things could be used as for example xml is their server response type, as JSON would be much more appropriate, but it is something thats still used today.

When comparing the two systems what I am referring to is mozillas XULRunner platform, which also uses the AUS system for updating both the runtime platform and the files that run on top of it.

I have no clue how much work it would be to build something similar for node-webkit, just trying to help further the discussion with ideas.

Thanks for all the hard work so far!

Can somebody explain me why node-webkit should have an auto-update feature by itself? Does anybody use it as browser replacement for viewing web pages?

2014-03-10 8:38 GMT+02:00 Allclone notifications@github.com:

An example from another open source project that deals with updating a system very similar to how node-webkit runs: TL:DR:

• Docs: https://wiki.mozilla.org/AUS:Manual
• bsdiff/packaging: https://wiki.mozilla.org/Software_Update:MAR
  • src: http://mxr.mozilla.org/mozilla-central/source/modules/libmar/

Its an older system and new things could be used as for example xml is their server response type, as JSON would be much more appropriate instead.

When comparing the two systems what I am referring to is mozillas XULRunner platform, which also uses the AUS system for updating both the runtime platform and the files that run on top of it.

I have no clue how much work it would be to build something similar for node-webkit, just trying to help further the discussion with ideas.

Thanks for all the hard work so far!

Reply to this email directly or view it on GitHubhttps://github.com/rogerwang/node-webkit/issues/233#issuecomment-37156566 .

@CodeTrol I can't quite make the connection between the use as a browser wrapper and the need for a auto-updating mechanism, but to answer your question: yes, we are - planning to - use it as a thin wrapper around an existing web app.

@CodeTrol Of course it should have an auto-update. That's a common function in modern desktop applications. The ability to tell the user when there's an update to the application.

Updating nw core and relaunching the application is one part of auto update.

However in my case the application itself is even more frequently updated. I would want that nw will be able to load the application package (zip) from url and extract it locally for offline execution. The url will be polled to detect new version, update the local application package and reload the application.

Currently my workaround is to use a remote url in the "main" property of the package.json combined with the "node-remote" option, however this means that the application is always loaded from the internet which requires being online to start it, and also effects startup time.

Polling for new version is easy and might even require some specialised authentication depending on the application nature, but the parts of keeping the application package offline and relaunching the application from the updated package are functions that would be best if nw will provide cross-platform.

Thanks! It's an amazing project!

I'm working on a little something for Mac here after the latest Mavericks update broke our previous updater - this isn't in production yet.

Contributions are welcome and I'd like to take it multi-platform in the future... right now it uses an app packaged in a .dmg downloaded from a remote host.

I confused a little... Are we talking about updating an app or just node-webkit core? For the first condition, solution consists of 3 steps:

1. check for update (eg: 'https://mycompanyname.com/myproductname/update?current=version') with JSON response like: {version:2, files:[...]}.
2. download files mentioned in JSON.
3. update manifest file.

For the second condition, here I wrote a code in 5 minutes for you which checks for node-webkit:

require('https').get('https://github.com/rogerwang/node-webkit',
 function(response){
  var contents = '';
  response.on('data', function(chunk){ contents += chunk; });
  response.on('end', function(){
   var matches = contents.match(/<a href=\"\/rogerwang\/node-webkit\/tree\/nw\-v([^\"]+)/);
   if(!matches) console.log('updates checker is broken');
   else matches[1] != process.versions['node-webkit'] ? console.log('There is new node-webkit version avaible: v' + matches[1] + '. Please get it from here: https://s3.amazonaws.com/node-webkit/v' + matches[1] + '/node-webkit-v' + matches[1] + '-win-ia32.zip') : console.log('up-to-date: v' + matches[1]);
  });
 }).end()

(this is version for Windows and not tested yet) But what if my app would not work there (kind of bug will appear). As developer, I must to test it first before it gets to the user. Maybe it's only me distributing my apps as stand-alone applications (nw.exe+package.json+"data"). Maybe it's only me replacing icons of executable (in Windows enviroment). Maybe it's only me renaming files /^nw(\.exe)$/ to 'myappname$1'.

Just sharing my thoughts.

I looked into this as part of our hack day at Sky and the general approach was:

1. Check for new version (via a JSON API similar to the one above)
2. Download new (packaged) app to tmp_dir, terminate app in app_dir
3. Run app from tmp_dir, replace / patch app in app_dir
4. Start (updated) app in app_dir, terminate app in tmp_dir
5. ?
6. Profit

I haven't really thought about how to do patched releases of packaged apps (i.e. apps packaged with nw as executables) yet, or whether it's achievable at all, but replacing the entire app seemed a good starting point.

@hardchor Bear in mind that you may need more than just those steps. Some apps will have db schema changes which will have to be handled in the process too, meaning that there would be a requirement for some sort of hook around...step 3, perhaps?

+1

@damianb Absolutely. This was just a very basic starting point. If anyone has any input or would like to give this a go, I'd be more than happy to join in. Otherwise, let's hope we get the go-ahead from work in the next few months!

What about the transition between step 2 and step 3?

• If the old version of the app is terminated and thus cannot not do anything anymore, then how does the new version start?
• If the old version of the app starts the new version and only then finishes itself…
  • …how do we ensure that the new version survives the death of its parent process?
  • …how does the new version find out when its parent process is totally finished and thus it's safe to update its executable file?

+1 for the autoupdate

+1

Looking for it...

+1 Would be great to have!

+1

+1

+1

Maybe node-webkit should not provide an "Auto-update" feature but rather an ability to trigger some file operations in admin mode before the next launch. Because "Auto updates" imply:

• Server check which may be dependant on server implementation
• Settings and ui (when to check for update, frequency, ask for user agreement?, ..., show download progress, ask for user to restart, ...)
• providing other way of updating than live updating (from local files, from archive, throught a proxy, ...)

I think all that things are mean't to be provided by the app and not by the shell.

But, we need a simple way to apply the update (on app reload or at the next start).

• Ask for user admin permission
• Make some basic file operations (delete, copy, maybe patch)
• Launch the updated app with standard user permission

The update check and download (to a temp folder or whatever) should be done by the app.

@felicienfrancois Your breakdown sounds good. I think also a trigger to restart the shell is needed once the app detects a new version on the server. nw ftw.

@felicienfrancois I agree with this. And I would also add that we will better have a default update system with UI for node-webkit (it can be in another repo). Something like Sparkle which could for example default to show a CHANGELOG.md file.

Has anyone tried creating an installer with Squirrel.Mac or Squirrel.Windows? Both have support for automatic updates.

I spent most of the weekend trying to build node-webkit from source so I could try and integrate either Squirrel or Sparkle updates for OSX folks. Unfortunately I wasn't able to successfully complete a single build on OSX 10.9.3 (using a fresh VM and diligently following all the steps). So I never even got to the point where I could try integration.

However in my Squirrel research I did find atom-shell which is very similar to node-webkit and comes with Squirrel auto-update support built-in (mac support now, windows coming soon).

I had created autoupdate lib for mac/win/linux32/linux64 tested http://eldar.djafarov.com/2014/06/node-webkit-autoupdate/ git repo: https://github.com/edjafarov/updater

It gives you api to:

1. Check the manifest for version.
2. If the version is different from local one download new package to temp.
3. Unpack the package to temp.
4. Run new version from temp and exit the process.
5. The new version from temp will copy itself to original folder.
6. The new version will run itself from original folder and exit the process.

Awesome achievement! :clap:

Great!

@edjafarov you are a hero!

@edjafarov is there a realistic way to apply this to specific files in an installation with a massive installation? For example updating specific files out of date or version in an app with over 2GB of (possibly external) assets.

@Zayelion you will need to download full packages anyway. But you can update them in the background while app is working. In your specific case I guess you can put some assets outside of your executable and get them by node fs api from:

updater.prototype.getAppPath = function(){
    var appPath = {
      mac: path.join(process.cwd(),'../../..'),
      win: path.dirname(process.execPath)
    }
    appPath.linux32 = appPath.win;
    appPath.linux64 = appPath.win;
    return appPath[platform];
  }

If those are js, you can evaluate, or use static server for other stuff. In that case you will need to update just those.

Well done @edjafarov , glad the steps I outlined worked for you. What did you do to address the issues @Mithgol mentioned in the comment below mine?

@hardchor

1) webkit-updater spawns detached process so they are not overlapping. 2) there is no way to ensure this. But I assume that it's ok. People will run the app again and we need to handle problems there. Shit happens. It is not 100% bulletproof.

@edjafarov This is awesome, and I'll definitely be taking a closer look at this, but one suggestion. If the phrase "webkit-updater" is used anywhere in your code/documentation, and you're actually targeting "node-webkit", can you please change that to "node-webkit-updater"? I'm assuming it is indeed "node-webkit", the Node.js/Chromium desktop app runtime, you're targeting and not "WebKit", the browser engine used in Safari, Chromium, and other browsers, which doesn't integrate with Node.js.

It's not the end of the world, but some people care about terminology being correct, so I thought I'd help! Hope this helps!

@jamesmortensen are you sure that is an issue? node-webkit-updater is damn long package name;) Who else have problem with webkit-updater?

This discussion should be moved to the webkit-updater repo.

@edjafarov I did spend some time retagging and editing posts on Stack Overflow because a lot of people confuse WebKit with node-webkit.

I suspect the only people who will have a problem with the name, as it stands, are people who aren't in this thread, the people who do searches later for node-webkit and auto-updating, and who don't have the context of knowing that a lot of people use WebKit and node-webkit synonymously, despite them being different platforms. A name communicates something to potential users. What do you want to communicate to your users?

If that's an internal package name, then I suspect I'm making a case out of nothing. :) But if it's going to be a node module, like npm install webkit-updater, then that could potentially cause confusion, not to me or people in this thread, but all of the future developers who come after us who don't have this context. Hope this helps!

@edjafarov There is, for example, a package named fidonet-mailer-binkp-crypt in order to be specific. And thus “node-webkit-updater” does not seem damn too long.

Who else have problem with webkit-updater?

Maybe npm search does. The results of node-webkit update search do not mention your package on the first twenty pages currently (unless I missed it), and thus you could try some cheap SEO tricks, like populating keywords array in your package.json or raising “node-webkit” to the package's title.

Though npm search also takes popularity into account (number of dependents, number of downloads) and thus your package would skyrocket anyway soon.

@jamesmortensen ok. Done! Pls @jonathandelgado is right - any comments on node-webkit-updater move to https://github.com/edjafarov/updater or twitter

@edjafarov Great job! Thanks.

any plan to support the updater officially?

+1 for really needing a standard NWJS update feature.

I don't see a point making this unless there's a p2p local share feature as well, what I mean by that is if one client download's the update he can then distribute that version on the network if more people than him are running the very same application.

@makkesk8, p2p is a great idea. The updater clearly has value for many projects even without this.

I anyone using @edjafarov's updater with nw-builder/grunt-nw-builder?

:+1: for this . may I know what is the latest status of this ?

Now that we have access to chrome API is it possible to use Autoupdate? @rogerwang

Here is what we do, which allows us to seamlessly update application and updater itself (yep, even on windows).

• Start application from the index.js (instead of directly pointing it to the .html file)
• Open main window (so user will not have to wait)
• Create temporary folder in the system's temp directory (lets call it T)
• Create updates folder in the T folder.
• Download manifest file from the remote location. It has the format, which is similar to the one used in https://github.com/edjafarov/updater. For example:

{
  "version": "1.1.0",
  "createdAt": "2016-09-15T15:02:02.365Z",
  "win32": {
    "url": "https://example.com/windows-x32-v1.1.0.zip",
    "sha256": "a5db62bbe2c382534162d921ae6319ae83384256ab7f40e928a323603653e22b"
  },
  "darwin": {
    "url": "https://example.com/darwin-x64-v1.1.0.zip",
    "sha256": "e9efa23c40cf17a1d0c77227c962b5659c099959ec199782e03f162dcbbdae19"
  }
}

• Compare local app's version with the one from manifest file
• If app has the latest version from manifest - do nothing
• If app is outdated - download zip archive to the updates folder created before. When it is downloaded - show notification for user using new Notification or chrome.notifications.create. If user clicks on notification - proceed.
• Copy bundled updater executable to the folder T
• Run copy of the updater executable using spawn in detached mode and close application. Pass path to the downloaded archive and path to the main app executable to updater using command line arguments.
• When updater starts it unpacks zip archive to the temp directory. Than it creates backup of the old app by renaming parent directory to .bak (on macOS the Application.app will be renamed itself)
• Move unpacked files to the new location. If all went well - delete bak, delete temp files, delete zip archive and start main application.

Now you may ask - what the heck is bundled updater executable? It is small (~3MB) golang program, which can be compiled from any platform for any platform. When you build your app you can build updater as well and put it next to the executable (for Windows and, I guess, Linux) or inside of the Resources folder (for OSX build). Due to the fact that we copy executable to the temp folder and we run it from there - entire application, nwjs platform and updater on its own can be updated.

I guess all the steps from above can be wrapped into NWJS module and updater's binary can be bundled with the NWJS builds.

I will be happy to share the example of the golang updater if somebody will be interested :)

@oaleynik It would be great if you were to open source your updater!

@matthew-dean here it is https://github.com/oaleynik/nwjs-tiny-updater

I will add README soon. I'm not really strong in golang, so it is stupid simple and maybe can be written better, but it does its job :)

I think it can be written in any language, but I've selected golang because of its simplicity (for real, it took just several hours for me to write this updater) and because it can be compiled from any platform for any platform, which is kinda perfect for NWJS :)

@matthew-dean I've added short README. I hope it will be easier to understand what's happening :D

@oaleynik I built a whole update solution with node-webkit-updater before figuring out that it's completely unusable with NW.js after 0.13. (The whole method relies on spawning a copy of the app that runs the installer. But after 0.13 you can only have one app instance! ARRRRG.) Trying out your solution next. Thanks!

@matthew-dean sweet! Let me know if you will have any questions. I will be glad to get more feedback. I think the overall thing can be wrapped into the nice npm module or even integrated with the nwjs natively. I really hope this will land someday in NWJS :)

We tend to support the update solution made by community, not a built-in one. Thanks to @oaleynik 's solution and it is a good start. If you find anything we can improve in NW to make your tool better @oaleynik welcome to file an issue.

What is the recommended auto-update solution to use for NW.js at the moment?

• https://github.com/edjafarov/node-webkit-updater is not being supported by @edjafarov anymore
• @oaleynik 's https://github.com/oaleynik/nwjs-autoupdater has an outdated readme that has not been updated in three months

I realize that community contributors have limited time to work on these solutions as side projects - I just want to know where I should be focusing my time to get one of these working. Or is there another solution somewhere I'm missing?

@gniezen readme updated :) https://github.com/oaleynik/nwjs-autoupdater

The only difference - I've cleaned code a bit and used glide for dependency management

Thanks @oaleynik - nice!

@gniezen also - you are absolutely right - there is not much time I have to put there. The version I have in that repo has been working for months in my main project so I completely forgot about that README notice. Thanks for pinging me and as I mentioned in that README - I hope someday we will have such solution in NWJS out of the box :) I have some ideas on a relatively simple way to do it - when I will have a bit more free time I will try to put my thoughts together about it.

@oaleynik would you mind adding a PR for the official docs to introduce your solution? Thanks.

@rogerwang sure - https://github.com/nwjs/nw.js/pull/5703

I've now tried 3 permutations for updaters, and I've found that there are none that work perfectly, especially in variations of Windows permissions. In hindsight, probably the original problem I had with the traditional node-webkit-updater was that I had an incorrect path. Using any externally-compiled executable has mixed results, because without proper app signing, or app signing that matches your original app, it's not guaranteed to execute. Even if it executes, it's not guaranteed to extract. Even if it extracts, it's not guaranteed to have the right permissions to copy into the program files folder. At my work, we're trying to build apps that can self-update without user input, and so far nothing has worked consistently (at every client's location).

As it stands now, there really is effectively no solution. That is: a solution that works 100% of the time, other than running another installer from scratch.

In contrast, in the Electron project, there's an auto-updater that has very good documentation, and the only distributable you need is a single file, because of the ASAR file format (a non-compressed indexed archive that you can mount to Node.js like a single drive). I don't know how WELL it works, just that it appears to be well-maintained.

It's really unfortunate NW.js doesn't do more for packaging and distribution, because if your apps can't be easily installed, and they can't be easily updated, then you'll struggle to make anything with mass distribution.

In contrast, in the Electron project, there's an auto-updater that has very good documentation, and the only distributable you need is a single file, because of the ASAR file format (a non-compressed indexed archive that you can mount to Node.js like a single drive). I don't know how WELL it works, just that it appears to be well-maintained.

Electron actually doesn't come with an updater. It just has compatibility with the Squirrel framework. Which is a general purpose application update framework. You will need to use an additional package that builds your Electron project with Squirrel artifacts in order to get it to work. Additionally it works with or without the use of ASARs. You can learn more about it's implementation in the autoUpdater docs. Theoretically NW.js could implement it in a similar fashion.

Electron actually doesn't come with an updater. It just has compatibility with the Squirrel framework.

Oh, didn't know that, my mistake. Hmmm..... so each one is limited in some fashion? I wonder why this is such a hard problem?

I wonder why this is such a hard problem?

Anyone can make a basic auto updater. By basic you check for changed files, download a new file, and replace it. But say if you have a packaged NW.js or Electron project a basic auto updater is out of the question. Otherwise every update would be 30-50+ MBs for KBs or a couple MBs worth of changes. So now the only plausible updater must support delta updates. Squirrel for example is a delta update based framework which is why it is favored with Electron. With delta updates you only update the differences in the file. This however is a very complex system to create. Throw in the difficulties have having in use files blocked by the OS, multi platform, and other caveats and you really got your work cut out for you. So creating such an updater is a full time project more than it is a feature. So realistically I don't expect NW.js to create their own updater but focus on third parties and possibly build an interface for those third party solutions like Electron did.

+1

@rogerwang, I'm done with the pull request + the documentation https://github.com/nwjs/nw.js/pull/5722

why this is so complicated :( I built app for each os(win, osx, linux). Have 3 zip files. I put them on server. Now i want simple api to install update or not. But or this: i need to do a lot of commands, compile source for each os and waste more time then i spent on my app.

@Arti3DPlayer there is a solution for this feature, see https://github.com/nwjs/nw.js/issues/233#issuecomment-247450777

And we're also developing another, proposed by @jtg-gg .

Looking forward to an officially supported feature.

After reading all this issue I have a question.

Are you going to make an official updater or continue to recommend community solutions?

+1 Mark

@boostio funded this issue with $40. Visit this issue on Issuehunt

@loadbalance-sudachi-kun funded this issue with $256. Visit this issue on Issuehunt

If this is still relevant I wold love to work on this if someone can assign me