Windows10 Anniversary Update - API Changes 1

来週に控えたWin10 Anniversary Update. 変更について4月の//build 2016からちくちくと追いかけていたのでざくっとまとめておこう、という趣旨の記事です。数回続く予定です。

Image ControlがAnimated GIF対応

いつも使っている Image Control がそのままアニメGIFに対応しました。ImageSource PropertyにGIFを設定するだけで絵が動きます。楽しい（Visual Studio上のXAML Designerの時点でもう動きます） 。  

AccessKey

https://msdn.microsoft.com/en-us/windows/uwp/input-and-devices/access-keys

所謂ショートカットキーのインプリが泣く程簡単になります。Button等、ElementのProperty AccessKey にショートカットキーを書くだけで基本終わりです。 UserControlだろうが何だろうが効きます。

<Button x: name=”myButton” Content=”Go” AccessKey=”G” Click=”myButton_OnClick”/>

これでAlt+Gを押下するとOnClickが呼ばれます。 ただ、5月頃のPreviewで試した時は、ALTによるToolTip表示は自分でやらねばならず、またAppBarが出入りするような実装だとそれにToolTipが付いてこないなど、割と面倒な感じでした。 また、ショートカットの重複を誰かが気にしてくれるとかも特に無いです。自分で気を付けましょう。    

その他XAML 小ネタ

• Pivot … くるくる無限選択を無効に出来る IsHeaderItemsCarouselEnabled　下線マークのフォーカス表現がデフォで可能に HeaderFocusVisualPlacement
• Element一般にフォーカスが当たった時に音を鳴らす（XBOX用）
• CommandBar、文字ラベルをアイコンの右横に表示可能に　また、Automatic Overflow にやっと対応 Appの幅が狭くなったら自動的にSecondaryに移動してくれる Overflowは既定でOn
• PopupのStyleに「Smoke」が追加 ContentDialogのように背景がぼやけるやつ
• x:Bindが異常に強まっている https://msdn.microsoft.com/en-us/windows/uwp/xaml-platform/x-bind-markup-extension
  • 全部OK
  • {x:Bind ViewModel.hogehoge.ToString() }
  • Text={x:Bind File.Properties['Artist'].Name }
  • Visibility={x:Bind (visibility)ViewModel.IsVisible}

Win10 Anniversary Update SDK API Diffs 14366

API Diff + msdn docsへのリンク（各APIのMSDN Docs のURLは決め打ち まだ文書が無いと404）


10586 vs 14366

http://ddlgsite.azurewebsites.net/ApiPeek/win10.10586.to.win10.14366.diff.html

http://ddlgsite.azurewebsites.net/ApiPeek/win10.10586.to.win10.14366.fulldiff.html


14291 vs 14366

http://ddlgsite.azurewebsites.net/ApiPeek/win10.14291.to.win10.14366.diff.html

http://ddlgsite.azurewebsites.net/ApiPeek/win10.14291.to.win10.14366.fulldiff.html


（API Diff の元ネタは  https://github.com/martinsuchan/apipeek  )

MSDN docs

API docs - indexed

実際にDocがUploadされてからIndexingされて下の検索に引っ掛かるまでタイムラグがある

Version 1607
https://social.msdn.microsoft.com/search/en-US/windows?query=introduced%20version%201607&refinement=183&ac=5

14366
https://social.msdn.microsoft.com/search/en-US/windows?query=introduced%20version%2010.0.14366.0&refinement=183&ac=4

14339
https://social.msdn.microsoft.com/search/en-US/windows?query=introduced%20version%2010.0.14339.0&refinement=183&ac=4

14295
https://social.msdn.microsoft.com/search/en-US/windows?query=introduced%20version%2010.0.14295.0&refinement=183&ac=4

Topics

APIと一対一に対応するDoc「以外」のTopicについては、最近更新があったらBlogで教えてくれるようになりました。有り難い。

https://blogs.msdn.microsoft.com/windowsdocs/

UWP と フォルダを介したデータ共有

UWP / StoreApp では、アプリが「直で」アクセスできるのはアプリそれぞれが持つフォルダのみである！という原理原則があります。

File access permissions
https://msdn.microsoft.com/en-us/windows/uwp/files/file-access-permissions
Open files and folders with a picker
https://msdn.microsoft.com/en-us/windows/uwp/files/quickstart-using-file-and-folder-pickers

