We are working on releasing the full Win32 SDK for Windows 10 ARM64. You'll be able to target that platform just as you do when you develop for x86-32 or x86-64.
In the meantime, the best way to target the platform is to develop ARM32 UWPs. These will run great on these devices.
Back to the Win32, and addressing your WinForms question, these devices currently only include the x86-32 version of Desktop CLR. This means that if your app has tight dependencies to Desktop CLR, you still need to run your app as x86.
This limitation does not apply to the use of (Core) CLR in UWPs. UWPs that use Core CLR (and that you allow publishing to ARM32) will be translated to ARM32 native code by the store and will run as ARM32 apps in the device.
@paradyne - The short answer is yes, these classic pooling applications will have their time stretched (you can call that "very very late", relatively speaking).
One the other hand, think about what happens on classic up-to-windows7 Standby (and also Windows 8 if the hardware does not support Connected Standby): When they do Standby, REALY nothing happens - everything just stops. In essence, Classical Applications on Connected Standby are no worse than they were before - maybe a little bit better.
McHalls, You seem to be describing a pervasive impact on all applications startup. ThreadPool has been tested thoroughly not to affect any such generic scenario. In fact, the loader remains mostly single-threaded to this day. There are multiple factors that could be influencing your results, such as storage drivers. Also note that Win8 does come with Defender complemented by Security Essentials anti-malware, where Win7 did not. Smart screening is also turned on by default validating the binaries being loaded are not back-listed as malware. A delicate balance with "secure by default".