Screenshots - are we allowed to use UIGetScreenImage()

[TOMSOFT]

Hi I am currently trying to incorporate a screenshot feature into one of my apps. Are we allowed to use the undocumented method UIGetScreenImage() in our App Store apps? I have implemented to code and it all works fine. Will my app be rejected?

I know you can do the same process using other code e.g. UIGraphicsBeginImageContext(self.view.frame.size); but I find this way much faster and easier to implement.

Thanks for any help

[wuf810]

Originally Posted by TOMSOFT

Hi I am currently trying to incorporate a screenshot feature into one of my apps. Are we allowed to use the undocumented method UIGetScreenImage() in our App Store apps? I have implemented to code and it all works fine. Will my app be rejected?

I know you can do the same process using other code e.g. UIGraphicsBeginImageContext(self.view.frame.size); but I find this way much faster and easier to implement.

Thanks for any help

Just submit your app and see. Not sure if Apple can determine the process you use i.e if it can be done in a legitimate way how will they know?

However undocumented/private APIs are subject to change and may break your code...so I would go the official route personally.

[NewiPhoneDeveloper]

Has anyone ever dared to do this and it went live on the app store? Just curious :-)

[gibtang]

Originally Posted by TOMSOFT

Hi I am currently trying to incorporate a screenshot feature into one of my apps. Are we allowed to use the undocumented method UIGetScreenImage() in our App Store apps? I have implemented to code and it all works fine. Will my app be rejected?

I know you can do the same process using other code e.g. UIGraphicsBeginImageContext(self.view.frame.size); but I find this way much faster and easier to implement.

Thanks for any help

I think using undocumented APIs is a valid reason for rejection. So, it is was me, I would not use UIGetScreenImage(), but UIGraphicsBeginImageContext() instead

[NewiPhoneDeveloper]

Yes i know, but unfortunately you can't grab contents of an EAGLview with that method and glReadPixels didn't return the alpha values so far.

[ius260385]

Originally Posted by NewiPhoneDeveloper

Has anyone ever dared to do this and it went live on the app store? Just curious :-)

Yes, my app was rejected for this reason. Do not use it. Try to find an alternative.

[HappyByte]

RedLaser uses it.

Most apps when come to use undocumented APIs encrypt binaries so Apple won't be able to track such a usage.

RedLaser uses it w/o any encryption. Just unzip RedLaser's .ipa and in the Terminal enter the following "cat RedLaser | srtings | grep UIGetScreenImage" - you will see it for yourself.

It seems like either censors didn't notice it as it was added in the update.

Or Apple did this on purpose - they won't delete an app from the store that sells 15-20k copies a day.

[HappyByte]

And as far as I see - there is quite a huge number of apps that do use undocumented APIs.

Many of them are also best selling apps.

Apple won't cut the money flow by deleting these apps.

So if you like to use undocumented APIs and feel that app will benefit from it - do so.

Just manage youself to encrypt your binary to hide any evidence of undocumented APi usage.

And best of all - add this feature not in the first version but with an update so censors won't pay that much of attention to it. Or may be censors obey to the policy for updates of bestselling apps to allow them a few undocumented APIs if they are really useful and improve the app.

[HappyByte]

[self censored]

[Steaps]

Apple runs a static analyser now to see if you are using undocumented API's, you won't get past the approval process.

[HappyByte]

Originally Posted by Steaps

Apple runs a static analyser now to see if you are using undocumented API's, you won't get past the approval process.

This is not true.