この縛りがあるために、UWP / Store Appは他のUWP / Store Appや、ユーザーのファイルを直接触る事が不可能であり、窮屈だけど安全な環境になっております、という事になっています。

…が、原理原則だけでは人は生きては行けないので…Win10 UWP では多少その辺り柔軟な対応になってきています。ここでは、フォルダを介したデータ共有として有名なものと、そうでもないものを紹介します。

GetPublisherCacheFolder

https://msdn.microsoft.com/en-us/library/windows/apps/windows.storage.applicationdata.getpublishercachefolder.aspx

有名なほう。

• 同じマシン
• 同じユーザー
• 同じアプリベンダー

の、複数のアプリ間で共通に使えるフォルダです。

このフォルダにアクセスしたいアプリは、各々のアプリのPackage.appxmanifest でアクセスするフォルダ名を<Extensions>内で宣言する必要があります。

Package.appxmanifest

デザイナでは変更できないので、右クリック→「コードの表示」で編集します。

上のように宣言したアプリは、コード中で以下のようにフォルダにアクセスできます。
ポイントとしては、このフォルダはアプリから直でアクセスが可能です。Windows.Storage ... OSのBroker Process を介さずに、.NETならば System.IOで直で触ることができます。

CacheFolderに触っている様子 直アクセスOK

なお、このフォルダの物理パスは

C:\Users\<UserName>\AppData\Local\Publishers\<publisherId>\<CacheFolderName>

になります。<CacheFolderName> は、上のManifestで指定した名前です。

SharedLocalFolder

https://msdn.microsoft.com/en-us/library/windows/apps/windows.storage.applicationdata.sharedlocalfolder.aspx

無名なほう。

• 同じマシン
• 同じアプリ

の、複数のユーザー間で共通に使えるフォルダです。

このフォルダにアプリからアクセスしたい場合、まず管理者がHKLMのレジストリを変更する必要があります。以下のKeyを作成し、DWORD Value "AllowSharedLocalAppData" を 1 にセットします。

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\AppModel\StateManager

上のRegistry Flagがセットされている場合、UWP Appから「SharedLocalFolder」にアクセスできます。ちなみに、Flagが0又は存在しない場合はfolderにnullが返ります（システムの既定ではKey "AppModel" 自体が無い）。また、このフォルダもアプリから直でアクセスが可能です。

SharedLocalFolder に触っている様子 こちらも直アクセスOK

なお、このフォルダの物理パスは

C:\ProgramData\Microsoft\Windows\AppRepository\Families\<PackageFamilyName>\SharedLocal

になります。フォルダ内で作成されたファイルはアクセス権が「Everyone-FullControl」になります。

また、このフォルダは上記Registry Value が設定されている場合、アプリ側で当該フォルダを使用しなくても勝手に作成されるようです。アプリ起動時のタイミングで作成されているように見えます（つまり、フラグをセットすると全UWP アプリでこのフォルダアクセスが有効になります。要注意）。

背景

UWP がお披露目となったBuild 2015では、UWP App 間でデータ共有を行う手段が幾つか追加されました、という文脈の中で前者 PublisherCacheFolder が紹介されていました。以降のWindows Blog等でも紹介されていたように記憶しています。

一方、後者のSharedLocalFolder はBuildでは完全にスルーでした（そのはず）。　VisualStudioでいそいそとコードを書いていると、ApplicationData.Current のIntelliSenseでチラチラ表示はされるので存在は知っていたのですが…いざMSDN Docを見ると木で鼻を括ったような全くなにも説明していない表記で、何ぞこれ？？？という。

状況が変わったのは以下のBlogで…MSのフィールドエンジニア氏がこんなんだよーと説明していました。まじか。
https://blogs.msdn.microsoft.com/notime/2016/03/04/sharing-data-between-users-of-a-universal-app/

ただ、実際こう見てみると…半ば隠しAPI扱いなのもやむを得ない感じですね。
HKLMの変更が必要であるため、UWPだけで使用可能になる類の物ではありません。管理者権限が必要です。

（Registry Editorの無いMobileや他のDeviceFamilyではどうすんだろう？という疑問もあります）

