While uploading app-file to itunesconnect the XCode says: improper advertising identifier [IDFA] usage...etc.
But I do not use this feature in my project. I've tried to find any
[[[ASIdentifierManager sharedManager] advertisingIdentifier] UUIDString]
calling. Futhermore, I'm just fixing a bug of my app, I hadn't included such features since my first release. The first release didn't said about IDFA-usage.
Well, this error happened about 15 days ago and it wasn't clear what is the reason till Apple released the Xcode update the same day and everything went smooth after that. Again, today I get the same message though I tried to upload the same builds for an app which I submitted 8 days ago.
I think we have just to wait for a few hours and see what will happen.
EDIT: Here is a link to show people complain about it at that time and how it was solved without doing anything: LINK
UPDATE: For anyone who uses PlayHaven ads, this may be helpful to avoid this error. Comment the 2 following sections:
In the file PHAdRequest.m (Lines 35-44)
/* if (![PHAPIRequest optOutStatus] && [ASIdentifierManager class])
{
NSUUID *uuid = [[ASIdentifierManager sharedManager] advertisingIdentifier];
NSString *uuidString = [uuid UUIDString];
if (0 < [uuidString length])
{
theIdentifiers[#"ifa"] = uuidString;
}
}*/
In PHAPIRequest.m (Lines 379-383):
/* if ([ASIdentifierManager class])
{
NSNumber *trackingEnabled = [NSNumber numberWithBool:[[ASIdentifierManager sharedManager] isAdvertisingTrackingEnabled]];
[combinedParams setValue:trackingEnabled forKey:#"tracking"];
}*/
This is a temporary workaround till PlayHaven updates their SDK.
I had provided this answer on another similar question and it seems to have been of help & I think my answer is particularly suited also to this question...
I had a similar error in an update to an app that had previously updated fine and then a few days ago was causing an error, after Apple made a recent change. I wasn't using any ads but do have Facebook integration (which needs the AdSupport framework). I believe, after searching the net, that Facebook uses the advertising ID for its own analysis purposes so, even though I'm not including ads in my app, the validation and upload processes through xCode were failing with the error "Your app contains the Advertising Identifier [IDFA] API..."
I searched and found that I needed to download the Facebook SDK source code, update the FBUtility.m to remove the references to the advertisingID but, in fact, I simply needed to:
1) download the source code for the latest SDK, which I did from here: https://github.com/facebook/facebook-ios-sdk (I downloaded the zip file from github to my documents folder)
2) build the framework - open the terminal. Use cd documents at the command prompt, then use this command: sudo scripts/build_framework.sh, which will run the build_framework.sh script that is in the scripts subfolder within the downloaded Facebook SDK folder
3) Remove the old FacebookSDK.framework from your Xcode project and add the new one (in my case, I navigated to documents/facebook-ios-sdk/build & choose the FacebookSDK.framework folder
4) Archive the project and it should (it was in my case) be good to upload
Hope that helps someone along the way - I've been at this for days!!
Simply upload your binary as you've been doing this while, and broadly classify IDFA in two categories:
publisher: You use third-party ad-networks library to display ad. Choose the 1st option in IDFA -> "Serve advertisements within the app". You're a publisher since you show ads, but do not perform advertising for your own app.
Advertiser: You use third-party libraries to track conversions for your app, as well as track 'goals' in your app. You directly do not show ads in your app. Choose the 2nd & 3rd option in IDFA -> "Attribute this app installation to a previously served ad". AND "Attribute an action taken within this app to a previously served advertisement".
Mixed: You track conversions for your app, as well as display ads in your app. Choose all three options.
In case of PlayHaven, setup PH_USE_AD_SUPPORT to 0 will disable the AdSupport framework.
PHConstants.h
/**
* By default, PlayHaven will require the AdSupport framework. Projects using a version of
* Xcode older than 4.5 may define \c PH_USE_AD_SUPPORT to be 0.
*
* #note By disabling the AdSupport framework, the SDK will not be able to collect the IFA
**/
#ifndef PH_USE_AD_SUPPORT
#define PH_USE_AD_SUPPORT 1
#endif
Work for me to fix "improper advertising identifier" when submit.
Related
We have App in ios. It was developed in unity. Yesterday apple informed that our app has been rejected because we have been used advertising in your app. But we did not used any advertisements in our app. This is the screen shot.
we have been searching in google. but we have not found any solutions. So any idea how to remove the Isadvertisingtrackingenabled in unity.
strong textThose who have received the above error. I have followed the below steps and our app got approved.
The answer is taken from this forum
https://forum.unity.com/threads/important-changes-for-ios-kids-apps-action-needed-by-developers.838939/.
all the credit goes to that person only. I am just posting for information purpose only.
To make the manual fix, please follow the instructions below:
Open the file DeviceSettings.mm within your Xcode project.
Find and remove the line #include
Find and completely remove the function “QueryASIdentifierManager”
Find the function “UnityAdvertisingIdentifier” and replace it with:
extern "C" const char* UnityAdvertisingIdentifier()
{
return NULL;
}
UnityAdvertisingTrackingEnabled()
find the unityadvertisingtrackingenabled and replace the code.
extern "C" int UnityAdvertisingTrackingEnabled()
{
return 0;
}
NOTE:
In Package manager . Unity Ads and Unity Analytics are enabled as default. So kindly disable the both. and then following the above steps. it will works fine for me.
after following the above steps mentioned by this above forum . you will receive one error. So to avoid the error.Kindly add
SystemConfiguration.framework.
in xcode FrameWork Path.
Then the error will solved and your app also got approved.
if you some one need any assistance i am ready to help you.
I have an app in private which need to scan all applications and schemes and get it by using private API LSApplicationWorkspace defaultWorkspace with others functional method, such as privateURLSchemes allInstalledApplications. This app works good and I can get all I need from the private API before iOS 11, but in this version I only got some warning and an empty array. It seems Apple limits private API that developer can't use in private in iOS 11.
So my question is what alternative ways can achieve my need in iOS 11?
UPDATE: This method does not work on iOS 12 - entitlement required
There is a way to find if a specific application is installed, its not a list of all apps like allInstalledApplications returned but its useful to query for a specific bundle id
Here is an example, the method receives bundle id and return true if it's installed on the device:
- (BOOL)checkIfAppInstalled: (NSString*)bundleID {
dlopen("/System/Library/PrivateFrameworks/MobileContainerManager.framework/MobileContainerManager",RTLD_NOW);
Class MBAppManager = NSClassFromString(#"MCMAppDataContainer");
NSError * error ;
id contentApp = [MBAppManager performSelector:#selector(containerWithIdentifier:error:) withObject:bundleID withObject:error];
return contentApp != nil;
}
Private API is just that—private API. Using it is completely unsupported, and as such, you cannot rely on a private API continuing to work in future versions of the OS.
In addition, I would be highly surprised if an app that used private API were able to get into the App Store, since it's one of the things Apple's reviewers scan for.
In enterprise you can use Apple Mobile Device Management (MDM) Protocol ManagedApplicationList commands to get the status of managed applications
From this post. From the comment of #ovo under the original question, it seems works.
Using MobileContainerManager.framework it's possible to check if an app is installed by using bundle id.
//If the device is iOS11
if ([[UIDevice currentDevice].systemVersion floatValue] >= 11.0) {
NSBundle *container = [NSBundle bundleWithPath:#"/System/Library/PrivateFrameworks/MobileContainerManager.framework"];
if ([container load]) {
Class appContainer = NSClassFromString(#"MCMAppContainer");
id test = [appContainer performSelector:#selector(containerWithIdentifier:error:) withObject:bundleId withObject:nil];
NSLog(#"%#",test);
if (test) {
return YES;
} else {
return NO;
}
}
return NO;
} else {
//Usual way
}
i got same Apple Reject.
Apple Says
Your app uses or references the following non-public APIs:
LSApplicationWorkspace
The use of non-public APIs is not permitted on the App Store because
it can lead to a poor user experience should these APIs change.
Continuing to use or conceal non-public APIs in future submissions of
this app may result in the termination of your Apple Developer
account, as well as removal of all associated apps from the App Store.
Solutions
To find out which library or code is causing this problem use the below code snipped.
1-) Open the terminal in macbook (cmd+ space) and than write terminal
2-) change the project directory with the below code
cd /Users/emreg/Documents/{your project url}
3-) To search appropriate word
grep -r LSApplicationWorkspace .
grep -r allApplications .
in my case, Blesh SDK has included LSApplicationWorkspace and allApplications keyword which is not permitted by Apple. When i upteded SDK, my problem is solved.
i hope, this answer will help someone.
I have an iOS application that stores some sensitive information in the keychain.
While writing values into the keychain, I am getting error code -34018.
I am currently using Apple's iOS KeyChainItemWrapper class.
Both of the following lines of code receive the same error code.
OSStatus res1 = SecItemCopyMatching((__bridge CFDictionaryRef)genericPasswordQuery, (CFTypeRef *)&attributes);
OSStatus res = SecItemUpdate((__bridge CFDictionaryRef)updateItem, (__bridge CFDictionaryRef)tempCheck);
This issue does not occur every time, but intermittently. Once I get this error, I am no longer able to write any values to the keychain.
I have printed the error description like so:
NSError *error = [NSError errorWithDomain:NSOSStatusErrorDomain code:res userInfo:nil];
and this is what the error prints out:
Error: Error Domain=NSOSStatusErrorDomain Code=-34018 "The operation couldn’t be completed. (OSStatus error -34018.)"
Seems like this is a bug in Keychain, which only appears when you launch your app from xcode. See here: https://github.com/soffes/sskeychain/issues/52
We debugged it a lot and it seems an issue accessing the keychain when
the app is launched from the background. This is only happening with
the debugger (i.e. when launched from Xcode). We think the issue
might be related in our case to the debugger keeping alive the app
even if it should be killed by the OS. We tried in fact to run the
app and then put it in background and launch many other app to occupy
RAM. With the debugger the bug came up when resuming the app from the
background, while without the debugger it didn't (we did run at least
10 tests each).
If someone will come here back with this error and XCode8 with iOS10, probably you have to enable KeyChain Share in the tab Capabilities:
As others have mentioned, this is a Keychain bug, one that Apple is aware of and has been aware of since at least mid-2015.
As of March 22, 2016, however, Apple has said:
We believe these problems were resolved in iOS 9.3.
iOS 9.3 was released on March 21, 2016.
See the thread: https://forums.developer.apple.com/thread/4743
To quote the response by an Apple employee:
Mar 22, 2016 3:28 AM
OK, here’s the latest. This is a complex problem with multiple possible causes:
Some instances of the problem are caused by incorrect app signing. You can easily distinguish this case because the problem is 100% reproducible.
Some instances of the problem are caused by a bug in how iOS supports app development (r. 23,991,853). Debugging this was complicated by the fact that another bug in the OS (r. 23,770,418) masked its effect, meaning the problem only cropped up when the device was under memory pressure.
We believe these problems were resolved in iOS 9.3.
We suspect that there may be yet more causes of this problem.
So, if you see this problem on a user device (one that hasn’t been talked to by Xcode) that’s running iOS 9.3 or later, please do file a bug report about it. Try to include the device system log in your bug report (I realise that can be tricky when dealing with customer devices; one option is to ask the customer to install Apple Configurator, which lets them view the system log). And if you do file a bug, please post your bug number, just for the record.
On behalf of Apple I’d like to thank everyone for their efforts in helping to track down this rather horrid issue.
Share and Enjoy
This held me up for 2 hours before I found a quick "fix" - reboot the iOS device
A quote from the discussion at http://forums.developer.apple.com/thread/4743,
From user littledetails
As others have reported, this mysterious keychain error is most easily observable when launching via Xcode with the debugger attached. Once the error starts occurring, the keychain doesn't seem to right itself regardless of memory pressure until one reboots the device.
When I rebooted my device the error went away, allowing me to continue testing. Not sure what else to do. In my situation, moving to NSUserDefaults or some other storage solution was not a possibility.
One way to get around this issue with the keychain is to use dispatch_async to allow the app to launch. This works when the app is opened from the background. Also make sure you have the kSecAttrAccessibleAfterFirstUnlock accessibility setting on the keychain.
dispatch_async(dispatch_get_main_queue(), ^{
// save/write to keychain
})
I am using GenericKeychain classes from apple:
https://developer.apple.com/library/content/samplecode/GenericKeychain/Introduction/Intro.html#//apple_ref/doc/uid/DTS40007797-Intro-DontLinkElementID_2
struct KeychainConfiguration {
static let serviceName = "MyAppService"
/*
Specifying an access group to use with `KeychainPasswordItem` instances will create items shared accross both apps.
For information on App ID prefixes, see:
https://developer.apple.com/library/ios/documentation/General/Conceptual/DevPedia-CocoaCore/AppID.html
and:
https://developer.apple.com/library/ios/technotes/tn2311/_index.html
*/
// static let accessGroup = "[YOUR APP ID PREFIX].com.example.apple-samplecode.GenericKeychainShared"
/*
Not specifying an access group to use with `KeychainPasswordItem` instances
will create items specific to each app.
*/
static let accessGroup: String? = nil
}
In this file I was specifying my custom accessGroup in this line static let accessGroup = "[YOUR APP ID PREFIX].com.example.apple-samplecode.GenericKeychainShared"
After returning to static let accessGroup: String? = nil the problem was gone. :)
Make sure keychain sharing must on under Capabilities in project Target.
In my case the App_Name.entitlements file has different bundle id than of my project bundle id. So, I change bundle id in the App_Name.entitlements file as of my project bundle id.
e.g., Suppose your project bundle id is com.Apple.testApp then got to
App_Name.entitlements file open key Keychain Access Groups key which is of Array type.
Under item0 set value of your project bundle id as eg:- $(AppIdentifierPrefix)com.Apple.testAp.
According to #iCaramba's answer. I've found a workaround:
Stop the task to kill the app (if you are already running the app)
Launch the app on your device manually. DO NOT use Xcode
Use Xcode to re-launch the app
when validating my app, I get an error saying
"Improper Advertising Identifier Usage. Your app contains the Advertising Identifier [IDFA] API but you have not respecting the Limit Ad Tracking setting in iOS."
I have check "Yes" on the Prepare for Upload page for Advertising Identifier.I am using revmob ads and flurry analytics in my app(COCOS2D-X project).How to fix this issue, I have tried a lot but not succeed.I have use below code into appdelegate but no luck.
- (NSString *)identifierForAdvertising
{
if([[ASIdentifierManager sharedManager] isAdvertisingTrackingEnabled])
{
NSUUID *IDFA = [[ASIdentifierManager sharedManager] advertisingIdentifier];
return [IDFA UUIDString];
}
return nil;
}
this IDFA issue was still happening for me today. I tracked it down to the GoogleAnalytics pod, so I just updated the pod to the latist version by specifying pod 'GoogleAnalytics-iOS-SDK', '~> 3.0.7' in the podfile which fixed the issue for me. the version was previously unspecified but was using 3.0.3.
Around April 26th Apple changed their IDFA scanning procedures. Not only do you have to check the appropriate checkboxes after you click on the "prepare for upload", but your code (or any other third party library that you have must use IDFA by using the class directly.
Someone suggested to do this:
"you can do that by replacing direct refs to ASIdentifierManager with NSClassFromString(#"ASIdentifierManager")"
DO NOT load this class using this approach! New scanning procedure will look specifically for this and if it is found instead of direct references - Apple seems to assume that there is some strange usage of the tracking identifier. I can't say I disagree with that decision.
It may not be easy to find exactly which library is at fault. Latest AdMob SDK for example is using the class directly and is NOT the source of a problem.
One way you can find out which library is the source of the problem is to remove AdSupport.Framework from your project and see which libraries fail to link. Those libraries are NOT the problem. See if you have other advertising libraries that do not require you to include AdSupport.Framework - those are most likely the culprit.
It sounds a bit counter intuitive, but the direct referencing is not the problem, dynamic (weak) loading of that class is.
Hope this helps someone - we were pulling our hair out until we found what was the source of the issue.
Looks like Apple has reverted the changes now. All apps are going through just as usual again :)
During my iphone app (iOS7) submission process, I saw the errors shown in the screen. Basically, it says I used non-public symbols __strlcat_chk, strlcpy_chk, I know strlcat and strlcpy, but don't think it could be non-public.
I used Xcode 5.
I also did a quick search strlcat() and strlcpy() in my project, I didn't see I used it.
Any idea what could be the reason.
[Update] I actually got update from Apple, after submitting my ticket through my developer account (We all have 2 tech supports coming with the developer account.) Basically, Apple Support told me it's known issue. Tell apple your app name and id number, your app will be whitelisted. There will no problem to go through the submission verification process once Apple gives a Go signal.
The reason for this can be found in the file:
iOS 7.0/usr/include/secure/_string.h
The code causing the issue seems here:
#if __has_builtin(__builtin___strlcat_chk) && __HAS_FIXED_CHK_PROTOTYPES
#undef strlcat
#define strlcat(dest, src, len) \
__builtin___strlcat_chk (dest, src, len, __darwin_obsz (dest))
#endif
#endif /* __IPHONE_OS_VERSION_MIN_REQUIRED >= 70000 || __MAC_OS_X_VERSION_MIN_REQUIRED >= 1090 /
#endif / __DARWIN_C_LEVEL >= __DARWIN_C_FULL */
I'm not sure what this does, but my guess is this is what is being picked up as the issue when validating the code.
You can compare this to the iOS 6 version of the same _string.h file, and you'll see that there are no references to the two methods, strlcat and strlcpy.
There is also a comment with a rdar reference:
rdar://problem/12622659
Bottom line: This seems to be an issue with the iOS 7.0 SDK, and it's up to Apple to 'fix' it.
UPDATE:
If you really want to submit your app, simply edit the _string.h file, edit #define __HAS_FIXED_CHK_PROTOTYPES 1 to #define __HAS_FIXED_CHK_PROTOTYPES 0
I had this issue using a self-compiled version of OpenSSL. I recompiled OpenSSL against the iOS 6.1 SDK, added libssl.a and libcrypto.a into my project and then built/archived my app against SDK 7.0 and it has now passed validation.
So it does appear to be an issue with iOS 7.0 SDK, but if you still have access to the the 6.1 SDK this workaround should work.