I am creating an iPhone app that will be free with the purchase of a set of headphones. The idea at this point is that a passcode will be included with the headphones that will let the user enable the app which is a DSP app with filter settings specifically for the headphones. The passcode only needs to be entered once and then the app will be permanently enabled. I assume that I will have to use my own server to check the passcode and return an authorization to the device. Does anyone have any advice on how to implement this functionality?
You could easily/quickly implement this feature using one of the PaaS (Platform as a Service) providers out there. Parse, StackMob, Azure, etc. They provide the database in the cloud and the REST API to access it, and you simply make a read on the password table to see if the entry exists (using the provider API). These services are very inexpensive and you could use the free tier until you get meaningful volume.
However, note my previous comment, that this would not be approved as an app for violating the App Store Guidelines.
Apps that arbitrarily restrict which users may use the App, such as by
location or carrier, may be rejected
Apps that unlock or enable additional features or functionality with
mechanisms other than the App Store will be rejected
Related
I am creating non renewable subscription for one of my application.
I have read document that if I implement non renewable subscription then I have to write code to expire it from server side.
I am all done with it.
But I am little bit confuse that If I am going to purchase that item once its expired the alert says as attached in image. That means it will restore the non renewable subscription or it will purchase a new one?
Also another question I have read that on stackoverflow that If application is providing non renewable sunscription that it must has optional registration flow is it true?
About your first question, non-renewing subscriptions can not be restored or sync via the usual Apple way of providing restoring/syncing between devices. You have to provide your own mechanism.
You can check this documentation and judge yourself how you want to do it.
You can sync and restore non-consumables and auto-renewable
subscriptions across devices using StoreKit. When a user purchases an
auto-renewable or non-renewing subscription, your app is responsible
for making it available across all the user's devices, and for
enabling users to restore past purchases.
Regarding your second question:
You can check how your app relates to the following entry in the review guidelines.
"(v) Account Sign-In: If your app doesn’t include significant
account-based features, let people use it without a log-in. Apps may
not require users to enter personal information to function, except
when directly relevant to the core functionality of the app or
required by law. If your core app functionality is not related to a
specific social network (e.g. Facebook, WeChat, Weibo, Twitter, etc.),
you must provide access without a login or via another mechanism.
Pulling basic profile information, sharing to the social network, or
inviting friends to use the app are not considered core app
functionality. The app must also include a mechanism to revoke social
network credentials and disable data access between the app and social
network from within the app. An app may not store credentials or
tokens to social networks off of the device and may only use such
credentials or tokens to directly connect to the social network from
the app itself while the app is in use."
I've written an enterprise iPhone app for the field workers in our company, and the powers-that-be are considering offering it to some of our client companies as a freebie for their field workers to use. I assume that Apple would not allow enterprise distribution to users who are not company employees, so I would have to place it on the App Store.
However, we would like to restrict the user base to approved users or companies, so I would like to avoid making it available to just anyone. The app does communicate with our servers, which makes it something of a risk, in my opinion, of hacking; we'd certainly like to avoid that.
I'm wondering if there is a way to restrict App Store downloads only to certain users or companies? Or is there an alternative method to prevent just anyone from downloading and using the app?
Posting as answer, as per the OP...
For your case, you probably want to look at Business-to-Business distribution: https://developer.apple.com/programs/volume/b2b/
You could use the new "DeviceCheck APIs" that is release in iOS11
Using the DeviceCheck APIs, in combination with server-to-server APIs,
you can set and query two bits of data per device, while maintaining
user privacy. You might use this data to identify devices that have
already taken advantage of a promotional offer that you provide, or to
flag a device that you've determined to be fraudulent. The DeviceCheck
APIs also let you verify that the token you receive comes from an
authentic Apple device on which your app has been downloaded.
https://developer.apple.com/documentation/devicecheck
I have an app that involves messaging (and it's a big part of the app). People can text each other through the app, and every message is kept on our server, uncrypted. (We never really thought of encrypting it)
The user has to accept terms when he creates his account and it's all written there, but my question is the following :
Knowing the user supposedly read the terms, is it still legal/allowed by apple to keep all the messages on our servers? We can identify who wrote it and what is written, obviously, but the users can only read his own messaging feed. Is that ok? Or should we run a encrypt algorithm when uploading the message and decrypt it on the reciever side? Or any other relevant idea/solution?
The T&C your working with Apple are documented in iTunes Connect > Contract, Tax, Bank > iOS Paid Applications and iOS Free Applications
TINLA: They don't say anything about how to store the data of your customers (by my brief understanding)
When distributing your App thru App Store as you say have you own Privacy Policy provided. If not then the standard EULA applies. the standard also does not say anything about privacy / encryption.
I do know how to ask permission for contact's list accessing, is a very simple implementation, also I know Apple checks all this in case of going live to the App Store.
I'm about to receive a AdHoc bundle to a third party client, very very picky with privacy issues and I want to be certain that you cannot in any possible way in iOS7 access to the the address book, without previous and clear authorisation, nor storing some file in local or sending it through a web-service.
If there's other sensitive information than a programmer can access without the operating system firewall please let me know as well.
I read some subroutines can go through...
QUESTION: Can a developer access to the addressbook or personal information, directly or indirectly using a third party API or subroutine to the personal data, without explicit permission? Is an AdHoc bundle as secure as an AppStore reviewed App in that case?
Please do not punish me with negative feedback if you are not interested in privacy issues or think was that obvious, actually Apple's documentation is not clear and is focused on AppStore, mostly.
Thanks!
This answer came up in every search I did trying to find, CNContactPickerViewController, so I figured I should respond for posterity.
In iOS 9 and later you can call CNContactPickerViewController to present a system controlled contact picker that doesn't require permission to access the user's contacts. You can't hoover up all their contacts, which is what the original question implied (and is super creepy), but at least you can prompt the user to select a contact (or multiple contacts), which is sufficient for many legitimate use-cases.
Docs
The Address Book cannot be accessed without permission. No third-party API can get in, because internally, these API's need to go through the same permission checks as you need to. No app can get into a user's address book without the user's permission.
This is because of a security issue that Path, and some other apps, uploaded its users' address books to their own servers to use for whatever reason. To read more about it, look here
After this surfaced, Apple required the user's permission to access the user's contacts. Apple's iOS platform is possibly the most secure operating systems today, and there are few security holes that exist in their API's (minus the goto fail; mess-up).
App Store reviewed apps are more secure for the user than Ad-Hoc apps. The developers at Apple make sure that you do not do anything malicious with the user's contacts. In Ad-Hoc apps, there is no checkup. So, if you wanted to do anything dirty with their contacts in an Ad-Hoc app, you technically could (if the user gives you permission at all). You do not need to state what you will be doing with the permission, and so you are able to take advantage of the user's trust in you.
If you want the company to trust the app, suggest that they look it over with their own reviewers. If they don't think you are doing anything fishy, you are good.
Currently we are capturing the crash exceptions and logging it to a local file. On launch of the app we will send those log files back to our own server.
My question: Is it allowed by apple to retrieve user's crashing logs without notifying the user? Do we have to display a dialog to let the user choose whether to send it or not?
Thanks
The standard EULA that is applied when you add your App to the store contains the following clause:
b. Consent to Use of Data: You agree that Application Provider may collect and use technical data and related information, including but not limited to technical information about Your device, system and application software, and peripherals, that is gathered periodically to facilitate the provision of software updates, product support and other services to You (if any) related to the Licensed Application. Application Provider may use this information, as long as it is in a form that does not personally identify You, to improve its products or to provide services or technologies to You.
You need to consider whether the crash information may contain personally identifying information, in which case you may need to supply an alternate EULA or seek permission within the application