Users are getting Delay of approx 2 minutes, after they try to launch the XenDesktop.
From the Packet Captures collected on the Client Machine, we can verify once the Client sends the Client Hello followed by NSG Sending Server Hello along with the Server Certificate, Receiver for MAC 12 tries to perform CRL Revocation Check , which is not successful due to no connectivity with CRL Providers over Internet.
CRL Check has a timeout of 60 seconds for each URL , so if you've 2 URL's configured to perform CRL Check, that contributes to delay of 2*60 seconds = 120 seconds.
And Finally Client/Receiver resumes the SSL connection by Sending Change Cipher Spec.
Receiver Logs from MAC Machine
If we can see here MAC Client tries to contact 1st CRL URL @ 11:27:33 and times out right after 60 seconds.
And then tries second CRL URL and time’s out after another 60 seconds @ 11:29:34 before proceeding with this connection i.e. almost 2 min and 1 seconds
05-23-2016 11:27:24.945 1716 1 sslprefs.m 173 GetRevocationPolicy TC_TD TT_API1 Config TLS revocation policy pref: FullAccessCheck << Shows us the current setting for CRL Revocation Check>>
05-23-2016 11:27:33.057 1716 2 sslasock.c 614 crlDownloadCb TC_TD TT_API1 Downloading CRL from http://ss.symcb.com/ss.crl
05-23-2016 11:27:33.057 1716 2 sslasock.c 647 crlDownloadCb TC_TD TT_API1 Running nested run loop
05-23-2016 11:27:56.603 1716 1 mac_NCS_appleEvents.m 628 HandleAppleEventsCommon TC_RECONNECT TT_API1 'odoc' event: items in list: 0, err: 0
05-23-2016 11:27:56.603 1716 1 mac_NCS_appleEvents.m 719 HandleAppleEventsCommon TC_RECONNECT TT_API1 'odoc' DONE: 0
05-23-2016 11:27:56.604 1716 1 ICAViewerAppDelegate.m 629 -[ICAViewerAppDelegate disableAppNap] LOG_CLASS TT_CONFIG Disabling App Nap
05-23-2016 11:28:33.075 1716 2 sslasock.c 660 crlDownloadCb TC_TD TT_ERROR Timeout waiting for CRL download to complete.
05-23-2016 11:28:33.075 1716 2 sslasock.c 664 crlDownloadCb TC_TD TT_API1 Nested run loop ended
05-23-2016 11:28:33.075 1716 2 sslasock.c 703 crlDownloadCb TC_TD TT_ERROR response is NULL!
05-23-2016 11:28:34.103 1716 2 sslasock.c 614 crlDownloadCb TC_TD TT_API1 Downloading CRL from http://s1.symcb.com/pca3-
g5.crl
05-23-2016 11:28:34.103 1716 2 sslasock.c 647 crlDownloadCb TC_TD TT_API1 Running nested run loop
05-23-2016 11:29:32.542 1716 1 mac_palkeyboard.m 2491 PALKbdHandleMacModifiers TC_KEY TT_API1 mac_palkeyboard.c:PALKbdHandleMacModifiers carbonModifiers=0x100
05-23-2016 11:29:32.710 1716 1 mac_palkeyboard.m 2491 PALKbdHandleMacModifiers TC_KEY TT_API1 mac_palkeyboard.c:PALKbdHandleMacModifiers carbonModifiers=0x0
05-23-2016 11:29:34.118 1716 2 sslasock.c 660 crlDownloadCb TC_TD TT_ERROR Timeout waiting for CRL download to complete.
05-23-2016 11:29:34.118 1716 2 sslasock.c 664 crlDownloadCb TC_TD TT_API1 Nested run loop ended
05-23-2016 11:29:34.118 1716 2 sslasock.c 703 crlDownloadCb TC_TD TT_ERROR response is NULL!
The reason why these CRL download's fail or Timeout, is because the Clients in this case are behind a Network Proxy, and Receiver doesn't honors the client proxy settings to go out to internet and fetch these file's even though it should go out through Proxy.

CRL Feature was introduced in 12.0 http://docs.citrix.com/en-us/receiver/mac/12/mac-secure-wrapper.html.
As a solution to this, we can switch over the settings of this feature to following with the following command
defaults write com.citrix.receiver.nomas SSLCertificateRevocationCheckPolicy NoCheck
NoCheck
CheckWithNoNetworkAccess
FullAccessCheck
FullAccessCheckAndCRLRequired
FullAccessCheckAndCRLRequiredAll
Please read more about them in the doc above.
But if, customer wants to use this feature as a Security Setting ,we need to make sure Receiver goes through the Proxy settings to get these file's.
To fix this issue, please open a case with Citrix Receiver Team and we can provide a workaround (private build) for this issue which has to be installed on the MAC running Receiver for 12 which will force the Receiver to send packets through Network Proxy.
Official Fix will be included in the next release for Receiver for MAC 12.

This is due a known issue with Receiver for MAC 12.
As it doesn't send traffic for CRL Revocation Check to Internet through proxy and fails.
Citrix Receiver Team is working on the official fix as of now, but can provide a workaround to fix this issue for the time being.