Like onAppInstall and onAppUninstall, if you could provide an onSettingsSaved event, it could be used effectively.
Here’s my use-case:
On App Install, I create a recurring schedule.
On every subsequent “save” app settings, I need to delete the old recurring schedule and create a new one.
Because onSave is when I get the timezone information.
We made afterAppUpdate as the app setup event live. It’s not precisely the same runtime that will be invoked when the user clicks save but does when the user clicks update.
Thanks @Saif , you guys rock as usual.
That is some very well documented and thoroughly thought-through feature.
Thank you again for listening to your developers and making the developer platform better each passing day.
Also, curious to know why it was named afterAppUpdate and not onAppUpdate like the rest of the events?
Technically, the app is not updated if afterAppUpdate throws an error. So, it will be misleading to call it afterAppUpdate because the app update was aborted.
Are there plans to bring the onAppSave event as well?
I will share some thoughts we took together, maybe your feedback will help us improve.
The runtime (afterAppUpdateHandler) will be invoked after the current installation (let’s say v2) is updated to v3. This means the authored code can depend on the new logic of v3 (may be in app.js or server.js, for example) in the execution context of v3’s afterAppUpdateHandler.
This also leaves us an open space in the future to invoke the beforeAppUpdate where the handler will be invoked before v3’s code is unpackaged. However, we are waiting for use cases to emerge to ship something like it.
Woow, it makes sense now.
So, the app will actually be updated to v3. And when v3’s afterAppUpdateHandler throws and error, the app will be downgraded to v2. Right? If it doesn’t throw an error it will continue to be on v3.
You are right, Arun. 
