You added support for this URL scheme which has opened up fabulous scripting options for me.
But Accordance also uses a different URL scheme that I would love to see Drafts recognizing. Currently Drafts opens it as a web-based system Accordance has, but Apple Notes, Pages, etc. support it as a URL scheme that opens directly into the app.
In case all of this is confusing (it is!), there’s a support discussion here: https://www.accordancebible.com/forums/topic/19364-url-schemes/
Drafts can open any URLs. If you place that example URL in a draft, and enable link mode, you will be able to tap on it and it will open in Safari in the app.
I am going to guess you installed this Accordance action example from the Action Directory and want it modified to work with those URLs? This is an example a user created and posted, not sure who made it to contact them about updating it. I don’t complete follow it’s usage as it’s doing some things with the clipboard.
What are you actually wanting - to lookup in Accordance the selected text?
Sorry I wasn’t clear. Actually I’m the author of that action. It’s pulling data on the line of a draft, turning it into a URL and opening directly into Accordance.
So the idea is just that Accordance has two different app specific URL schemes. Other apps including Omni outliner, for instance, will recognize the format of “accordance.bible…” as an app specific URL and open directly to Accordance instead of opening in Safari.
Currently, Drafts is not parsing it as an app specific URL (maybe because it is not whitelisted?) and opening it in Safari. If it could ever be whitelisted / recognized and open directly to Accordance the way that the accord::// scheme does or the way that Omni opens the accordance.bible format, that would just be cleaner. Does that make more sense?
In the example you showed, the new URL is an “https” URL…which should work fine. Do you have a modified version of the action that displayed the case where it’s not working?
It sounds like Accordance has setup support for Universal links, which allows http URLs to be redirected by the system to an app other than Safari, but that’s all system level stuff and should not require any changes on Drafts end if the URL is constructed properly.
accordance.bible just part of the URL in your example - are you possible constructing the URL without the
https:// at the beginning?
Maybe this will clarify it? In the linked video I’m opening the same link first in Drafts and then in Omni. The result in Omni mirrors the way these links are parsed / handled also in the Apple apps (Pages, Notes, etc)
I couldn’t get the video above to work, but I may be able to provide further clarity.
If I install the Accordance app and use your example link
https://accordance.bible/link/read/ESVS?John_3:16_, when I tap on it, it opens the link in the in-app browser and displays the web site; rather than handing off externally to the OS to handle. If I tap and hold on the link I get the menu of options. If I select “Open”, I’m guessing that this opens the link ‘externally’ at the OS rather than Drafts app level, which then picks up and processes the universal link, opening the app rather than the web site.
To me it seems like this is working correctly. All I can think that might help users in this instance who are coerced into using a universal link would be to have an option in Drafts to allow link mode links to be opened ‘externally’ to Drafts rather than internally. Apologies if such an option is already available - I couldn’t spot one.
That’s it. And yes, most of the other apps I’m using are processing it at the external, OS level (Spark, Omni, the Apple suite) which takes me directly out to Accordance instead of through Safari. Having the option to process it in iOS instead of internally in Safari would make this specific URL scheme actually useful within Drafts.
It’s okay if this isn’t an option. I can also just build a Drafts action workaround to convert it into the other style of accordance URL scheme that does work. Maybe the broader question is if this might be a parallel limitation for other users with other apps.
Some general thoughts then aside from changing the links:
- Long pressing and selecting open enables universal app links today.
- A global open internal/external option might be useful.
- Providing external opening for all universal links automatically is impractical given new ones could be added daily.
- Providing a user maintained “grey list” to open URLs for certain domains in a particular way would allow users to specify alternates to override the default open internal/external option and maintain it for their own universal links and any others they may have reason to always open externally.
Would be pretty easy to write an action that detects a URL in the current line and opens it. The
app.openURL function can be explicitly told whether to use Safari View Controller in-app or not. Attach that to a hot key - might be a good workaround for now as well.