Parse-SDK-iOS-OSX
Parse-SDK-iOS-OSX copied to clipboard
requestAlwaysAuthorization reference prevents AppClip upload to App Store
Any use of requestAlwaysAuthorization prevents the build from showing up in the iTunes Connect when app includes an AppClip target, despite not showing any errors. The following email message is sent:
ITMS-90842: Invalid SDK usage - App clip 'AppClip.app' uses the SDK selector 'requestAlwaysAuthorization', which is not supported. Ensure your app clip is using supported SDK features.
I was able to push up a build successfully by commenting out all references to this in PFLocationManager.m
Can you submit a pull request with your change so we can look at it? Also a heads up, you will need to rebase your PR with the master branch as soon as the actions PR is merged (you can choose to wait until after the merge to create your PR if you want).
@cbaker6 I'll attempt to fix this in a PR, but I am unsure how exactly to approach this. I'll see if I can create another custom flag for an App Clip target.
@cbaker6 I am unable to find where to set a Target flag like the ones in PFLocationManager.m are defined. I am seeing ones in the included iOS Framework but I don't see one that can be used for an AppClip.
Any update on this?
We do have AppClips while using requestAlwaysAuthorization in the main App @mtrezza so I don’t think there’s any bug… Or at least we need more precision on the real bug.
I guess we can close this and reopen if anyone can provide details.
Same issue here: ITMS-90842: Invalid SDK usage - App clip 'xxxxxxxx.app/AppClips/xxxxxxxx-clip.app' uses the SDK selector 'requestAlwaysAuthorization', which is not supported. Ensure your app clip is using supported SDK features.
grep -R requestAlwaysAuthorization * Binary file Products/Applications/xxxxxxxx.app/Frameworks/Parse.framework/Parse matches Binary file Products/Applications/xxxxxxxx.app/AppClips/xxxxxxxx-clip.app/Frameworks/Parse.framework/Parse matches Binary file dSYMs/Parse.framework.dSYM/Contents/Resources/DWARF/Parse matches
Here is the code from Parse:
path: Parse/Core/PFLocationManager.m
- (void)addBlockForCurrentLocation:(PFLocationManagerLocationUpdateBlock)handler {
@synchronized (self.blockSet) {
[self.blockSet addObject:[handler copy]];
}
//
// Abandon hope all ye who enter here.
// Apparently, the CLLocationManager API is different for iOS/OSX/watchOS/tvOS up to the point,
// where encapsulating pieces together just makes much more sense
// than hard to human-parse compiled out pieces of the code.
// This looks duplicated, slightly, but very much intentional.
//
#if TARGET_OS_WATCH
if ([self.bundle objectForInfoDictionaryKey:@"NSLocationWhenInUseUsageDescription"] != nil) {
[self.locationManager requestWhenInUseAuthorization];
} else {
[self.locationManager requestAlwaysAuthorization];
}
[self.locationManager requestLocation];
#elif TARGET_OS_TV
[self.locationManager requestWhenInUseAuthorization];
[self.locationManager requestLocation];
#elif TARGET_OS_IOS
if ([self.locationManager respondsToSelector:@selector(requestAlwaysAuthorization)]) {
dispatch_block_t block = ^{
if (self.application.applicationState != UIApplicationStateBackground &&
[self.bundle objectForInfoDictionaryKey:@"NSLocationWhenInUseUsageDescription"] != nil) {
[self.locationManager requestWhenInUseAuthorization];
} else {
[self.locationManager requestAlwaysAuthorization];
}
};
if ([NSThread currentThread].isMainThread) {
block();
} else {
dispatch_async(dispatch_get_main_queue(), block);
}
}
[self.locationManager startUpdatingLocation];
#elif PF_TARGET_OS_OSX
[self.locationManager startUpdatingLocation];
#endif
}
Altho I tried to add an active compilation conditions (#if !APPCLIP…) without great result on Apple ITMS-90842 issue. Apple DTS suggest to contact the 3rd party code and report on the unsupported SDK.
I don't know how to solve this issue at the moment, but it seams that every AppClip that use Parse SDK will got the same problem.
@mtrezza it could be interesting to reopen this issue to make it futur proof with AppClips. My simple solution was to edit requestAlwaysAuthorization to requestWhenInUseAuthorization. But this is not the proper way I supposed.
Thanks for opening this issue!
@SebC99 Do the details above give more insight? It seems strange that you don't see this issue.
@Coriolan-Bataille Would you want to open a PR?
@mtrezza I would love to, but don't feel confident enough to propose a proper and definitive solution. But I guess the proper way would be to detect with an active compilation conditions if it's an AppClip and use requestWhenInUseAuthorization instead of requestAlwaysAuthorization.
Is the request type currently hard coded in the SDK? If so, we could maybe expose an option to change that?