You will pass If you know how. The basic technique is to use dynamic loader and encrypt/code function names that are loaded. One can also use one of the existing commercial (there are a few of them) or free (although I don't know such yet) cryptors. Thus analyzer will confused.

I've already decrypted quite a number of apps binaries and have seen a clear evidence how developers hide the usage of such APIs from Apple's analyzer.

But I personally think in some cases censors allow a slight usage of the APIs.

Like for the RedLaser that uses UIGetScreenImage even without any kind of encryption - anyone that can use unzip and terminal can check it out (see my upper post)

P.S. I would even name some of apps that use such APIs for which I've got a decrypted part of code but I prefer that knowledge to stay in private. RedLaser is the only exclusion from that because they even don't bother to hide undocumented APIs usage.

[NewiPhoneDeveloper]

Now that is some interesting news. Not that I intend to make use of any such technique, but outta curiosity: How would one achieve such an ecryption?

[HappyByte]

Originally Posted by NewiPhoneDeveloper

Now that is some interesting news. Not that I intend to make use of any such technique, but outta curiosity: How would one achieve such an ecryption?

Encryption or encoding - is the easy part - not what you have to care about much.

Finding the API itself is what you should think of first.

As for me I'm being much tempted and seduced to use undocumented API but still had no chance - all my current needs are served by standard API quite well. Of course I've got a few ideas that could be done with some not yet available solution but they now can't be solved even with known undocumented APIs Thus I'm regurarly filing feature request to Apple to add one or second into the SDK.

[NewiPhoneDeveloper]

Originally Posted by HappyByte

Encryption or encoding - is the easy part - not what you have to care about much.

Finding the API itself is what you should think of first.

Alright, let's stay with the UIGetScreenImage() one then What now?

[ethanwa]

Originally Posted by HappyByte

The basic technique is to use dynamic loader and encrypt/code function names that are loaded. One can also use one of the existing commercial (there are a few of them) or free (although I don't know such yet) cryptors. Thus analyzer will confused.

Can someone explain this in a bit more detail?

E

[HappyByte]

iTunes Store

Yet another example of the app that uses not so "forbidden" APIs. Although using UIGetScreenImage() instead of direct camera access is incredible slow.

[NewiPhoneDeveloper]

Originally Posted by HappyByte

iTunes Store

Yet another example of the app that uses not so "forbidden" APIs. Although using UIGetScreenImage() instead of direct camera access is incredible slow.

I don't think that this app uses UIGetScreenImage(). I read, that they use a private SDK in combination with their own framework. However, it required Apple's approval for it to get allowed. In fact, that app didn't slip through, it passed the process and Apple knows exactly which APIs are being used.

Anyways, I'm still hoping for a public version of UIGetScreenImage().

[HappyByte]

Originally Posted by NewiPhoneDeveloper

I don't think that this app uses UIGetScreenImage().

Nope.

UIGetScreenImage() - is exactly what they use.

Here is the proof (you can see it yourself by unzipping their .ipa). They don't even try to hide it as with RedLaser:

unknown@darkstar.org [~] $ cat UStreamUI | strings | grep UIGetScreen
@_UIGetScreenImage
_UIGetScreenImage
unknown@darkstar.org [~] $

Own framework is a fake to make others think it's hard to create such an app. There are several things that tell about that.

If it would be really video capturing framework - it would work much faster as a real video recorder does. On my 3GS it is incredibly slow while normal recorder works very smoothly.

I think in this app that is the same as in RedLaser - done by capturing screen with screenshots.

That is the reason why a part of the screen shows a picture that is not overlayed with UI - same as in RedLaser. The part of the screen must remain clear from UI and show original picture in order to be captured that way.

That's why only a part of the image is then broadcasted as if they would like to broadcase full image - it would be captured with their UI over it

[NewiPhoneDeveloper]

Originally Posted by HappyByte

Nope.

UIGetScreenImage() - is exactly what they use.

Here is the proof (you can see it yourself by unzipping their .ipa). They don't even try to hide it as with RedLaser:

unknown@darkstar.org [~] $ cat UStreamUI | strings | grep UIGetScreen
@_UIGetScreenImage
_UIGetScreenImage
unknown@darkstar.org [~] $

Own framework is a fake to make others think it's hard to create such an app. There are several things that tell about that.

If it would be really video capturing framework - it would work much faster as a real video recorder does. On my 3GS it is incredibly slow while normal recorder works very smoothly.

I think in this app that is the same as in RedLaser - done by capturing screen with screenshots.

That is the reason why a part of the screen shows a picture that is not overlayed with UI - same as in RedLaser. The part of the screen must remain clear from UI and show original picture in order to be captured that way.

That's why only a part of the image is then broadcasted as if they would like to broadcase full image - it would be captured with their UI over it

Thanks for that information! I haven't actually checked out their .ipa and I think they are not hiding it, because in that special case they have Apple's blessings. At least, that's what I read in various blogs.

So, if your app really depends on that API, your only chance seems to be encryption. Someone talked about that here and then unfortunately didn't go into detail.

[HappyByte]

Google for "dlopen" and "dlsym". There are plenty of samples.

[NewiPhoneDeveloper]

Originally Posted by HappyByte

Google for "dlopen" and "dlsym". There are plenty of samples.

Thanks! I would never use that of course

[ethanwa]

Originally Posted by HappyByte

iTunes Store

Yet another example of the app that uses not so "forbidden" APIs. Although using UIGetScreenImage() instead of direct camera access is incredible slow.

My app just got approved two days ago that uses this API:

iTunes Store

I made the app in under a day and only because my brother gave me the idea. I said "what the heck, let's give it a shot" and uploaded it. Sure enough to my surprise it was approved!

Maybe they aren't caring as much anymore about this API?

E

[HappyByte]

I've got a friend that submitted an app that uses UIGetScreenImage() in that quick way w/o encryption.

He tells that chances are 50/50. Depending on which moderator is working on approval, his mood and etc.

Btw. he also told that he was unable to submit updates to this app Update was rejected for usage of UIGetScreenImage()

[HappyByte]

So if you need to use hidden API - use it. May be Apple will allow it.

[NewiPhoneDeveloper]

Seems like UIGetScreenImage() is now an official API call???

Please read this blog entry on TUAW

One guy in comments below says, that some Apple guy said on the official forums, that it is now allowed to make use of this API. Can't confirm this information, but it looks very interesting so far!

[EDIT: YES ITS TRUE!!! Log onto the official forums and do a search for UIGetScreenImage();

Here is the quote:

After carefully considering the issue, Apple is now allowing applications to use the function UIGetScreenImage() to programmatically capture the current screen contents. The function prototype is as follows:

CGImageRef UIGetScreenImage();

Note that a future release of iPhone OS may provide a public API equivalent of this functionality. At such time, all applications using UIGetScreenImage() will be required to adopt the public API.