Trying to figure out if it's possible to share my pass with another app produced by an independent developer team.
As per passkit documentation you have to specify team identifier for the pass which (I'm assuming) limits the scope of accessing pass when using method such as -[PKPassLibrary passesOfType:]
Additionally I found following excerpt in the documentation for [PKPassLibrary passes]:
Your app only has access to certain passes according to its entitlements. PassKit doesn’t return passes that your app can’t access.
What if I want another app to be able to access my pass programatically - is my assumption correct meaning it's not possible to share pass between two apps?
Thanks
Related
Is it possible to create pkpass in app? I have watched a few wwdc and searched online. It say it require signing and it can't be created in app. Is it correct? If not, is there a way to create in app?
The simple answer is yes, but you probably don't want to. I don't see what would stop you creating and signing a PKPass file in ObjectiveC or Swift.
The reason you wouldn't want to do this is security. When a pass is created, it's manifest is signed with a private key. This ensures that you can trust the vendor and it also provides legal safeguards. If you put were to create the private key into the pass it could be extracted and use to create similar Passes or even replace your own passes.
I have an app that is on appStore.However this app gets some of the data from server side from an xml
My app is on different apple stores. However I want to restrict some features to only specific app stores. How can I make the application to work for different app stores , lets say make the app read different xml for different app stores or something like that? Is that possible? Or maybe Any place inside app where my app can read the store Type e.g find out if its USA Store or Japanese store or Etc.
An easy way of doing this would be to have a input parameter in your API call which the application can request which country it's from, and then deliver your refined results based on that. Then, launch multiple apps in iTunes connect where each one specifies which country it is in the API request, and only allow it to be downloaded from that country.
For example, if you had two applications:
MY APP (UK) - API call: http://example.org/api/uk/request.xml
MY APP (USA) - API call: http://example.org/api/usa/request.xml
Note: The country you set in iTunes connect is the app store registered to the users account and not based on what country they are actually in!
Alternatively, you could use a online service to determine the location based on their IP. I haven't done this but a quick search finds:
http://www.makebetterthings.com/iphone/how-to-find-ip-address-of-iphone/
http://www.geobytes.com/iplocator.htm?getlocation
i think in you developer account in the app setting you can choose to which stores to upload, or do you mean like having different content for some stores?
Actually you can do it in two ways:
1- build a different binary for each country
or
2 - find an API that let's you know what is the reference store for an user
About this second option, a quick search in the Apple documentation didn't return me a specific API to do this.
Sure, basing on the Locale is not good (what if the user changes the language settings?)
The only way I found is to use SKProduct class. It has a priceLocale property that returns an NSLocale instance. So if you do:
mySKProduct.priceLocale.localeIdentifier
you'll have a NSString with the locale associated to the reference AppStore. (in my tests: it_IT#currency=EUR ).
I tried it in a project with in app purchase enabled, I think that you must setup a real SKProduct to make it work properly
Regards
Fabio
i investigate development for Apple Passbook. i've found that if you have something to perform as a pass to your subscribers, you should create special .pkpass files and distribute them variously. But is it possible to create your own passes in iOS application and add them to Passbook? For example, i have barcode, all additional info, so i want application user to configure his own pass.
It's certainly technically possible to develop your own pass creation App, however to create a .pkpass bundle entirely within an App would require you to embed your Pass ID Private Key within the App which presents a huge security risk.
In practice, your App should send the pass data to your web server which should compile the .pkpass bundle and transfer the bundle back to your App to add to Passbook.
The Apple Pass Kit Framework reference gives you everything you need to accept a pass from your web server that contains info that your user has provided to your App.
I am trying to find a way to generate a pass for passkit on the device its self after it received the information to put in a pass over the network.
Does anyone know if this can be done / how to do this?
Refer to: https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/PassKit_PG/YourFirst.html#//apple_ref/doc/uid/TP40012195-CH2-SW1
Basically: Not easily (if at all), you need to be able to sign your pass using signpass, a command line utility in order to make it readable by devices. This will cause a lot of hassle and distress, as you can't run another process on iOS, and to convert the signpass code to run on the device might not be possible either.
What I would suggest is to sign your pass on the server/wherever the data is coming from, and send both the information and the generated .pkpass to the device. This is how it was designed, and how it should be used. Read the docs for more information, they're very clear.
Actually, Apple have stated the security problems when signing passes in iOS. This is because the certificates needs to be packaged with the app. And you don't want to expose certificates to users like that.
Just like WDUK suggests, implement a simple pass signing and distribution server that your app can request passes from. This is also very helpful when you want to update passes added to devices.
I'm sure you can find a server implementation that fits your needs on GitHub.
Not exactly a programming question but here it goes:
How can a company who is distributing passbook passes via email or web prevent a pass from being installed on more than one device?
I can not find anything about this on Apple docs. The only I can think of is to check on the device registration webservice whether the combination of pass type and serial has a device already registered and delete it , but I am not aware of any command to delete the pass remotely.
Another option would be to check if it is already registered prior to generating the pass but this would only work for URL distribution, not for email.
Is there any way to delete a pass remotely via push notification + update? Any ideas on how to solve this issue?
Mail and Mobile Safari will present any pass they are given and the user can decide to add them to their Passbook. There is nothing the pass creator can do to prevent it except to be careful about how the .pkpass files get handed around.
If you really only want to deliver a specific pass to a specific device you might consider a companion app that uses a custom API to communicate with the the backend and request the pass for that device that way. Then you have much more control than distribution via email or url links.
Apple frowns on trying to delete a pass programmatically; only users are supposed to delete passes because they added them. You can, however, update a pass to make it clear that is not valid and should be deleted. For example you can remove the bar code, if any, and use a background image with a big red "INVALID" on it.
Just to extend #ohmi's answer:
You cannot prevent passes from being installed on more than one
device - e.g. if user enables iCloud for Passbook, the passes will get
synced automatically across devices.
Considering your links to pkpasses are public, you may want to consider
introducing one-time download links, but while it can fill your
needs just fine, users can be really disappointed if it's impossible to re-add
passes that they manually deleted. So I wouldn't recommend such solution.
You can make you pkpass links kind of private, so only GET request originating from your application and carrying a specific value for specific header field (e.g. auth_token), will receive a pkpass file, however this way you almost disable pass distribution via email or via sharing URLs to passes and make pass updating probably impossible.