Support for local execution will continue to increase but not everything will be available day 1.
The newest version of V1 has Zwave plus, but not the early ones.
I remember Ben stating keep your expectations for hub v2 low:
Then you might have missed other (earlier) posts where he and/or other ST employees talked about local processing… how they’ll put everything they can to run locally, etc.
Technically we are putting everything we “can to run locally” as a running locally option 
respectfully, that is really different from what @Tyler has been posting today.
He’s been saying, and this is also reflected in the published documentation, that as of now, device types and smartapps must be reviewed and authorized for local operation by smartthings staff before they will run locally. This has nothing to do with any technical limitations on the code’s ability to run locally, which is what your statement seems to imply.
For example, a smartapp which required weather app information from a cloud service, could literally not run locally. It has to have Internet access in order to retrieve the values that it needs.
On the other hand, the community developed device handler for the smarten IT three toggle switch certainly could run locally, there’s nothing technical to prevent that, but because smartthings have not yet published an official device type for it, it will not run locally. An administrative decision, not a technical one.
Because this is a really big deal for a lot of us, I think it’s important that the staff statements do reflect the authorization requirement, not just say “can” as though it were just a technical issue.
The very same people who are able to write their own device types and smart apps are probably the ones who can evaluate technically whether code would require Internet access. But that has nothing to do with whether it actually will run locally under the current structure, which depends on administrative approval.
The above response was a poorly executed joke.
Been there, done that. More than once. 
Thanks for explaining.
@juano2310 answered in a much nicer way than I would as my response would simply be to say you are wrong.
I keep saying it: prove me wrong.
I can prove myself right based on links I’ve already posted. That’s the best information we have - that and CURRENT functionality. Not some fictional “might show up” or “only available to employees but might never be available to customers” stuff.
I cannot tell what you are right or wrong about but based upon how many posts of yours you have deleted you have to figure that you have been wrong at least a dozen times today.
We will run as many types of apps and capabilities locally as we can. We are not looking at specific SmartApps and device type handler submissions for this granular level of “approval”.
Please remember that our goals are aligned here: SmartThings and people who want things to run locally - we both want to run as much of it locally as we can.
Ben, being that you can very well read EXACTLY what I deleted, you know WHY I deleted each one. For example, I posted when the status page wasn’t being updated… when it finally was, I deleted the post. Or when the ide went down, and I posted that it wasn’t back up yet… and then deleted the post when it DID come back up.
There’s no need for people to waste time reading my harshness when the issue is finally corrected.
I don’t read deleted posts on principle.
I’m confused, is this external apps that communicate with ST using that URL? Where do we use these commands to get the new URL? Example please?
Is there some way for users to choose where the app runs or some way for ST to figure it out? For eg if using schedulers and timers definitely want it running locally (assuming the Devs have done a better job in the local scheduler than the cloud) rather than cloud. Plus it reduces the load on the cloud. The other day some DEV was complaining about “spamming” the cloud because of the polling frequency. That should not be a problem locally.
Maybe I should phrase my question differently. What guidelines should a DEV use to determine when developing code on what should run locally and what on cloud?
Ie why would ST NOT want to run locally?
That will, apparently, show which apps are running locally. See the very next post after that from @Tyler for answers to more of your questions. My impression of that next post is that we’re going to be transitioning from “a few weeks” to “a few months.” (However, I think google already owns the trademark on “a few months”, so not sure how ST will deal with that.)
You need to use these commands when you want to create web services SmartApps. This is allow external applications to make web API calls to your SmartApps (obviously you need endpoints for your SmartApps). You can go to this page for examples.
Right but these won’t work with local processing right? since the URL’s point back to the API server in the cloud.
You are correct, Sir.
@Jim there’s an issue with getApiServerUrl(), when I run it it returns:
many devices don’t support HTTPS and also don’t support the :443 format, what if I just want http://url.com how do I get that?