Something to note if your WinRT app uses raw notifications. They will be received by the device but not by the app if it is suspended. This makes sense but may not be obvious sometimes because swiping the left side of the screen may still show the app on the stack. So it will appear to still be active, even if not in the foreground. The exception, of course, is if your app is registered to use a background service and the user has decided your app is important enough to be one of the “Lucky Seven” (those apps given permission to use the Lock Screen). I wouldn’t count on it.
It took me a bit to spot this behavior. I was noticing an instance of the app on one machine would sometimes receive raw notifications if it wasn’t in the foreground, sometimes not. The “not” occurred after a decent time lapse, which was the first clue. My server notification logs were no help because only client devices that were off or logged out of would return a status other than OK from the notification service. As mentioned, if the device is on and logged into, the notification service will successfully send the message. This makes sense. All it cares about is reaching the client at the specified URI. It’s up to the client to do what it wants with the received message. In this case, it appears the WinRT designers elected not to wake up an inactive app. Not a problem, but something to be aware of.
In my case, raw notifications are used to tell the app to update its data. It just means that the same sort of behavior also has to be triggered by resuming from a suspended state. BTW, for those who don’t know, you can suspend an app from within Visual Studio while debugging. To enable this, select TOOLS > Customize from the Visual Studio menu. Check the box next to “Debug Location”. If you have a solution with multiple projects you may have to select the right WinRT project from the Process pull-down menu.