実際に使用されるケースは…LOB Appでの使用、All UserなWin32 Appとの協調動作を企図した使用等、かなり限定的なのではと思われます。

Desktop App Installer を使ったUWP / Centennial AppXの配布

4月末、MSがDesktop App Installer なるUWP Appをストアに載せてこっそりテストしているよ、という記事がMSPowerUserに載りました。

Microsoft Desktop App Installer now available in the Windows Store
http://mspoweruser.com/microsoft-desktop-app-installer-now-available-in-the-windows-store/

このアプリ、まだストアに載っており、誰でもDownload・Installできる状態です。
この記事はDesktop App Installer を試し、これからのUWP AppのDeploy方法について考えてみたよという話です。

Microsoft Desktop App Installer
https://www.microsoft.com/store/apps/app/9nblggh4nns1

※インストールできるのはWin10 RS1 以降です。Win10 TH2には入りません。
※5月6日追記…今上がっているPackageは「Win10 Desktop / Mobile, x86/x64」が対象であるため、殆どのWin10 Mobileには入りません。
※5月9日追記… 名前が「App Installer」に変わり、Win10 TH2 にも入るようになりました。しかし、試した所App Installerを使ったUWP App のDeployには失敗してしまいます。
※5月30日追記… MSDN Blogに記事が載ったようです（今まではストアにあったアプリを勝手に見つけて撫でまわしてるだけだったので…）

App Installer!!
https://blogs.msdn.microsoft.com/appinstaller/2016/05/27/app-installer/

記事によると、Win10 Anniversary Updateには最初からApp Installerが入っているようです。

背景

この「AppXをDoubleClickしてインストールできる仕組み」、最初にお披露目となったのはBuild 2016, UWP AppModel Sessionの中でした。"Modern Desktop App Installer"としてAppXをストア外で配布する手段が確立されましたよ、という文脈です。

Universal App Model Overview: What's New in the UWP App Model
https://channel9.msdn.com/Events/Build/2016/B809
（当該箇所は5:19あたりからです。説明・デモでいろいろ大事な事を言っているので、スライドだけでなくセッションの視聴をお勧めします。また最後のQ&Aも）

説明ではCentennialでConvertしたPaint.netをDeployしていますが、別にCentennial用という訳では無く…AppXならばGenericに使うことができます。以下の例では UWP AppのAppx Packageを使っています。

AppX をDoubleClick するとどうなるか

Desktop App Installer をインストールすると、.appx / .appxbundle が Desktop App Installerでの実行に関連付けられ、小包アイコンで表示されるようになります。

拡張子 .appxbundle に Desktop App Installer が関連付けられている様子

ダブルクリックすると、Desktop App Installerが起動します。

仮のUWP App "Shumen" のAppxbundleを起動した様子

この画面以降、インストールできるかどうかは以下の条件により変ってきます。

AppX 未署名の場合・又は証明書がインストールされていない場合

以下のエラーメッセージが表示され、インストールは出来ません。
Either you need a new certificate installed for this app package, or you need a new app package with trusted certificates. Your system administrator or the app developer can help. A certificate chain processed, but terminated in a root certificate which isn't trusted (0x800B0109)

つまり、あなたのAppXがTrusted Rootな証明書で署名されているか、又は、あなたのAppXの署名に使った証明書が「この」システムの証明書ツリーにインストールされている必要があるよ、という事です。

前者…Trusted Rootな証明書での署名は、これまでもApplicationの配布時にはほぼ必須となっているもので、自分が自分であることをVerisign等の発行業者から年数百ドルで証明書を購入することで発行業者に裏書きしてもらいましょう、その証明書でバイナリに署名しましょう、という話です。

後者は所謂「オレオレ証明書」と言われているもので、Appx作成に使った.cer をシステムにインストールすれば前者と同じことにはなります。違うのは、自分が自分であることを証明するのは自分しかいない所です（なのでオレオレ）。
限定的な配布のテスト用途等には使えますが、一般配布にはもちろん使えません（エンドユーザーに.cerを渡してTrusted Rootにインストールさせるのがどう考えても間違いである、.cerが他者に使われてしまう恐れがある、不正なTrusted Rootとして使用を停止される恐れがある、等々ダメな理由はいくらでもあります）


