User Profile

My app Frax makes use of custom URL schemes to share presets via custom URL scheme links. This is done by sharing normal URLs, e.g. fr.ax/fe0ci, which our server then redirects to the custom URL scheme link; e.g. fraxhd://fr.ax/fe0ci.frx . This link opens in our app and tells it where to find the preset file (in this case, fr.ax/fe0ci.frx).This worked fine in iOS 12 and earlier (all the way back to iOS 3), and in all other apps we've tried it with (e.g. Facebook). However, it is broken in iOS 13 Safari. The server attempts to redirect to the custom URL scheme link, but our app is never called or opened. The links still work fine from other apps (e.g. Facebook), and also when the custom URL scheme is pasted by hand into Safari. Only the server-based redirect mechanism has stopped working, and only in Safari.Any idea why this might be, or what changed from Safari iOS 12 to Safari iOS 13, or how I might go about troubleshooting it? Thanks in advance!

For the past several weeks I've been dealing with a maddening CoreData issue, which feels like an Xcode bug. (Currently on Xcode 10.2.1, running iOS 12.3.1 on my devices.)I have a large project using CoreData with several model versions, using lightweight migration. The latest is version 6, which adds an NSData attribute 'foo' to the managed object. The app creates and persistently stores and manages databases in this format.However, once in a while the app will build and launch and throw an exception saying that 'foo' is an unrecognized selector, and crash. (As if it were built using an older model version.) Worse, when this happens it corrupts the CoreData store, deleting all 'foo' attributes. To get the app to stop crashing, I've found that I can simply toggle the 'Current Model Version' in Xcode from 6 to 5 (without rebuilding) and back to 6, then rebuild and relaunch, and it works correctly, except that the previous 'foo' attributes stay deleted. Obviously, it would be very bad if a build affected by this bug were to be released on the App Store, since it would destroy a ton of user data.I am sort of at a loss for how to troubleshoot/fix this. I'd like to be able to check for this condition at startup before the database is loaded, but CoreData classes don't work with 'instancesRespondToSelector' (because the selectors are created dynamically). If I wait until the model is loaded before checking (e.g. by triggering the exception and catching it), it will corrupt the database. And it seems pretty heavy-handed to create a dummy database each time I launch, just in order to check for this bug.Any help is welcome. This is the first time in years that I've considered opening a Technical Support Incident!Thanks,Ben