Overview:
I have an IOS app that allows a user to create an order from menu items and then check out that order using a credit card.
I am aware that you cannot store a users credit card information and that this can only be stored with a registered authority i.e.: the credit card gateway (somewhere that is PCI compliant).
The Question:
I need to store a users first name, last name, mobile number and email address, so these fields can be autofilled on a future order. Just to be clear the name and number are not in any way associated with the credit card or payment method, that is a separate field and is handled differently. This is just user information for the actual order that is handled through our servers.
Could I store these pieces of information in NSUserDefaults so when the user goes to checkout in the future these fields are autofilled?
You can definitely store the information in NSUserDefaults but as others have pointing out a database like SQLITE will be a better option. In the future your app might grow and might want history of items user has purchased or shown interest in. At that point you don't want to store collections in NSUserDefaults.
One more option for you is using Core data
Related
I am building a native social app in Android and iOS
I am using contacts from users phonebook to determine if his target friends are on our app or not and send the events accordingly
I recently came across this news that Apple is banning apps to send contacts to the server, which is the backbone of my app in order to function
How should I approach this problem? How do apps like WhatsApp which sync contacts (whole phonebook) to their server manage through this?
Do I need apple review of the app to access phonebook permission?
From This article I quote
But the phone maker didn’t publicly mention updated App Store Review
Guidelines that now bar developers from making databases of address
book information they gather from iPhone users. Sharing and selling
that database with third parties is also now forbidden. And an app
can’t get a user’s contact list, say it’s being used for one thing,
and then use it for something else -- unless the developer gets
consent again. Anyone caught breaking the rules may be banned.
Since the question is quite general let's dive into it a bit.
Looking into the App Store Review Guidelines there are three places mentioning that users' contacts should not be collected.
First and second, users should not be forced to provide their address book in exchange for app functionality (paying with contacts; highlights were added, a similar phrase is used for app subscriptions):
Apps should allow a user to get what they’ve paid for without performing additional tasks, such as posting on social media, uploading contacts, […]
Third, uploading and/or storing contacts to/on a server has an impact on users' privacy and is prohibited for the following use-cases:
Do not use information from Contacts, Photos, or other APIs that access user data to build a contact database for your own use or for sale/distribution to third parties, and don’t collect information about which other apps are installed on a user’s device for the purposes of analytics or advertising/marketing.
This does not exclude using contacts for creating a social graph for the benefit of your users. However, collecting all contacts might violate the principle of data minimization. So Instead of just uploading all contacts, Apple recommends to use a contact picker (see ContactsUI), where the app only gets access to the contacts the user selected:
Data Minimization: Apps should only request access to data relevant to the core functionality of the app and should only collect and use data that is required to accomplish the relevant task. Where possible, use the out-of-process picker or a share sheet rather than requesting full access to protected resources like Photos or Contacts.
The Art. 32 of the GDPR requires you to take the
[…] the state of the art, the costs of implementation and the nature, scope, context and purposes of processing […]
into account.
I think that the process has to be made transparent (as in comprehensibly explained to the user):
The user should have control over which contacts are used for discovery. All would be a valid choice – selected contacts (through the contact picker) or manually entering contact information (phone number, email – whatever is used for your contact discovery process) would be valid choices as well.
The app should function even if the user denies access to the contacts. In that case you can still offer a contact picker, or manual entering.
You must describe the process, including what information is used and for what purpose, in your privacy policy.
You should at least hash the processed values, as you do not need the actual phone numbers or email addresses for contact discovery and hashing comes without much effort and cost. However, be aware that hashing of personally identifiable information is not sufficient for "anonymising" these values – which is a common misconception.
For more advanced protection, you can take a look at the blog post by the authors of the Signal app, where they describe technical details on how they protect their contact discovery process.
I am working on Integrating Apple Pay in my app. I need following details to post to api :
1. Name on the card,
2. last 4 four digits,
3. type of card (VISA, AMEX etc)
Is there a way to retrieve those from the card selected by user in Apple Pay tray ?
You cannot get the name on the card via ApplePay. This is one of the reasons why a lot of merchants have resisted it. But Apple did this to protect users' privacy: you should be able to buy something without telling someone your name. If someone doesn't know your name then how can they identity fraud you?
If you want the customer's name, ask them, or have employees check their ID and require that the name be entered into the system. If you can't be asked to bother asking the customer to identify themselves, then, since the customer has not voluntarily given you their name, why do you deserve to have it?
I need to implement "Save card" and "Delete card" features in my iOS app.
From Stripe documentations I found that we can create a customerId on our backend and link it to our internal userId.
But we need part of card details to display it to user. E.g.
Visa card xxxx xxxx xxxx 8153
Is it ok to store this data on backend and iOS app? I'm talking about card type and last 4 digits.
Should we create new customerId in Stripe if we want to store more than one card per customer?
Thanks.
There are certain details that are available when you store a card; you don't need to store them separately. "Last 4" and type are some of the fields available from the API; check out the Stripe docs for cards for more. https://stripe.com/docs/api#cards
No, you don't need to create a new customer (and in fact, would probably be a bad thing for keeping everything cleanly coordinated). Store additional cards on the same customer.
I have an app where users create accounts by username and password. However, I also want users to be able to add friends via their mobile #. Is there a security reason as to why I would need to verify their number if my design goes as follows:
User A enters her # into app, which saves to database
User B gives app access to his contacts. User A is a contact in User B's address book. When the database is queried for all #'s in User B's contacts book, we find User A's # and User A is returned.
How could there be a security flaw if User A entered a false #?
That would definitely cause security issues. Of course, for an app like this, you would need some way to verify the data that you are receiving. What if one if the contacts phone numbers are wrong? Some phone numbers change all the time now and it would be difficult keeping up to date with them all.
But on a bigger note than that, I don't think this one would fly with Apple. I've never designed an app that needed to access more than one contact at a time and the user was fully aware of which contact he/she was importing to a database. But for an app to automatically upload multiple contacts from a users address book for intent to be stored on a remote database might cause security flags to be raised at Apple during the review process. So the app may never see light of day on the Apple Store.
If you really want to implement something similar, make sure users verify their phone number before use and instead of storing the users contacts on a server, just store the verified phone number. Then you can use the contacts in your phone to check mobile numbers that have been verified of other users and which ones have an account linked to them.
I'm trying to learn about iCloud. I've read that there's
ubiquityIdentityToken and it's used to determine if iCloud is available or if the user changed the account signed in. Also, this is only available in ios 6+
But what i need to know is the unique data for every iCloud user. What i'm saying is, after the user logs into iCloud, is there a way for us developers to know who that persons is/who the account belongs to like a username or id (similar to Facebook's fbid/identiferForVendor)? Could we even get the iCloud account of the user in code?
The reason why I want to know this is because i want to check if it's possible to use the user's iCloud account(or whatever unique data we could get from them) as the user's unique identifier on our server.
I hope I could get some answers. Thank you so much!
You can use CKContainer.fetchUserRecordID(completionHandler:)
Returns the user record ID associated with the current user.
https://developer.apple.com/documentation/cloudkit/ckcontainer/1399191-fetchuserrecordid
This article shows example of practical usage of record ID retrieved in this way: Onboarding without Signup Screens.
Apple don't want you to do this. That is why they give you a unique token that is opaque. You can't use it as an id on your server. Apple do not allow iTunes accounts to be used in that way at this point in time.
I suggest you use your own account names, or you use accounts from Facebook or Twitter, which are accessible via system APIs on iOS.