以降は、上の条件を（オレオレ証明書で）クリアした環境下での検証結果になります。また、以下で参照している「開発者モード」とは、設定→更新とセキュリティ→開発者向け、で設定できる以下の項目の事です。

「開発者モード」

開発者モードが「Windows ストア アプリ」（既定）の場合

実行すると以下のErrorMessageが表示される。
To install this app, turn on sideloading mode in Settings > Update & security > For developers. If you can't turn it on, ask your system administrator to unlock the machine for sideloading (0x80073CFF)

開発者モードが「サイドロード」「開発者モード」の場合

実行すると特にエラーなくインストール可能

これらから、Desktop App Installer は「サイドロード」以上の設定を必要とすることが分かります。
また、この設定→アップデートとセキュリティ→開発者モード、の設定は一般ユーザーには変更ができず、管理者権限が必要になります。
（おそらくPolicyのDeployは可能と思われますが、基本的に管理者マターであるという事になります）

参考...バージョンアップ・ダウンについて

バージョンアップ又は同一バージョンの場合…特にメッセージは無く、置き換えが行われます。未確認ですが、通常のストアでの更新同様にApp構成ファイルは入れ替え、AppLocal Settings/Folderは維持と思われます。

バージョンダウンの場合…以下のエラーメッセージが表示され、インストールはできません。
There's a newer version of this package already installed. To install this older package instead, uninstall the one currently on your system (0x80073D06)

参考…「PowerShellを使った配布」について

これまでは.ps1 を使うDeployが開発用に使われていました。
この.ps1で行っているのは、

• 開発者モードを「開発者モード」に変更　(PowerShellはSettings Panelを表示するまで 変更自体はユーザーが自分でToggleButtonを押す)
• .cer をシステムにインストール

という動作です。

• 開発者モードに入れる事
• 実際にはユーザーにボタンを押してもらう事
• .ps1を右クリックして「PowerShellで実行」を選択してもらう事

等、基本的には…エンドユーザーにさわってもらう形にはなっていませんでした。

この項まとめ

今回のDesktop App Installer によって、（証明書を用意できるのならば）「エンドユーザーにストアを介さずAppXを直接ダウンロード・インストールしてもらう」という形がかなり現実的になったと言えるでしょう。

※ 現在は「Desktop App Installer」という独立したUWP App Packageになっていますが…これOS組み込みにしない理由が僕にはどうもわかりません。単に今回は試験中だからかもしれませんが。後から別にインストールするのは手間ですので、RS1 GMには最初から入っている形が望ましいと考えます。

ストア外配布の現実味と将来

Win10 RS1では、上で挙げたセッションで云うように「ストア外」での配布が可能となっています。

ただ、これまで見てきて分かるように、あくまでも署名付きパッケージのみの話と考えるのが正しいように思われます。
「署名の無い」パッケージについては、事実上、一般配布は極めて難しいように思われます。

※未署名パッケージ配布の是非を論じるのは僕の手に余るのですが…個人的な印象としては、（可能であったとしても）未署名のパッケージ・バイナリを配布するのが許される世の中ではもう無いのかなという気がしています。

未署名パッケージ配布は脇に置くとして、これからのUWP Appの配布方法としては

• Microsoft Corporationと契約し、Windows Storeを使った配布を行う
• 自前で証明書を調達し、自前でAppXを配布する環境を持つ

この二択になると思われます。

ただ実際のところ…殆どのソフトハウス・個人開発者等は前者…Windows Store を選ぶだろうという気がします。
以下に簡単な長所・短所比較を挙げてみます。ほぼ裏表になりますが、


Windows Store

長所

• ダウンロード・更新システムをMicrosoftに丸投げ
• アプリ販売・IAPシステムをMicrosoftに丸投げ
• Ad Mediationを使用可能
• OS持ちの既定のマーケットである

短所

• 販売に30%のMS税がある
• アプリを載せるのにCompliance Testを通す必要がある（極端なエロス等は無理）
• Testに数日かかる
• バカな伸びしろのあるTesterと付き合う必要がある
• ストアがバグると大変なことになる（2015年は本当に大変でした）

自前配布

長所

• 売上総取り（料金システムが自分持ちなら）
• Compliance Testを通さなくていい
• そもそもTestが無い

短所

