UIGetScreenImage will be reject now? - ios

I know UIGetScreenImage is a private api, and in a period time can use in the appstore.
and later someone said can't use anymore.
So I ask here to make sure, Can use in my app and pass to Appstore?
Best Regards

Take a look at this Apple tech note. It shows how to "legally" do screenshots in UIKit where it will get accepted into the App Store:
http://developer.apple.com/library/ios/#qa/qa1703/_index.html#//apple_ref/doc/uid/DTS40010193

They have been rejecting it again for a long time, since iOS 4 release in 2010 when they introduced AVFoundation framework which was a solution for all the camera frame capturing that UIGetScreenImage() was mostly used for before.
They offered two alternatives, one for camera frames (Technical Q&A QA1702) and one for UIKit elements (Technical Q&A QA170 - the one that Michael mentioned), but neither of those is nearly enough usable for taking actual screenshots.
You can read the announcement at developer forums (iOS Developer Program account required).

Around a year ago, Apple started to run static analysis on submitted binaries during the App Store review process. Before that, access to private APIs will pass the review if the functionality itself wasn't too obvious to be caught by the reviewer.
Currently, reviewer uses automated methods to identify private APIs by their names. I recall reading somewhere that, not only aren't you allowed to call them, but also can't you use private API names in Category method names. I imagine because the scanning process is automated, you wouldn't have a shot to pass the review if you did use undocumented methods.

Related

How do I create a built-in demo regarding App Store Connect Guideline?

I have a problem when pushing my iOS App to the App Store. I know this is not a coding issue.
I got rejected because of guideline 2.1 that the App Store wants to test full features of my app. There are parts of features that they are unable to reproduce (e.g. OTP code, product code ,etc).
What does it mean by providing built-in demo regarding the 2.1 guidelines? How can I make it?
Added to 2.1: “If you are unable to provide a demo account due to
legal or security obligations, you may include a built-in demo mode in
lieu of a demo account with prior approval by Apple. Ensure the demo
mode exhibits your app’s full features and functionality.”
My apps never got rejected. You can use the form where you can put comments to the reviewer into how to create an OTP entry, for instance, like, use this seed, and provide the seed. Remember the QRcode are only a convenience to provide the seed. Try a seed like 123456 depending on the algorithm the length may vary. Just inform how they can view this feature working. It's very simple actually. I cannot see something that you cannot communicate previouslly to the reviewer... if was a network access, provide a temporary APIKEY or better, a demo account. You can always remove later.

Is it possible to detect if any other certain app is Currently running or not in iOS?

