I've had independent Watch apps on the market for over three years now. A continuing problem is that users will buy the apps from an iPhone, but if they don't have their Watch App Store setting enabled to "automatically install apps purchased from other devices", then the apps do not show up on their Watch. This leads to daily support traffic with customers where I have to walk them through looking in the purchase history on the Watch's App Store app to manually install the apps on the Watch (I also tell them how to turn on the setting to enable automatic installs in the future). I can't believe that after three years, this is still a major problem. It seems exacerbated by customers who don't understand the difference between companion apps and independent apps, and they often get belligerent, accusing me of ripping them off because the install didn't happen the way they expected. Does anyone else see this problem as often as me? It has me contemplating pulling my Watch apps. The revenue is decent but I probably burn more $$ in time responding to these requests on a frequent bases. It also leads to a lot of poor reviews and angry customers.

I am trying to add a complication to an existing Watch app, and need to use the ClockKit approach to be compatible with older watchOS versions. I've spent a couple days working on this and have concluded that using placeholder images through an asset catalog is not reliable at all. In fact it seems really broken. First issue, the documentation here has some inaccuracies relative to observed behavior: https://developer.apple.com/documentation/clockkit/creating_complications_for_your_watchos_app/adding_placeholders_for_your_complication?language=objc The documentation says "If you don’t provide any placeholders, the system generates a placeholder based on your app icon." which is not true in practice. If I do not provide placeholder images, the complication only shows "--". Pity, because all my customers really want is a shortcut to launch the app, so having the icon displayed in the complication would be wonderful. OK, so I'll provide some image placeholders in the Xcode assets. The documentation says "If you don’t provide an image for a particular screen size, watchOS resizes the closest available image in that family." Well that's not true either. I have to supply every size in every family or the complication shows "--" on some devices. Even that wouldn't be bad if it really worked. But in Xcode 14, the asset format for complication images only has slots for a few device sizes. So even when I fill all the slots, testing on some other device sizes results in "--" displayed in the complication because there isn't a direct placeholder graphic match for their screen size. Finally, different scale options can be set for the assets, and some offer options for "all sizes" or vector graphics. That would be wonderful since theoretically it can scale to any size and look sharp. Well I tried that with SVG files in the sizes requested, and the graphics show up but do not properly scale on the devices. They end up getting cropped, not scaled. Has anyone gotten this to work properly? It seems totally broken. I can certainly write up code to deliver complication graphics as part of the complication data source, but without reliable static placeholder graphics, that will still leave some undesirable gaps when a user first installs the app. I am really surprised this is so unreliable.

I don't submit in-app purchases very often, but when I do, it seems like the reviewers reject the app about 50% of the time because they cannot locate the IAP. This despite the fact that I give detailed instructions in the "review notes" section of the in-app purchase review information and always include a screenshot. At least half the time, the app will get rejected and they ask how to find the IAP. I paste the same exact information into resolution center and then the process proceeds along. Am I being too optimistic to think that a reviewer should read the review notes submitted with the IAP? Or at least look for that information in the IAP submission before rejecting the app and going through resolution center? I don't get it.

In moving over to PhotoKit to save photos+metadata from my app, I discovered what I think is a pretty serious bug when associating a file name with the photo. First of all, here is what I am doing:PHAssetCreationRequest *assetRequest = [PHAssetCreationRequest creationRequestForAsset]; PHAssetResourceCreationOptions *creationOptions = [PHAssetResourceCreationOptions new]; creationOptions.originalFilename = @"mycustomname.jpg"; creationOptions.uniformTypeIdentifier = @"public.jpeg"; creationOptions.shouldMoveFile = YES; [assetRequest addResourceWithType:PHAssetResourceTypePhoto fileURL:[NSURL fileURLWithPath:imgDataFilePath] options:creationOptions];This does associate a filename with the asset, but the filename is not recognized in most typical software that can import photos from a device. In fact, the only software that seems to recognize it is Photos on a Mac, and only when the iPhone is tethered to the Mac — if a photo comes across through iCloud PhotoStream, the specified filename is often lost. And PC users or folks using other software to import/sync photos (including image capture on a Mac to a USB-tethered iPhone) will not see the specified filename or even the typical camera roll name like "IMG_1234.JPG" -- they will instead see a random and useless alphanumeric filename like "ABCD1234.JPG".I submitted a bug report about this (#41787363) but after a couple rounds of communication, the bug was closed. I don't think the folks looking at the bug report really understood the problem or looked at my sample app because they just told me to use the above approach to name a file, which is what I am already doing and is what causes the bug in the first place. I have a sample app that demonstrates the problem and it can be easily seen using the Image Capture app on a Mac to view photos on a tethered iPhone. Not sure what else I can do about this so I am posting up here in case anyone else runs into the problem. I have seen a couple other reports of this problem elsewhere on the internet so it's affecting other folks.