2016年8月21日日曜日

MSDN Doc 上の Fonts for UWP Apps の説明が少し変わった

タイトルが全てなのですが…
今迄は、

Guidelines for fonts
https://msdn.microsoft.com/en-us/library/windows/apps/hh700394.aspx

こちらに
  • UWP Appでの各国語フォントの扱い、既定のフォント
  • XAML Style一覧
  • それに伴うFont Ramp (サイズ一覧)
等がまとまっていたのですが、2016年8月下旬に見てみると以下三つに分割されたようです。


Fonts for UWP Apps
https://msdn.microsoft.com/windows/uwp/style/fonts

Typography
https://msdn.microsoft.com/en-us/windows/uwp/style/typography

XAML theme resources
https://msdn.microsoft.com/windows/uwp/controls-and-patterns/xaml-theme-resources

言ってる事は大体同じ、3Pに分かれてより詳しい記述になっています。

UWP App書く人への注意点としては… XAMLの中でFontsizeを直指定、はあんまり上品では無く、
  • なるべく既定のStyleを使う…XAML theme resources にStyle一覧が出ています。
  • アプリ中の地の文(本文)のサイズはBody/Baseに合わせておくのが一番いいです。自分の好みでみつしり字を詰めても良いこと無いです(Webページで変に文字小さく指定してる微妙な奴、あれです)。ここから外したい人はフォントサイズ変更の仕組みを作るのがお勧めです。


◇◇◇


(余談)
一点気になるのは…以前のGuidelines for fonts では囲み記事になっていた注意点

「この一覧以外のフォントをアプリで使用する場合、フォントの自動ダウンロードが発生する場合がある。これはデータプラン等で通信量に制限のあるモバイルデバイスでは特に問題となる可能性がある。モバイルデバイスで動作するUWP アプリはこのリスト以外のフォントを使用すべきでは無い。

この記述が新しいドキュメントでは消えているようです。どういうことなんでしょうね?
言われなくてもそりゃそうだろう、とは思うのですが、Win10M でフォントの自動ダウンロードの実例を見た事は無かったな…というのもあり、若干もにょっとした感じが残ります。


…Desktop のWindows OS 的には、この手の話はざっくり言うと以下の通りで、

  • Windows XPまで…欧州系フォントは全言語OSにInstall、東アジアグループ(日本語・中国語・ハングルなど)はその言語のOSにInstallされ、東アジア以外のOSで東アジア言語を使いたい人は東アジアフォントパックをインストール このため、英語・その他欧州言語バージョンのXPでは日本語・中国語などは全部豆腐か文字化けで全く見えないことが多かったです。
  • Vista以降…全言語Versionで全言語フォントが既定でインストール ここ以降、どの言語OSでも文字化け無く表示できるようになりました。また、アプリのUnicode Build化、WebPageのUTF-8化が進んでいったという背景もあります。
※PreloadやEmbedded系で入っているフォントを調整する例はあったと思います

ただMobile…Windows Phone系はどうだったんだろう?僕は良く知らないです。ただWP8.1系でも既に、XP的なフォント入ってない系の話はあんまり無かったような気がします。














2016年8月2日火曜日

Windows 10 Mobile と 緊急地震速報・防災情報

Windows Phone 8.1 とWindows 10 Mobile(以降Win10M) は、OSの機能として緊急地震速報に対応しているが、既定の設定はOFF…ONにしたい場合は電話メーカーが各自行う必要がある、事が知られています。

ただ、実際に緊急地震速報が発報される事は少ないため、どういう動作になるか知見はそれほど溜まってはいなかったように思います。

今年に入り、緊急地震速報・防災情報それぞれ受信・受信失敗する機会がありましたので、この機会に…

  • Win10M で緊急地震速報を受信できた機種まとめ
  • 受信するとどんな画面が出るのか
  • 自治体の防災情報を受信できるのか
  • 実際に訓練で確認してみよう
という内容で記事を書いてみました。


緊急地震速報


2016年5月16日夜、関東地方で地震がありました。
http://www.data.jma.go.jp/svd/eqdb/data/shindo/Event.php?ID=9902422

2016年5月16日の地震

この地震では緊急地震速報が発報されました。

人口の多い首都圏、また多くの人が活動している夜9時過ぎという事もあり、Win10M 機で速報を受信した・しなかった旨のTweetが多く見られました。
Tweetを検索し、日本国内で販売されているWin10M各機種ごとに調べてみたのが以下の結果です。

  • 緊急地震速報を受信した… MCJ Madosma Q501, VAIO Phone Biz
  • 緊急地震速報を受信しなかった… NuAns NEO, FREETEL KATANA01, FREETEL KATANA02, Yamada Everyphone
  • 未確認… Geanee WPJ40-10, Diginnos Mobile DG-W10M

(未確認…地震直後にETWS受信した・しなかった等のツイートを確認できなかった)

前述のようにWin10MはOSとしてはサポート、ただし既定はOFFです。Madosma Q501とVAIO Phone Biz は設定でONにされており、その他の機種は既定のままOFF、であったものと思われます。

受信時の様子


