Post not yet marked as solved
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!
Post not yet marked as solved
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
We have a longstanding app ("Frax") on the App Store, in an iPhone version ("Frax") and an iPad version ("Frax HD"). For years we've wanted to combine these two into a single Universal app, but there were always significant obstacles, to which we've now developed tentative but imperfect workarounds. I'm posting our scenario in hopes of finding ways to improve these workarounds before we pull the trigger.Obstacle 1: How to transfer user data from the deprecated iPad-only app to the new Universal app.Some of our users have accumulated preset libraries that approach hundreds of megabytes, some even gigabytes, which is far too large to transfer reliably via iCloud. So our tentative solution has been to create an App Group directory shared by both apps; the iPad-only app moves its presets from the local Documents folder into the App Group, where they can be seen from the Universal app. When the user eventually downloads the Universal app, the iPad-only app can safely be deleted, and the App Group directory (with all the presets) will remain intact.Question 1: If Frax HD is removed from sale, and a user hadn't yet upgraded it to the App-Group-aware version, is there still a way for them to upgrade so they can move across their presets to the Universal version?Obstacle 2: How to avoid double-charging users for switching from iPad-only to Universal.In principle, the most elegant way to accomplish this (short of fully automating it) would be to create an App Bundle comprising both apps, for the price of the iPad-only app. Then users could simply "complete the bundle", and download the Universal app for free.However, this solution runs into a Catch-22. Per Apple, App Bundles may not contain both iPhone-only and iPad-only apps, so we can't create the App Bundle before converting the iPhone version to Universal. But App Bundles ALSO cannot contain apps that have been removed from sale, so we can't create the App Bundle afterward either. My understanding is that Apple will not allow us to offer both the Universal app and the iPad-only version of the same app concurrently, and we would prefer not to do that anyway because it could cause serious confusion. We also would prefer not to artificially convert the Universal app to "freemium" and require an IAP to unlock its most basic level of functionality, because that would inconvenience and frustrate new users going forward.Our tentative workaround is simply to offer the Universal app for free for a limited period of time (a month or two), and have the iPad-only app actively prompt users to switch, showing a link to the Universal app in the App Store. We hope this will capture most active users. For stragglers, we can offer free-download tokens on a piecemeal basis. And for users who simply can't be bothered, the deprecated iPad-only app should hopefully continue to function for a few more years at least.Question 2: Is there any way to use an App Bundle in this scenario to allow Frax HD purchasers to not be charged again for Frax Universal?I'd appreciate any advice or feedback any of you might have on our scenario. Thanks for listening!
iter9_dev.