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

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