• ダウンロード・更新・認証システムを自分で持つ
• アプリ販売・IAP システムを自分で持つ
• 証明書を自分で買う必用がある
• Ad Mediation を使えない
• 既定のマーケットではない…見つけてもらえるにはどうすれば

※認証システム…AppX をそのまま配布する場合、そのままではいくらでもCopy可能です。
CopyFreeにするのでなければ、何らかの「認証」の仕組みを自分で持つ必要があります。
キーを販売し、App起動時に認証サーバに見に行って認証する、というような。何かのアカウントに紐づけてもいいかもしれません。


…どうでしょうか。
個人的には、自前配布で短所の要件を克服するよりは…Testの面倒さと30% のAdmission Feeを受け入れたほうが楽かなぁという気がします。
特に、今はゲーム・非ゲーム共IAPでおぜぜを頂く道がとても大事です。そこを全部自前でやるのはなかなかつらいのではと思います。

MSさんもそこはわかっているようで、Win10 RS1ではWindows Storeが大幅に拡張されることになっています。以下のセッション見て頂ければわかるのですが、ざっくりいうとSteamのStore的なものをそのままWindows Storeに持ってくるつもりのようです。

Windows Store: Publishing Apps and Games to Desktop, Mobile, and Xbox
https://channel9.msdn.com/Events/Build/2016/B839


逆に、自前配布の短所で列挙しているような用件を全部自分でクリアするのではなく、ある程度割り切ることで現実的な自前配布も在り得るのかもしれません。
普通のソフトハウスならば証明書は既に持っているでしょうし、認証の仕組みさえクリアできれば何とかなってしまう場合も多いように思われます。Windows StoreのマネをしてMSAなら10個まで、でも良いかもしれません。


また、上の比較は主にConsumer…一般向けアプリで考えてみたのですが、これがLOB…社内配布向けになると全然別の話になりそうです。しかし長くなってしまったので…このあたりにしておきます。

Win10 Anniversary Update SDK API Diffs

API Diff + msdn docsへのリンク（URLは決め打ち まだ文書が無いと404）

10586 vs 14328

http://ddlgsite.azurewebsites.net/ApiPeek/win10.10586.to.win10.14328.diff.html

http://ddlgsite.azurewebsites.net/ApiPeek/win10.10586.to.win10.14328.fulldiff.html

14291 vs 14328

http://ddlgsite.azurewebsites.net/ApiPeek/win10.14291.to.win10.14328.diff.html

http://ddlgsite.azurewebsites.net/ApiPeek/win10.14291.to.win10.14328.fulldiff.html

10586 vs 14291

http://ddlgsite.azurewebsites.net/ApiPeek/win10.10586.to.win10.14291.diff.html

http://ddlgsite.azurewebsites.net/ApiPeek/win10.10586.to.win10.14291.fulldiff.html


MSDN docs

14295
https://social.msdn.microsoft.com/search/en-US/windows?query=introduced%20version%2010.0.14295.0&refinement=183&ac=4

14339
https://social.msdn.microsoft.com/search/en-US/windows?query=introduced%20version%2010.0.14339.0&refinement=183&ac=4

元ネタは
https://github.com/martinsuchan/apipeek

UI.Composition でListView/GridView を賑やかす

UI.Composition を使い、スレッドカタログにアニメーション効果を付けた F10 をリリースしました。

F10 image bbs browser
https://www.microsoft.com/store/apps/f10-image-bbs-browser/9nblggh1ntrd

TH2から使えるUI.Composition を使ってGridViewに要らんアニメを付けるテスト たのちい pic.twitter.com/hBs03ltt16

— 佐藤 pnp0a03 (@pnp0a03) 2016年4月17日

このGridView のItemをくるくる回す部分を抜き出した簡単なサンプルプロジェクトを作りました。

CompositionGridView
https://github.com/pnp0a03/CompositionGridView

MSさんのサンプルには面白いのが沢山載ってるんですが、一番単純な…単にList/GridViewものをくるくる回す的な意識の低いサンプルが無くて難儀したためです。

MSさんのUI.Composition Sample
https://github.com/Microsoft/WindowsUIDevLabs

ここでコードぺたくた貼って解説するより読んだほうが早いですよね。

UI.Composition について

Visual Layer
https://msdn.microsoft.com/en-us/windows/uwp/graphics/visual-layer
... この項、概念から具体的な操作例まで満遍なく記述出来ている良記事 MSDNでは少ないタイプです。ｵｽｽﾒ

