So does webcore stop working when the classic app stops working?
Both apps are a user interface. Webcore works in the cloud and the UI works in the new app. The tricky part is installing it, which can only be done via Classic. So technically it works fine without Classic once it’s installed with Classic.
So I suppose in that example it depends what you mean by “works.“
There’s also the issue that the entire cloud platform is transitioning to something new, and webcore definitely won’t work for either old or new pistons once that happens. Whether somebody is going to find a way to replace the functionality of the SmartThings groovy cloud for webcore is yet a different question.
The Hubitat groovy implementation is very similar to SmartThings and most smartapps designed for smartthings can run there, but they have found that a number of their customers had problems trying to run webcore so they recommend using their own rules engine instead.
Webcore is an astonishing accomplishment, and much to be admired, but the circumstances that brought it into being may well be unique.
The latest webcore on HE is being reported to be very stable for folks.
So a lot of changes have happened in last month or two.
The SmartThings Classic App deprecation isn’t the primary reason for concern.
The deprecation of the “Groovy API” is - and there is definitely no announced timeline for this - neither for Device Handlers nor SmartApps (“Automations”).
There’s plenty of reason to be confident WebCoRE can be ported to the new API, but plenty of uncertainty if it will be and if SmartThings will support and approve its publication.
To be clear: No one at SmartThings has said WebCoRE won’t be migratable or might be disallowed. But nobody has (or can!) guarantee it will exist indefinitely.
And also acknowledge that the number of WebCoRE using customers is a very number to Samsung and they have discontinued significant initiatives on the past (Windows Mobile App, and the ZigBee based Arduino Development Kit Shield, …).