私は当時川崎の自宅におり、電話(MADOSMA)はACに繋いだロック状態、画面は消灯、マナーモードには入れておらず着信音量は5/10程度だったと記憶しています。
地震が始まり、あれ少し大きいなと感じた頃にMADOSMAの画面が点灯し、バイブレーションが始まりました(正確な前後関係は自信が無いです)。


受信時のスクリーンショット


  • 画面表示 ポップアップ上に地震アイコンとエリアメール文面
  • バイブレーション 強いバイブレーションが長く続く
  • 音 「プーーーーープーーーー」という断続的な長いブザー音(家電話の受話器を上げた時のような音)が続く 音量は通知音量程度

音については、「マナーモードにしていると鳴らなかった」というツイートを複数確認できました。設定した着信音量そのままで鳴っていたものと思われます。

モードに関わらず全力全開でぎょわっぎょわっと鳴動する、いわゆるガラケーの緊急地震速報とはかなり様子が異なります。


防災情報



2016年8月2日、関東地方で局所的な豪雨・雷が発生しました。私の住んでいる川崎でも深夜に物凄い音の雷が何度も落ち、大雨が降りました。

午前9時頃、私は川崎市内の電車(東急田園都市線)に乗っていたのですが、突然回りの乗客の携帯電話が鳴動を始めました。緊急地震速報とは別のメロディ音でした。
この時、私が持っているMADOSMA は速報の類を受信した様子はありませんでした。

後で確認すると、自治体(川崎市)が発信する防災情報のエリアメールでした。



この豪雨は局所的だったこともあり、Twitter等で他のWin10M 機種の動作を確認することは出来ませんでした。


国が出す緊急地震速報と 地方自治体が出す防災情報


詳しくはIIJさんの資料をご確認頂きたいのですが、

IIJmioのSIMで緊急地震速報は受信できる?

IIJmio meeting 12 災害とMVNO (ETWS動作検証)


ざっくりまとめると…

  • Win10M で多く使われる 所謂MVNO SIM 自体は、緊急地震速報・防災情報を受信する能力がある
  • ただ、実際に表示できるかどうかは電話の実装による
  • 「緊急地震速報・防災情報」と呼んでいるのは、気象庁管理の地震・津波速報と、地方自治体管理の災害・避難(水害等)の二種類がある
  • iPhone 系は両方受信可能 SIMフリーアンドロイドは前者受信可能・後者受信不可能、な場合が多い

そして、今年に入ってからの上二つの経験からすると、Win10M の実装は「SIMフリーアンドロイド」と同じ系統であるように思われます。

つまり、
  • 緊急地震速報…電話メーカーがONにしていれば受信可能
  • 自治体エリアメール…受信不可?

ではないか?と思われます(自治体エリアメールについては受信不可のサンプル数が少ないため断言しづらい所があります…)。


お手持ちのWindows 10 Mobile が対応しているかどうか確認するには


メーカーに聞いてみる

電話メーカーさんは知っている(はず)ですので、聞いてみるのが結局は一番早いかもしれません。
Win10Mの場合、On/Offどちらに設定されているかをシステムから読み取る手段は…私は知らないです。私の理解では、普通のユーザーアプリレベルからは触れないと思います。


訓練で確認する


全国の自治体で防災訓練が行われています。この時にエリアメールの受信確認が可能かもしれません。

ただし、「緊急地震速報の訓練」とあっても、確認してみると自治体の防災無線でサイレンを鳴らすのみ、という場合が多く、実際に携帯にエリアメールを発信する訓練は少ないようです。
例えば、気象庁では年1回、11月5日「津波防災の日」に緊急地震速報の訓練を行うのですが、この訓練ではエリアメール発信は行われません。

※エリアメール発報訓練はその仕組み的に、電源OFF以外に「訓練をパス」する手段が無く、確実に携帯が鳴動しますので(そういう作りだから仕方ない)、それはそれで社会への負担も少し大きいかな、という所があります。

また、上でも触れましたが、これらの訓練では自治体のシステムでエリアメールを発報するため、気象庁管理の「緊急地震速報」とは結果が異なるものと思われます。


2016年 エリアメール発信を伴う訓練

※Web検索で目についたものをピックアップしました。

入間市防災訓練(埼玉県)2016年8月21日(日曜日)http://www.city.iruma.saitama.jp/bousai/bousai_list/bousaikunren.html
記述から見るに、おそらく自治体発信のエリアメールと思われます。
当日の午前9時15分、入間市内にいれば受信できるはずです。

静岡県 12月頃?
去年の訓練情報のままで、今年の日にちが判らないです(自治体のHPはこの手のが多いです…)

大阪880万人訓練(大阪府)2016年9月5日(月曜日)http://www.pref.osaka.lg.jp/shobobosai/trainig_top/
規模は圧倒的ですね… メール発信は午前11時となっています。

17万人市民まるごと防災訓練(愛知県西尾市) 11月頃?
去年の訓練情報のままで、今年の日にちが判らないです





2016年7月30日土曜日

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}








2016年6月19日日曜日

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/


2016年5月15日日曜日

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との協調動作を企図した使用等、かなり限定的なのではと思われます。



2016年5月5日木曜日

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…社内配布向けになると全然別の話になりそうです。しかし長くなってしまったので…このあたりにしておきます。