Post not yet marked as solved
In case anyone else is reading this because they are tempted to make their watch app work independently, then please think very carefully about it.
I enabled the WKRunsIndependentlyOfCompanionApp option a year or two ago because my watch app can work independently, so I figured it was worth doing. However the watch app is still best used with the iPhone app (e.g. configuration is easier on the bigger screen). As others have said, ever since I made the watch app independent then every time I release a new version I get complaints from users due to issues caused because either the iPhone app has updated and the watch app has not, or vice-versa.
The worst thing is that I can't roll that change back because of Apple's restrictions. For some reason it is a one-way change. This is why I recommend against making the watch app independent. Even if you think there is no need for a companion iPhone app now there may still be the chance that you may add one in the future (e.g. the bigger screen can be useful for configuration or analysis). So if you choose to make the watch app independent now then you may be setting yourself up for major problems in the future.
I do not understand why Apple cannot simply update both versions of the app regardless of whether the watch app is tagged as being able to work independently. Why would you want a user to have inconsistent versions? And if they can't do that then they should definitely improve the documentation for WKRunsIndependentlyOfCompanionApp. They need to make it clear that enabling that option will cause the watch app and iPhone app to get out of sync with every update, and that once you have made that change then there is no way back in future versions. At the moment that option looks innocuous but can be deadly.
Post not yet marked as solved
I gave up trying all the suggested fixes because in the end it was impossible to tell if they worked because the issue is random. So I very reluctantly made my app accept all file types. Even if Apple were to fix the problem tomorrow it would still be too late. Most people are using iOS13 now and a significantly large amount will still be using it in a year or two, so I can't see myself ever changing the app back to only accepting some file types. It is very annoying because we told Apple about the issue months before iOS 13 was released but they did nothing and now the file type system is broken for the foreseeable future.
Thanks for the analysis. Did you manage to reproduce the problem?It happens on watches without the always on display (the OP mentions the series 3) but maybe Apple have changed the logic in watchOS 6 for all watches. I didn't see the problem with the watchOS 6.0 betas though. It seemed to start with the first release version.
Thanks - I tried both with and without the always on display and it didn't make any difference.I filed a bug report a month ago and got a reply saying that "didappear and willDisappear are navigation lifecycle events. They're called once when the view is first navigated to or away from". That was it. To be honest I wasn't sure what to make of it. It seemed like they might have been saying that didAppear should no longer be called on wrist raise (which contradicts the documentation), and they didn't even mention willActivate, which is the main problem.It's not such an issue now that I have worked around it by using applicationDidBecomeActive, but it seems a major bug. However maybe it only affects some apps because it seems strange that only two of us are experiencing it.
I have worked around the bug by using applicationDidBecomeActive. In that I now use dispatch_async to call a method on the interface controller that is also called by willActivate (and contains the code that I previously had in willActivate). I only do this for watchOS 6 and when didDeactivate has not previously been called.This fixes the issues that I see with watchOS 6 that I do not see with watchOS 5, which confirms that willActivate is no longer being called in watchOS 6.
One of my users has just reported that it doesn't seem to work on the 6.1 beta 2 either. He's not a developer so cannot confim it, but he is seeing the same effects that are caused by willActivate not being called.It seems amazing that no-one else has mentioned such a major bug so maybe there is something specific about our apps. What sort of app is yours? Mine is a workout app that also uses Scene Kit to display a vector map.
Post not yet marked as solved
Thanks for that. I can't tell if it works for me yet because I wasn't having the problem - many of the users of my app were seeing it, but not me. I will use that UTI in my next beta and see what the beta testers say.
I see that the watchOS 6.1 beta 2 release notes mention this bug fix, that hopefully means that Apple have fixed the problem:Resolved IssuesView controllers receive the expected lifecycle callbacks. (55457949)
I am seeing the same thing. I had a few bugs that could only be explained by willActivate not being called, but I thought that would be impossible (thinking it would be too major a bug to not be spotted?). So I checked and it is indeed not being called on the device. It works fine on the simulator, which makes it even harder to diagnose.I tried to switch to using didAppear but that seems to not be called either. I suspect it is related to the always on screen changes, even though it also happens on older watches. That would also explain why such a major bug was not spotted during the watchOS beta as it probably wasn't in that code.
Post not yet marked as solved
The problem with knowing if any specific change fixes the problem is that just the act of installing can solve the problem. The order of installation/uninstallation seems to be a factor. I have had several users re-install other apps that register an interest in GPX files and suddenly my app appears on the share list, despite them having made no changes to it at all.I have also had users for whom it was working with iOS 13.1 but then it broke when they installed iOS 13.1.1. It seems almost random but is triggered or fixed by the installation of a new iOS, or the install or uninstall of other apps that register interest in the same file type.I am also now having problems with my workaround of showing a UIDocumentPickerViewController to allow files to be specifically imported. It seemed to work with iOS 13.0 (or at least no-one complained) but sometimes does not work since iOS 13.1 was released. Strangely it still does work for some users for whom the sharing mechanism is not working. So it helps some users but not others.I had set the document type for this import controller to be kUTTypeXML but for some people this will not allow any files to be selected for the affected users. I will try making it kUTTypeData in the next version to see if that helps, although I would prefer not to make every data file selectable.
Post not yet marked as solved
My bug report for the issue says less than 10 people have reported it, so I am wondering if Apple do not actually realise how big the problem is because their systems are not correctly detecting that multiple reports are for the same bug. I guess it can be described in many ways.Unfortunately iOS 13 is so buggy (the worst I can remember in over 10 years of iOS development) that bugs with so few reports are probably well down Apple's list of priorities.
Post not yet marked as solved
I find the same: it is related to what other apps have registed the ability to read GPX files, and to the order in which they are installed.
Post not yet marked as solved
I have heard the same from some testers so it looks like it isn't fixed. Unfortunately Feedback Assistant is constantly down so I cannot tell them!
Post not yet marked as solved
I just got an email from Apple saying that the issue is fixed in iOS13.1 beta 2, which is great but it sounds like it will be an issue for users using iOS 13. It will be interesting to see how soon after the iPhones are available that 13.1 will be available. Hopefully very soon if not immediately!"As a result of your feedback, there are software changes in build 17A5831c that have resolved this issue. Has this issue been fixed for you?"
Post not yet marked as solved
I submitted my bug report using Feedback Assistant, although I haven't been able to login to it for several days. It always seems to be down at the moment. I wonder if that is why the iOS 13 beta is so bug-ridden: because the tool for reporting bugs is rarely working.It is strange that such an obvious bug that was reported back in June hasn't been fixed in September, but maybe it isn't so obvious to Apple engineers. It seems to depend on what other apps are installed and they may do their testing on "clean" devices without other apps.
