8

Apparently Mountain Lion 10.8.2 Safari "supports" Passbook passes, in that it will preview and offer to sync ".pkpass" files to iCloud for the user's configured iPhone to load into Passbook.

However, I haven't found any documentation on how to get the browser to load such a file, other than the user explicitly downloading such a file.

Ideally, there would be a <link rel="alternate" type="application/vnd.apple.pkpass"> or similar tag so a supporting (and suitably configured) browser could pick it up and offer it. I can't find any mention of such a feature.

Other than that, the user would need to be directed to "click here" to download a pkpass and hope to heck they knew what it was and what to do with it. Otherwise, it's an opaque blob in their Download folder.

Obviously I don't want to be explicitly sniffing the User-agent for iOS 6 or OS X 10.8.2 and above, as this would not also check if the user had iCloud configured, and also precludes support for PassWallet and similar apps for Android and the like, along with other supporting browsers.

gid
  • 317
  • 1
  • 5
  • 11

2 Answers2

2

The obvious solution is to include an Accept header for the vnd.apple.pkpass content type. This is precisely the intention of this header.

That's not in the hands of an individual developer unfortunately.

Microsoft do this for the .Net Framework where they send the information as part of the User-Agent. This lets you detect if the .Net Framework is installed on the visitor's machine.

OS X Lion should include this header in all browser requests issued and iOS devices should send it too.

At present, the best option you would have is the one you've outlined. If the UserAgent is for iOS or OS X Lion you can infer support. It's not ideal, but the best you can do at present.

Tomas McGuinness
  • 7,651
  • 3
  • 28
  • 40
  • I like this Tom and have filed an enhancement radar. Would be grateful if you could also file one as well @gid as any others reading this. – PassKit Jan 14 '13 at 11:30
  • It's the only choice really. I'm quite surprised that Apple didn't include that MIME type in their headers. Maybe iOS 6.1 or 6.2 might include this. I'll raise an enhancement radar. – Tomas McGuinness Jan 14 '13 at 11:38
  • 6.1 beta 4 and Safari 6.0.2 (8536.26.17) so far no dice ;-( both accept `text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8` – PassKit Jan 14 '13 at 11:49
  • I think the User agent inference would be okay for OS X Lion and iPhone, but would fall down with Android. – Tomas McGuinness Jan 14 '13 at 11:51
  • Unfortunately User Agent falls down on OSX because there is still a very high proportion who don't have iCloud configured. – PassKit Jan 14 '13 at 11:52
  • Yes, but then it disappears unprocessed and the user is left bemused (or outraged, because they don't want iCloud). It would be better to not offer the pass at all if there is no way to get it on to the user's device. – PassKit Jan 14 '13 at 12:22
  • I'm not sure the Accept header is the best solution: if typical browsers sent comprehensive Accept headers for all the different possible things they'd accept, every single hit would be bloated, especially relevant when mobile data limits are considered. Wouldn't you say it'd be better for the content provider to _offer_ an alternative and allow the user agent to use it if understood and configured, in the same way is used for RSS, ATOM, and so forth? – gid Jan 14 '13 at 14:35
-1

Your server needs to send a "Content-type: application/vnd.apple.pkpass" header with the pkpass file.

Jacek Lampart
  • 1,741
  • 13
  • 25
  • This question is not about how to serve a pass - it relates to how to predetermine if the user's browser is capable of processing a pass BEFORE serving the .pkpass bundle. – PassKit Jan 12 '13 at 04:23
  • Just out of curiosity: how do you determine whether to serve a pass or an image (as stated here: http://news.passkit.com/tag/passbook-for-android/). Couldn't the same information be used for this? – Jacek Lampart Jan 14 '13 at 16:10
  • We currently do this using browser sniffing, not ideal, but it works reasonably well. The trouble is on Apple browsers, that unless iCloud is configured, Safari will ditch the pass after displaying a preview. It would be nice to know beforehand, not to send a pass to any browser that cannot add a pass to a user's passbook. – PassKit Jan 15 '13 at 04:18