Apple Submission Rules and Regulations (SIM CARD DATA ACCESS) [closed]

Question

Closed. This question is off-topic. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 9 years ago.

Improve this question

I have done a lot of researches regarding accessing device SIM card data such as SIM serial number and user phone number, and below are my findings :

• By using private API for iOS SDK we can extract the needed information from SIM card (If already stored on the SIM card).
• The issue related to the rules and regulation for submission apps. On Apple store, since Apple rejects any application accessing SIM card because hey supposed that such behaviors break the user privacy and security.
• This functionality used for application not attended for APPStore submission.

References :

• How could I read information from SIM card in iPhone?

• Programatically get own Phone Number in iPhone OS 4.0

• How can I get the phone number of my iPhone device?

• Read/write certificates on a SIM card - iOS

all the posts and tutorials that i found said that i can't extract data from the device SIM card without facing apple rejection !!!

My question is ,, is there any way to access SIM card information and publish my application successfully on the Appstore ? and i appreciated any reference to the part in apple submission rules and regulations document that says "NO SIM CARD DATA ACCESS" !!

Answer 1

My question is ,, is there any way to access SIM card information and publish my application successfully on the Appstore ? - No there's no way. There's no direct reference of "No Sim Card Data" in documentation.

As you have already read SIM card data access is not possible using the Apple SDK. Following is the part of Apple Developer Document :

The following guidelines can help you ask for user data in ways that help people feel comfortable.

Make sure users understand why they’re being asked to share their personal data. It’s natural for people to be suspicious of a request for their personal information if they don’t see an obvious need for it. To avoid making users uncomfortable, make sure the alert appears only when they attempt to use a feature that clearly needs to know their information. For example, people can use Maps when Location Services is off, but they see an alert when they access the feature that finds and tracks their current location.

Describe why your app needs the information, if it’s not obvious. You can provide text that appears in the alert, below a system-provided title such as ““App Name” Would Like to Access Your Contacts”. You want this text to be specific and polite so that people understand why you’re asking for access to their information and don’t feel pressured. Your reason text should:

Not include your app name. The system-provided alert title already includes your app name. Clearly describe why your app needs the data. If appropriate, you might also explain ways in which your app will not use the data. Use user-centric terminology and be localizable. Be as short as possible, while still being easy to understand. As much as possible, avoid supplying more than one sentence. Use sentence-style capitalization. (Sentence-style capitalization means that the first word is capitalized, and the rest of the words are lowercase unless they are proper nouns or proper adjectives.) Ask permission at app startup only if your app can’t perform its primary function without the user’s data. People will not be bothered by this if it’s obvious that the main function of your app depends on knowing their personal information.

Avoid making programmatic calls that trigger the alert before the user actually selects the feature that needs the data. This way, you avoid causing people to wonder why your app wants their personal information when they’re doing something that doesn’t appear to need it. (Note that getting the user’s Location Services preference does not trigger the alert.)

For location data, check the Location Services preference to avoid triggering the alert unnecessarily. You can use Core Location programming interfaces to get this setting (to learn how to do this, see Core Location Framework Reference). With this knowledge, you can trigger the alert as closely as possible to the feature that requires location information, or perhaps avoid an alert altogether.

You can refer this