When looking at the application designer, we can see application ID in the link:
It is the same appid that will be added to the url when you open your application in Dynamics:
However, try adding that application(and the corresponding sitemap) to a solution, then export the solution, and have a look at the customizations.xml:
You’ll see the name of your application, but you won’t see the ID. You should probably see where this is going at this point, but let’s do a test.
Delete your application sitemap, and, then, delete the application from your Dynamics instance. Publish all customizations. Make sure the application is not there anymore. Re-import the solution exported above back to your Dynamics instance.
Your application will be back, but it will have a completely different ID:
Why would it even matter? Mostly, because there can be multiple applications in the Dynamics instance, and you may want to start adding application ID-s to the links you are sending by emails or using in the reports. And, if you follow some kind of application lifecycle methodology, you will likely have a dev environment where your application ID will be different from the same application ID in production.
So, before you start adding those ID-s to the workflows/scripts/flows/plugins, or anywhere else, you may need to figure out a way for getting application ID by application name somehow. If you need to use it in a workflow, you might create a custom configuration entity, store appID in the entity field, and use a custom workflow activity to get that entity. You might use a custom action instead (in this manner: http://missdynamicscrm.blogspot.com/2014/05/crm-2013-custom-action-as-configuration.html). You might probably just use a custom workflow activity to query app ID by name through FetchXml.. or do the same in the javascript through WebAPI.
Just don’t use the ID directly or you’ll have to re-configure the workflows/scripts/etc every time you deploy them in production as part of your solutions.