上の記事を読んでいただければいいんですが、XAML Framework から DirectX Layerの間に一枚あったDWM... Visual Layer, UI Composition を Win10 TH2から使えるようになりました、という話です。

XAMLレイヤから降ってきたUI Element、またはVisual Layer の中で作ったRectangle・Imageに対して、Effect・Animationを掛けることが可能です。

XAML→DirectXのパイプラインに手を突っ込んで描画を捻じ曲げるような感じがあります。


以下に参考になるリンク集等。


Creating Beautiful UX in a Real-World App with Visuals, Animations and Effects
https://channel9.msdn.com/Events/Build/2016/B818
...　GridView/ListView のItem弄る元ネタはこのセッションの途中からﾊﾟｸ参考にしました。Slideだけだと肝心のCodeが見えないので、面倒でも動画を見るのがお勧めです。英語ですが字幕Onにできますので。また、2016年夏予定のRS1で入るUI.Compositionの変更にも触れられています。


MSさんのUI.Composition Sample
https://github.com/Microsoft/WindowsUIDevLabs
... Build 2016 で使っている部分を多く含むサンプル。また、下のDiderikさんサンプルでも参照されているComposition ToolKit ... Visualに対してImageをロードするコード、もここから取得可能です。Visual Layerの中で色々やるには多分必須。
また、Sample はRS1用の新APIを使うものも含んでおり、RS1上のVSでBuildすると見られます（バグ多し）。


Diedrik Krols さんのBlog
https://xamlbrewer.wordpress.com/category/composition-api/
... MSさんの解説・サンプルは基本的にXAML のElementに対してVisualを作って操作する、物がメインなのですが、Diedrik さんのサンプルは珍しく「Visual Layerの中だけで作った」Visualを操作して色々描いてみる、というスタイルです。

robmikh blog
http://blog.robmikh.com/
UI.CompositionTeamの中の人のBlog
特に、Why even use Composition? は読む価値があると思うのでｵｽｽﾒ。DWMにやらせることでApp（UIThread）側の負担ゼロで秒60コマのアニメーション・エフェクトを使えるのがUI.Composition の利点で、XAML上のStoryBoard使ったアニメーションではこれは無理、という大事な話
Why even use Composition? / Images and effects
http://blog.robmikh.com/uwp/composition/2016/04/21/images-and-effects.html

Build2016 API Readiness

（訂正 2016/04/29... RS1以降のAPI を使うには、NuGet Package　Microsoft.NETCore.UniversalWindowsPlatform を手動で5.1.0に更新することが必要なようです。既定の5.0.0だとBuildできない、通らないものが多いです。← 14332 Releaseと同時だったので今となってはよくわからない）

build 2016で説明されていた新機能が、現状のWin10 RS1 14295 SDKにどれくらい入ってるのか…すぐ使えるのか、ビルドは出来るけど動作怪しいのか、全く入ってないのか…を自分で確認したもの表です。

（個人的に興味があるもの…UWP App関連＋Centennialだけ見ているので、ほかの要素は全くノーチェックです）

