I’ve just update snapd-git package on our end in unstable to version v2.30dev+171219+g5f5180e. snapd itself is still at v2.27.6. I’ve to see when I might update it.
@mborzecki has a different PKGBUILD and install method. I’ve to check if it is good to adopt his changes made to the scripts. On first glance they look good.
I’ve pushed a small fix for Arch packaging:
I try to keep the snapd-git AUR package in sync with the packaging in snapd repo. There’s also ongoing work to make Arch part of CI. This should make life a bit easier for Arch like distros.
Nice Work @mborzecki, but there are still some limitation, i can’t update snapd version using different core channel, for example i wanna try 2.30 on arch linux, i can’t 
Not understanding what you are trying to achieve. You can install @mborzecki 's package from the AUR, it is called snapd-git to get 2.30. Understandably it builds from the master and not a release.
The way snapd is meant to be update is by updating core. But in this case we have to build snapd from git.
FYI, the snapd package has been moved from community to AUR and is now avaialble here: https://aur.archlinux.org/packages/snapd. The package was adopted by @Aimilius (thanks!) and got updated to 2.30 release.
As a results of a review from one of the Arch TUs, the snapd AUR package was updated with the following changes (thanks to Emiel for doing the work!):
The snapd ArchWiki page was also updated with notes on classic snaps.
I’ve synced snapd-git, so the changes are in both packages now.
This makes the skype classic package fail to launch because of the missing symlink.
We are aware of this. The change was requested by one of Arch devs. Attempting to run a classic snap you should get a message with instructions on how to get it working. Also, there is a note in the wiki page https://wiki.archlinux.org/index.php/Snapd#Classic_snaps
Thanks I didn’t know that. But it would be nice if the application didn’t suddenly stop working after a packaging change. Maybe a post-install message in snapd might be good.
According to my knowledge, snapd is meant to update by updating core?
But this isn’t the case with Arch Linux.
For any change in git, have to rebuild it from AUR.
What are the limitation so far?
Snapd and core are different things. You update snapd from AUR and update core from snap: snap refresh core
There are still some compile time decisions made. When they are gradually removed each distribution can choose to opt-into the refreshing of snapd directly from a snap.
Oh, and let me just say that @mborzecki’s work just today made it much easier to allow Arch to do this 
As @zyga-snapd mentioned there is still some code that requires compile time configuration. While the pieces in Go rely on run time detection, snap-confine is in C and is currently and relies on various configure switches. There are some ideas about reducing this configuration, but it will obviously take some work and time to get it done.
I an curious about Sandboxing.
As far i know sandboxing is done by AppArmor and AppArmor isn’t enable in Mainline kernel provided by Arch Linux.
So that mean the snap app aren’t in sandbox?
Though what are the advantages of sandboxing?
On snapd-git you should be able to run snap debug sandbox-features to see what kind of sandboxing elements are present on your system. Sandboxing without apparmor is not as strong as without it but it’s not an all-or-nothing game.
The benefits of sandboxing are, obviously, that it is harder to attack the system by installing a malicious application.
How secure is snap without AppArmor compared to Flatpak?
And can we see AppArmor being enabled by Default on Arch Linux?