Let say If I want to check if the facebook or any other application is currently running on device ?
The answer is simply "No", this is absolutely not possible in iOS.
(Note that you can easily "open" another app - it's just like opening a web link - but you can not "check if it is already open".)
Simply your answer is NO
The reason behind this, in case of iOS, every app is running like on own sandbox. So there is no connection between one sandbox to another.
Update 2:
Decided to use Code-Level Support.
Included with your paid membership are two Technical Support Incidents
(TSIs) for code-level support from Apple support engineers.
Reply from Apple:
Automatic Assessment Configuration limits what features of the system
are available while in a testing environment. It locks the device to a
single app. It does not provide oversight, such as identifying which
apps are running.
Classroom is an app targeting K-12 classrooms. It provides teacher
oversight of student activities during lessons, including viewing
student screens.
https://www.apple.com/education/k12/teaching-tools/
https://support.apple.com/guide/classroom/welcome/ipados
I'm not aware of any functionality associated with either of these
that provides for notification of apps running in the background.
While I cannot say how any given app is implementing apparent
functionality, I'm pretty confident in saying that the app you mention
earlier is not using either Automatic Assessment Configuration or
integrating with Classroom.
You may want to contact the developer of the app in question.
Of course, it's also possible your colleague misunderstood and the app
is not in fact doing any such reporting.
I would also encourage you to file feedback requesting such a feature.
Please submit your suggestion via Feedback Assistant
https://feedbackassistant.apple.com. For more information on
Feedback Assistant, please visit
https://developer.apple.com/bug-reporting/.
While you were initially charged a technical support incident for this
request, we have assigned a replacement incident back to your Apple
Developer Program account.
Perhaps my colleague mistook Android version of the app for iOS.
Update:
After reading some more about this it could be related to Automatic Assessment Configuration and AEAssessmentSession.
This allows an app to:
Enter single-app mode and prevent students from accessing specific
system features while taking an exam.
and
A session provides protections by preventing access to desktop
elements like:
...
Other apps, except those that you selectively allow
https://developer.apple.com/documentation/automaticassessmentconfiguration
https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_developer_automatic-assessment-configuration
https://developer.apple.com/documentation/automaticassessmentconfiguration/aeassessmentsession
Sample code here:
https://developer.apple.com/documentation/automaticassessmentconfiguration/build_an_educational_assessment_app
Original:
I agree with #AnkurLahiry and #Fattie that it should not be possible due to sandbox environment. According to Apple Developer Forums it is not possible either:
https://developer.apple.com/forums/thread/48374
However a colleague took his hunting degree and they used an app for examination. This app could detect other apps running in the background. For example one person had Teams app running and the examinators could then tell that he had that exact app running on his phone. Not just installed but running in the background.
https://apps.apple.com/se/app/teoriprov-f%C3%B6r-j%C3%A4garexamen/id1548547811
He took the test 2022-04-29 and was using the app version 1.0.8.
I'm not an iOS developer but I have done some experiments with disabling or bypassing SSL Pinning/Certificate Pinning on Android. In this case developers often used checks in the native layer as well as the Java layer to make it difficult to bypass. My guess is that they use low-level access to detect if a process is running or not.
https://security.stackexchange.com/questions/149325/disable-or-bypass-ssl-pinning-certificate-pinning-on-android-6-0-1
https://developer.apple.com/documentation/objectivec
Unfortunately I don't have more information than that. Next step could be contacting them and see if they are willing to share how they did it.
You could also read up on examination apps and classroom:
https://apps.apple.com/us/app/classroom/id1085319084
For Android you can check it like this:
https://stackoverflow.com/a/22503513/3850405

Your app, extension, and/or linked framework appears to contain code designed explicitly with the capability to change your app’s behavior [duplicate]

My latest build was accepted into the Apple app store, but I got the notice quoted below a couple of days later.
My app also uses Rollout.io, and I asked explicitly if this was the problem. No response yet.
If respondsToSelector or performSelector are banned, are there any replacements?
Dear Developer,
Your app, extension, and/or linked framework appears to contain code designed explicitly with the capability to change your app’s behavior or functionality after App Review approval, which is not in compliance with section 3.3.2 of the Apple Developer Program License Agreement and App Store Review Guideline 2.5.2. This code, combined with a remote resource, can facilitate significant changes to your app’s behavior compared to when it was initially reviewed for the App Store. While you may not be using this functionality currently, it has the potential to load private frameworks, private methods, and enable future feature changes.
This includes any code which passes arbitrary parameters to dynamic methods such as dlopen(), dlsym(), respondsToSelector:, performSelector:, method_exchangeImplementations(), and running remote scripts in order to change app behavior or call SPI, based on the contents of the downloaded script. Even if the remote resource is not intentionally malicious, it could easily be hijacked via a Man In The Middle (MiTM) attack, which can pose a serious security vulnerability to users of your app.
Please perform an in-depth review of your app and remove any code, frameworks, or SDKs that fall in line with the functionality described above before submitting the next update for your app for review.
EDIT:
Apple forum mentions this: https://forums.developer.apple.com/thread/73640
It is not respondsToSelector:, performSelector: that are banned. The ban is on putting dynamic content as a parameter to this method. For example, this is not banned:
if([self.delegate respondsToSelector: #selector(myDelegateMethod)]) {
[self.delegate performSelector: #selector(myDelegateMethod)];
}
However, this code might be banned:
NSString *remotelyLoadedString = .... (download from your backend)
[self performSelector: NSSelectorFromString(remotelyLoadedString)];
On March 8th 2017, Apple warned all the developers of JS injection. This includes libraries like:
JSPatch
Rollout.io
AMapFoundation as it includes JSPatch [edit: they now provide a new version without it]
Bugly as it includes JSPatch [edit: they now provide a new version without it]
GTSDK as it includes JSPatch [edit: they now provide a new version without it]
...
If you are directly using a service like JSPatch or Rollout.io, you should stop using it.
If you are using a third-party that was depending on JSPatch indirectly, you should request an updated version of your third-party that does not include JSPatch anymore.
dlopen
dlsym
respondsToSelector
performSelector
method_exchangeImplementations
Sometimes some people used to think all above methods are banned but the exact issue is, those methods are restricted to use parameters that are generated at runtime. For example,
when we use,
SEL selector = NSSelectorFromString(#"stopProgress");
Its allowed, but
when we use,
SEL selector = NSSelectorFromString(#"%#", runtimeFunction);
Its not allowed!
The app store notice told you exactly what the situation is.
The functions in question are not banned. What is banned is using those functions to circumvent the app store review process and do things like call private APIs or download and execute code. App store apps are required to have all of the code that they run compiled into them. They are also not allowed to use private APIs from iOS. If an API isn't documented, it's off limits.
My guess is that you know exactly what they are talking about, and you are trying to bypass the rules.
If you are not calling private APIs, downloading scripts and using performSelector to call them, then you should submit an appeal to the app review board, explaining what you are doing, in detail, and how it is not a violation of the app store guidelines. If you're truly not breaking the rules and have a legitimate reason for what you're doing then you will very likely be able to get your rejection overturned, but you will need to offer full disclosure and a compelling argument as to why what you are doing is not breaking Apple's rules.
Their field, their ball, their rules. If you're not willing to play by Apple's rules your only real alternative is to try to distribute your app for jailbroken devices, but that will likely cost you your developer program membership.
EDIT:
Based on your comment below, it sounds like the problem is that the framework Rollout.io that you're using is doing js injection, which Apple now bans. I suggest searching on "Rollout.io iOS app store ban" or similar.

Are performSelector and respondsToSelector banned by App Store?

My latest build was accepted into the Apple app store, but I got the notice quoted below a couple of days later.
My app also uses Rollout.io, and I asked explicitly if this was the problem. No response yet.
If respondsToSelector or performSelector are banned, are there any replacements?
Dear Developer,
Your app, extension, and/or linked framework appears to contain code designed explicitly with the capability to change your app’s behavior or functionality after App Review approval, which is not in compliance with section 3.3.2 of the Apple Developer Program License Agreement and App Store Review Guideline 2.5.2. This code, combined with a remote resource, can facilitate significant changes to your app’s behavior compared to when it was initially reviewed for the App Store. While you may not be using this functionality currently, it has the potential to load private frameworks, private methods, and enable future feature changes.
This includes any code which passes arbitrary parameters to dynamic methods such as dlopen(), dlsym(), respondsToSelector:, performSelector:, method_exchangeImplementations(), and running remote scripts in order to change app behavior or call SPI, based on the contents of the downloaded script. Even if the remote resource is not intentionally malicious, it could easily be hijacked via a Man In The Middle (MiTM) attack, which can pose a serious security vulnerability to users of your app.
Please perform an in-depth review of your app and remove any code, frameworks, or SDKs that fall in line with the functionality described above before submitting the next update for your app for review.
EDIT:
Apple forum mentions this: https://forums.developer.apple.com/thread/73640
It is not respondsToSelector:, performSelector: that are banned. The ban is on putting dynamic content as a parameter to this method. For example, this is not banned:
if([self.delegate respondsToSelector: #selector(myDelegateMethod)]) {
[self.delegate performSelector: #selector(myDelegateMethod)];
}
However, this code might be banned:
NSString *remotelyLoadedString = .... (download from your backend)
[self performSelector: NSSelectorFromString(remotelyLoadedString)];
On March 8th 2017, Apple warned all the developers of JS injection. This includes libraries like:
JSPatch
Rollout.io
AMapFoundation as it includes JSPatch [edit: they now provide a new version without it]
Bugly as it includes JSPatch [edit: they now provide a new version without it]
GTSDK as it includes JSPatch [edit: they now provide a new version without it]
...
If you are directly using a service like JSPatch or Rollout.io, you should stop using it.
If you are using a third-party that was depending on JSPatch indirectly, you should request an updated version of your third-party that does not include JSPatch anymore.
dlopen
dlsym
respondsToSelector
performSelector
method_exchangeImplementations
Sometimes some people used to think all above methods are banned but the exact issue is, those methods are restricted to use parameters that are generated at runtime. For example,
when we use,
SEL selector = NSSelectorFromString(#"stopProgress");
Its allowed, but
when we use,
SEL selector = NSSelectorFromString(#"%#", runtimeFunction);
Its not allowed!
The app store notice told you exactly what the situation is.
The functions in question are not banned. What is banned is using those functions to circumvent the app store review process and do things like call private APIs or download and execute code. App store apps are required to have all of the code that they run compiled into them. They are also not allowed to use private APIs from iOS. If an API isn't documented, it's off limits.
My guess is that you know exactly what they are talking about, and you are trying to bypass the rules.
If you are not calling private APIs, downloading scripts and using performSelector to call them, then you should submit an appeal to the app review board, explaining what you are doing, in detail, and how it is not a violation of the app store guidelines. If you're truly not breaking the rules and have a legitimate reason for what you're doing then you will very likely be able to get your rejection overturned, but you will need to offer full disclosure and a compelling argument as to why what you are doing is not breaking Apple's rules.
Their field, their ball, their rules. If you're not willing to play by Apple's rules your only real alternative is to try to distribute your app for jailbroken devices, but that will likely cost you your developer program membership.
EDIT:
Based on your comment below, it sounds like the problem is that the framework Rollout.io that you're using is doing js injection, which Apple now bans. I suggest searching on "Rollout.io iOS app store ban" or similar.

Counting missing calls on iPhone/iOS

I'm quite new at iOS app development.
I'm starting to work on an app that should in somehow be able to count the missing calls that the iPhone has registered since the app is running.
I've read that in no way Apple is going to let me intercept incoming calls, answer them, reject them, or "whatever" them, but I wonder if we are allowed to count them.
I've found some people that say it can be done (well, I knew it is possible, cause LockInfo does, for instance), but I don't know if it's attached to jailbroken iPhones only.
Anyway, as far as I have seen, it must be done with some methods related to kCTCallStatusChangeNotification from CoreTelephony.h if I'm right (as seen in http://blogs.oreilly.com/digitalmedia/2008/02/when-it-comes-to-the.html), but I coudln't find much more info about it.
Hello and welcome to iPhone Development! :) As you have already pointed out, you can be informed through a notification if a call is happening. Great! But here comes the dark side of iPhone Development:
That's the end of the road. 95% of the "Phone Functionality" of the iPhone is private API and you don't technically have access to it.
Of course, you could header-dump the private frameworks and use them anyway, but that will get your app instantly rejected from the AppStore, which wouldn't be fun for anyone.
LockInfo is an extension for jailbroken devices - those guys are known for not caring too much about Apple nor Private APIs ;) Also, as you may have seen, LockInfo isn't on the AppStore because it would've never made it that far.
So Apple, why is there CoreTelephony?
Well, it's there for some very specific reasons. I personally use it to obtain the carrier name of the device for certain country specific restrictions in my application. The notification you talked about, along with others, tend to be used by developers to prepare your app for going into an inactive state (when the call comes in, your app is put in the background), so its used to pause tasks etc... CoreTelephony has never been intended for any deep level access to the telephone system of the iPhone.
So sorry, you can't obtain the information you're looking for using public APIs.

Resources