Item	説明	現状
FullTrustProcessLauncher msdn doc	UWP App Package内のWin32 AppをUWP Appから起動する…という謎のAPI 今まででは考えられないタイプのやつ 多分Centennialで作ったPackage用	Build不可 このAPI Callに必要なPacakageManifest内のCapabilityがSchemaに入ってないので全く無理
AccessKey msdn doc build session	XAMLのショートカットキー革命	動作する　超便利
TrySetDisableLayoutScaling	謎 これを呼んだAppのScalingをDisableするらしいけど	Callは出来るが常にFalse（失敗）　効果自体謎ではあるのでよくわからん
ExtendedExecution、BackgroundTask系 build session	Build2016で説明のあったやつ	Diffと、MSDN HelpDocのAvailabilityを見る限りまだ準備されていない
CommandBarの自動オーバーフロー build session	幅が足りなくなると自動的に今までのSubMenu見たいになるやつ（伝わる？）	既定で動作する　ただ一部Propertyは現在XAMLで指定するとRuntimeに落ちる事がある
Pivot		HeaderOverflowModeをセットするとアプリ起動時に死ぬ これ以外にも14295 SDKでBuildしたPivotは、もともとXAMLでPivotItemを指定していない場合CodeからPivotItemを追加できない等動作が不安定なので注意
ImageのAnimated GIF Support build session		これだけはちゃんと入ってる SourceにアニメGIF指定するとXAMLデザイナ上でアニメGIFが動く だが、ウェイトサポートが適当で正しく再生されないAnimated GIF が多い 正しい再生を行いたい場合はGifImageSourceを使うのがお勧め
Ink		まだ見れてないです　（ペン対応PC持ってないので出来る事が少ない）
UI.Composition		UI.CompositionについてはGraphicsTeamが自前で持ってるSample TreeがGithubにある こっち見るといいです https://github.com/Microsoft/WindowsUIDevLabs
Project Rome系 build session	IPC的な仕組み CortanaがDevice間でデータを同期するのに使ってるのがこの仕組み　わかりづらいけどうまく使うと良いものになりそう	まだ見れてないです
Map系		まだ見れてないです
App Extension系 build session	後からPackageに新しいバイナリを追加できる仕組み 所謂DLC的なやつ	まだ見れてないです
UWP on XBOX build session		実機が無いので出来ることがあまり無い…

SDKとは特に関係無いけどBuildで出た新アイテム等

Centennial msdn doc	Preview版と、そこそこ詳しいドキュメントが出た Win10 Enterprise IP 14316が必要です。Azure VM上のものでも大丈夫です。 Preview版自体は動作条件がハードル高いので実際に試している人は凄く少ないと思う 重要なのはある程度詳しいドキュメントが出たことで、下のリンクのBehind the scenes を読めばこの手のもの知っている人には何やってるのか大体わかるようにはなったと思います https://msdn.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-deploy-and-debug#behind-the-scenes 現状わからない（興味ある）のは、実際のパッケージのサイズがどれくらいになるか（VFSやFont等肥大化しそうな部分が多々ある）
Store Update build session Windows blog	Availabilityという点では今回一番優秀なのがこのStore Update かなりの機能が既に実装済みで即利用可能になっている　素晴らしい Documentationも良くできている 新しいベータテストのための仕組み TestFlight Packageは、今までできなかった「本筋のAppPackageをストア上に維持したまま、登録したテスターにテストパッケージを自動更新でDeploy」が可能になっている　凄い　即役に立ちそう BuildのSession動画を見ると判るけど、どうもMSさんは自分のSteam Storeを持ちたいみたい
HoloLens	HoloLensのフラグ立てたアプリは既に受け付け開始されている　（F10はこれで出した） ※ HoloLens emulator でAppを動かすには、AppのTarget（.csprojのPropertyページで設定するやつ）の「最小バージョン」を10.0.10240.0 に設定する必要があります。10586だとエミュレータがメニューに出てきません。
XAMLTreeView build session	MSのGitHub UWP Sample、Dev Branchに「XamlTreeView」サンプルがある　Build・実行にはRS1環境が必要　実体はVC++製のControl RS1の新Controlを使っているのでTH2では使えないです
14316 DesktopでThemeがSettingsから変更可能になった件	App側のTheme設定が「Default」だった場合、Systemの変更が即反映される・・・・はずなんだけど F10でテストすると、部分的に適用される所・されない所がありバラバラ　うまく動いていない　もちろんAppを一旦終了・再起動すればOKではある
XAMLのEdit&Continue	Buildのデモ、超便利そうでしたよね　すぐ使いたい！使わせれ！！！ でもこれ、現状使えるのは Win10 RS1 14295以降＋VisualStudio vNext "15" だけです。VS2015Update2はムリ。

おまけ

TH2 vs RS1 API差分一覧　（MSDNへのリンク付き…まだ文書無い場合は404です）
何気に便利

http://ddlgsite.azurewebsites.net/ApiPeek/win10.10586.to.win10.14291.diff.html

元ネタは
https://github.com/martinsuchan/apipeek

おまけ2

MSDN のAPI Referenceの内、"10.0.14295.0から" という文言が付いているもの検索
（変更後少し経つとIndexingが走ってこういう検索ができるようになる 04/11現在はOKです）

https://social.msdn.microsoft.com/search/en-US/windows?query=%2210.0.14295.0%22&refinement=183%2C117&ac=4