Post not yet marked as solved
Very late reply, but just for anyone else I use the following:
{
BOOL isAppOnMac = NO;
if (@available(iOS 14.0, *)) {
isAppOnMac = [NSProcessInfo processInfo].isiOSAppOnMac;
}
return isAppOnMac;
}
Post not yet marked as solved
I'm seeing the same issue on some devices, both iPhones and iPads, running the production release of iOS/iPadOS 17.0.2.
I thought that perhaps this issue was only with [HKHealthStore isHealthDataAvailable], so as a test I tried bypassing that call and proceeding with the call to [healthStore requestAuthorizationToShareTypes:], wrapped in a try/catch block. The authorization check though just throws an exception indicating the same error, that "Health data is unavailable on this device", so internally, the auth request API is still calling [HKHealthStore isHealthDataAvailable].
The issue doesn't appear on all devices, most seem to work. I have customers with multiple devices and it will work on one but not the other; in some cases it's their iPhone that doesn't work, and in others it's their iPad running iPadOS 17.
I've tried going into the Health App to make sure I've gone through its initial setup in case that was the issue, but it had no effect.
The next step is to create a simple app that demonstrates the problem and submit that to Apple with a bug report, but I've done this in the past and waited years with no resolution or response from Apple.
Were you able to resolve the issue or have you discovered anything else?
Post not yet marked as solved
I'm seeing 15% for app sales now in the US, but App Bundles are still at 30% for some reason. I've contacted app store connect support because there's no mention in the Paid Applications of any sales being charged anything other than 15%.
Either they're not handling bundles correctly or they need to update the Paid Apps agreement so it is consistent with the actual commission rates being charged--otherwise, it creates a tax issue because the commissions they took won't agree with your backup documentation.
Post not yet marked as solved
I have the same issue. When I "View All Sizes in Media Manager" there are no grayed out screenshots for any device or language. The new App Store Connect site is very buggy, it times out more half the time when I try to save updates, and sometimes it won't allow screenshots to be re-ordered. I could try to delete and re-upload screenshots, but it's a lot, 5 apps x 5 languages x iPhone and iPad...there's no way that the App Store would be able to get through those uploads without even more stalled uploads. Also, if the stalled uploads are not visible to me now, deleting and re-adding may not clear the issue.
Post not yet marked as solved
To make this behave as it did prior to iOS 13, you can move the request for authorization further up in the flow by having your "add media" button call the following requestAuthorization method, and then if the user grants the permission present the media picker:[MPMediaLibrary requestAuthorization:^(MPMediaLibraryAuthorizationStatus status)You would only need to do this for iOS 13. While it's possible for app developers to move this request further up in the workflow the default should not be *after* the user's media has been selected. It gives apps access to metadata even if the user denies the request and it looks insecure from a user-experience perspective.
Post not yet marked as solved
Hopefully, this gets fixed quickly because it's a privacy flaw that violates Apple's own data-sharing and privacy rules. We're too close to the GA release for bugs that violate user privacy to still be in the betas.In the meantime though, if you have an app that selects media you may be used to that media collection not being populated if the user denies access. In iOS 13 it will be populated, but you need to check if they've actually granted access because when you try to use the media you won't be able to, but you'll have all its metadata.
Post not yet marked as solved
I ran into this issue as well. It's related to the new dark and light modes. In light, or default, mode they auto tint button images on UISegmentedControls to black, and in light mode to white. In my case, my apps use black backgrounds on UISegmentedControl buttons so this was making my buttons invisible--and I didn't want to either change the entire UI to forced dark mode or change my color palatte just to work with Apple's automatic choices for my button colors. I tried using image xassets with light/dark options, tinting the parent view and subviews, dynamically swapping out images..none of those worked.But I noticed that they don't do this to auto-tinting to text labels so I tried setting those attributes and it worked. It responds to the TitleTextAttributes foreground color attribute:NSDictionary *attributes = [NSDictionary dictionaryWithObject:[UIColor whiteColor] forKey:NSForegroundColorAttributeName]; [segmentedControl setTitleTextAttributes:attributes forState:UIControlStateNormal];
Post not yet marked as solved
According to the docs, as of iOS 13, applicationMusicPlayer can no longer play iTunes Music in the background. Only the systemMusicPlayer can do this now, although it has fewer features and is generally not recommended by Apple.
Post not yet marked as solved
I'm also not sure anyone looks at the Feedback tool submissions. I have reproducible bugs with sample projects submitted in 2014, 2015, 2016 that are still in the 'Open' state. Most of those bugs don't appear anymore, but I don't think anyone ever looked at those bug reports.
