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.
Related
I want to implement deferred deep linking in my iOS app as a means of tracking referrals. When a user of my app wants to refer a friend, I'll generate a URL that has a unique referral code. When the other person receives the link and opens it, I want it to take them to my app's page in the App Store. Then if they install my app, when it first opens, I need a way for it to read the referral code from the original URL.
I've found may pages about deferred deep linking on the web but none that really explain how to do it. Instead, these pages all end up telling you to install some third-party code or use some commercial service. This isn't what I'm after. I want to learn how to do this myself.
There are lots of old pages out there that recommend convoluted and error-prone solutions, like tracking the user's IP address, putting the referral code into the clipboard, or somehow obtaining it from a cookie in a web view. I don't think these are the correct solutions to be using in 2022.
If anyone can recommend the appropriate resource, I'd appreciate it.
If it is the case that Apple simply doesn't want us to do this and doesn't provide any support for it, then I'd like to know that too. I was under the impression that they did, but maybe I'm wrong.
Thanks,
Frank
Apple's Universal Links allow for this (would understand the difference between the typical URL Scheme and Universal Links as threshold). This assumes you're willing to do some lifting server-side along with other hurdles on the iOS side, largely administrative.
A benefit of Universal Links and the server-side work is that you're provided a fallback webpage if a user does not have the app installed. Since the app should open if downloaded, you could typically just redirect to the app store from this URL. In this case, though, before any redirects, you could execute an operation to decode the unique params passed in the URL and persist it in a remote data store. The data encoded needs to be required and verifiably unique during your registration -- email seems ideal.
If that's feasible, your standard registration flow could require email verification with a link to the app as a mandatory entry point (think slack magic link). When the user submits his/her email to verify, you could first check that email against your data store to see if it maps to any previously decoded referrals saved from the flow above. If so, you could generate a unique link for this email to your app with params that will direct the deferred/deep link.
The good news is, I found a solution. I could construct a web page that redirects the user to the app store, but before doing so, copies some text into their clipboard (without telling them or asking them to do anything). Then later if they install my app I can get the text by pasting from the clipboard. I tested this idea and it works.
The bad news is, starting with iOS 16, Apple now asks you for permission to paste. So if you try to do this, your user will launch your app and immediately get promoted with a message asking them to allow a paste from Safari. I expect most users will deny the request and just the fact that they saw it will erode their trust in the app (I know I wouldn't trust an app that tried consume my clipboard without a direct command from me).
I'm writing an application which will be used in an enterprise, no outsiders.
This application should fetch data from API response and display it.
Each user has his own device, Ipad and should see only the data he is the owner of.
Problem i'm facing is identifying the device/user, so that API responds with only the information the user is supposed to see.
brief example of how it should work:
App is opened -> get unique id -> attach ID to API call -> receive appropiate response -> display data
As i imagine this ID should be static and not made upon installation of the app or generated.
I've tried getting UDID, Serial, MAC,- no luck, they're deprecated. Only managed to get .IdentifierForVendor, which is unique not in the way that i need.
So here is my question, are there any other options left?
Like fetching appleID name,email or should i make unique deployments for everyone separately?
Or a Log-in screen?
You could create a GUID for every App instance. However, apart from that you will have a hard time doing what you want.
These ways of identifying a device have been deprecated to ensure Advertisers and other malicious Apps cannot fingerprint a device easily.
If you don't want too much hassle authenticating everyone, you could apply a simpler scheme such as using a pin code, QR code, NFC tag or whatever you prefer.
However, if someone were to steal one of these enterprise devices and it would contain any secret information I would rather rely on something more secure as username and password, or even better something multi-factor.
Unique id's will have to be set by deploying the app from MDM. For example:
https://docs.jamf.com/9.9/casper-suite/administrator-guide/In-House_Apps.html
How should the application accept those variables, i dont know. Maybe it modifies .plist when deploying.
Solution i did was enforcing device name from MDM, so that users are unable to change it - and using that as the unique identifier.
I have an app where I get a list of product IDs from the server, which I then send to Apple to get a list of SKProducts, which I then send back to the server to get html, which I put all together to make a webview with the products.
This is very complicated- is there a way for the server to communicate with Apple directly without having to do all the back and forth?
No. Your app has to make a request to the iTunes store directly from the device it is running on (to ensure correct handling of the user's iTunes account, including appropriate prices for the region, etc.).
It sounds like your app-server communication structure is not the most efficient; it'd be easier if you generated the storefront web view inside your app, locally on the device (or even found a better, native way of displaying the information, such as a UITableView or UICollectionView), instead of sending the IDs to the server. This would eliminate a lot of the back-and-forth resulting from you doing this in a way that was certainly not intended.
I'm developing an app that creates a simple document with basic information created by the app. It won't contain any personal information, but it will contain data created and requested by the user. I want the user to be able to send this to themselves via email. I would also like to add the option for the user to have this file (which updates daily) to be able to send to them automatically every week/month, so they won't have to think about it. The user can set the intervals themselves.
Is this possible? The user will set up this option themselves from a menu, so it's not like they won't know it's happening. Every automatic mail will also contain information on how to turn the option back off again.
Is this possible and is it allowed by Apple?
Thanks for your reply
It is not possible from within the app. A user has to explicitly send the email through the MFMailComposeViewController.
If you want this functionality, you should build a backend for your app.
To clarify, if you want to use the users configured accounts; i.e. the account they use with Mail, then no you cannot do this automatically. The other answers rely on the fact a user enters their POP/IMAP settings, which personally I would never do.
You could use an email service as mandril or mailgun, to send emails "from your app".
Take a look at this: https://github.com/rackerlabs/objc-mailgun
There's a library called MailCore that's incredibly powerful. You can use it to send mail in the background of your app without needing to present the built in mail composer view
https://github.com/MailCore/mailcore2
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.