We are building a system based on Yocto+snapd. While discussing about possible points of failure, we pondered upon the question that what would happen if snapd broke on our image. Will that prevent all our installed snaps from functioning ?
This is important for us because we plan to ship our OTA update service as a snap package as well and if snapd breaks on our system due to whatever reason, that could mean we won’t be able to “update” the system at all without physical intervention.
To add to what @Spencer said - in my experience, yes, things that were installed as snaps will run fine without snapd itself running. You can experiment by simply disabling the snapd service (systemctl disable snapd) and seeing how things look. If you check the system logs you’ll see that all snaps (the squash .snap files) are still mounted under /snap, and all services that are installed by snaps are intact - because those are all installed as systemd units at installation time, and will persist even if snapd itself isn’t present at runtime.
What will definitely not work without snapd is things like refreshes (and installs, uninstalls), and many (though not all) of the actions you can invoke through the snap CLI.
In practice, we’ve had systems in the field where snapd itself has become unusable (e.g. because state.json has got corrupted - see https://forum.snapcraft.io/t/snapd-cannot-run-daemon-cannot-read-state-unexpected-eof/), but the snaps themselves have continued to run fine.
This is based on my experience with snaps installed on Debian, which does not have AppArmor (and therefore no snap confinement). The behavior may be different on Ubuntu Core or another OS.
it might work to just have snap-confine and the other bits to establish the confinement working without snapd when systemd units are in place and the full installation has properly happened … but as soon as your snap calls out to something like snapctl from i.e. a wrapper/launcher and there is no daemon listening you might see everything fall flat on its face …
To be clear, it is a design goal of snapd that application snaps can run if snapd is unable to startup properly due to a bug or something. This is with the obvious exception that @ogra points out that if your snap uses snapctl or otherwise tries to interact with snapd and snapd is dead, well then that is not going to work, but you could always make your application extra robust against this case as well if you really are concerned about robustness.
So TLDR, yes you should be okay to rely on your app snap service to be able to run even if the snapd service gets botched somehow. That’s not to say that there can’t ever be bugs where an app snap does fail to start because snapd is botched, but that we will try very hard to not have those bugs 
However, we would just like to make clear that it is not a goal of snapd to enable running snaps without snapd available at all, snaps are not something that is separate from snapd that you could install and then remove or disable snapd at that point. There are various reasons why, but the gist of it is that snapd should be able to try and start up so that it could minimally refresh it’s state with the store/internet in the form of assertions and also to apply updates in the form of refreshes.
Which overall architecture component’s task is to ensure snap to snap interfaces, also interfaces to host resources can operate, be used…? There might further tasks this class.