User Profile

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.

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.

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.

I have been seeing a lot of undesirable behavior with MKOverlayRenderer in iOS 13, including double calls to canDrawMapRect and inconsistent mapRect sizes going between setNeedsDisplayInMapRect, canDrawMapRect, and drawMapRect.Perhaps the biggest problem is that canDrawMapRect seems hardwired to use giant 1536x1536 (point) mapRects no matter what size mapRect needs to be drawn or is invalidated. We used to have very fine control over our map overlay content, being able to surgically redraw 256x256 or 512x512 regions of the map, but now canDrawMapRect is upsizing all mapRects to 1536x1536. That is larger than the short screen dimension on many devices!I have come up with a workaround that involves abandoning canDrawMapRect and doing tile management inside drawMapRect, however this brings on some other headaches and isn't a long term solution.Anybody else seen this? I have filed a bug report, FB7442855. Among other things, I am proposing Apple let developers define the size mapRect they want to use, such that we can have consistent behavior between setNeedsDisplayInMapRect, canDrawMapRect, and drawMapRect. Most maps probably want to use a power of 2 multiple of 256 for their mapRect size in points. 1536? Not so much!thanks,219

I have noticed a problem in several projects where Xcode will flag a C or Obj-C header file as not found, marking the #import or #include line with a red error flag and putting an error symbol in the status area up top. Sometimes cleaning the build folder will resolve this. Other times, the problem remains until I compile, after which it goes away. But then it might come back again later on while editing/coding even though I have done nothing to the header file in question.I have seen this on old projects and projects that were started new with Xcode 11. I assume something changed in the way Xcode parses headers on the fly while doing live syntax checking, etc, and for some reason it's not finding the headers or it's erroneously showing them as missing. All of these headers are in the main source root folder of the projects (and for old projects, have been that way for years without issues). Obviously the compiler finds the headers, otherwise compilation would fail. Anybody else seen this or have suggestions?

I heard from some customers that my app cannot be added to the dock on their Watch as a favorite, and I confirmed this -- in the Apple Watch app on the phone where we make dock settings, my app does not show up in the list down below where you can normally tap a + to move it into the "favorites" list up above.The app does show up fine in the dock on the Watch when showing recents, and it has a proper snapshot and behaves as expected.Was their some project setting or code required in order to be shown as a favorite in the dock? I wouldn't think so, but this has me wondering.

I am seeing something really odd. Initially I wanted to add another target to my iPhone app project, for iPad. So I duplicated the target, changed the device family to iPad, then built and ran in the simulator. The app looks good and the existing XIB seemed to adapt and look good on the iPad. However, no touches were being recognized anywhere on the screen.So then I tried simply making the existing target universal, and same deal, looks good on the iPad simulator but no touches recognized.Thinking this may be due to an oddity in this particular project, I tried these steps on a different project and same result, looks OK but no touches recognized in the simulator.These are older projects with a XIB and not a storyboard. While they look OK on the iPad, clearly something is not being properly tweaked for iPad if no touches are recognized.Anybody have any ideas? I am wondering if there are some obscure settings in the project or XIB that I need to fix, which newer Xcodes (tried 10 and 11) might be missing. It's been ages since I converted an iPhone app to universal.Unfortunately my daughter has my actual iPad and I can't test on actual hardware right now, but I have no reason to believe this is limited to the simulator. Seems more like a project/target/Xcode thing.thanks,219