13

Holding a list of apps that should open certain links isn't future-orientated. Instead, certain links that are obviously not meant to be opened by a web browser should trigger an option to open the link with certain apps shown in the following link:

https://apple.stackexchange.com/questions/430158/how-do-i-control-where-links-open-on-ios

Provide an option to open a link in an external app, then you ask for the standard behavior.

At least to me, that option makes much more sense, but hey, if it is only me, it isn't that important.

  • Vlad replied to this.
    Merged 1 post from Add Vodafone to list of supported app links.

      LAJVXO Moving this here.

      Hoping to understand the mechanism that allows Safari to open this and that fails in Orion.

          Please check this page:

          https://developer.apple.com/documentation/xcode/defining-a-custom-url-scheme-for-your-app

          As far as I understand dedicated apps register their url scheme. Any other app can just naively try to open a url inside itself, like Orion does it at the moment. Or it triggers opening the app that has registered a certain url scheme.

          There are two options as far as I can tell.

          1. provide an option, long press or whatever, to open an external app when clicking an URL. Also ask to save the behavior for future click on such URLs.

          2. Check if there is an URL scheme registered for a certain app in case Orion can‘t open it. Or something similar.

          I didn’t dive deeply into the matter as of now but I never ran into an issue using the Brave browser for example.

          I‘m quite sure that holding a list of external applications inside Orion, maintained by Orion isn’t the right way to go.

          If I should dive deeper, please let me know.

          • Vlad replied to this.

            rosenrot I am assuming part of the problem is that many apps dont register this URL which made the need for a paid app like Opener?

                Not sure about that. As I said, I never had any problem with Brave with the app to be opened I refer to.

                Also I never had an issue with Safari. The other guy here also refers to the fact that Safari works for him.

                As far as I can tell the problem is that Orion naively opens any URL by itself without checking or providing the possibility to open the URL externally.

                Don’t you think? Otherwise Orion would just perform as well as Safari or Brave do and no one here would raise an issue. I didn’t use any paid app so far.

                • Vlad replied to this.

                  https://developer.apple.com/documentation/uikit/uiapplication/1622952-canopenurl

                  This is a function exactly made for checking iOS if a URL scheme is registered for a certain URL scheme.

                  The three options as mentioned before would be:

                  1. trigger this option every time a URL is clicked. I don‘t know if this causes any performance issue or what it causes to happen in case it is a http URL and would report Orion itself or any other browser or the standard browser.

                  2. In case a URL doesn’t open in Orion try to run this function

                  3. Long click a URL and add the possiblity to „open externally…“ with the possiblity to store the behaviour

                  Possibly there are even better implementations.

                    As an example:

                    open „sms://“ in Safari. It asks you to open Messages as sms is a registered URL scheme.

                    Orion doesn‘t do that.

                    This is where the rabbit is burrowed I guess.

                      rosenrot Thanks. How do you explain a paid app like Opener being so popular if there is no problem that it is solving?

                          Vlad I would say the app addresses a possible „missing feature“ of IOS, which is that if multiple apps listen for the same URL scheme, it opens just one of them without providing a choice. Opener gives them a choice, not by allowing different apps to listen to the same URL scheme as this would create chaos in other apps if they would do, but by transforming URLs to different apps URL schemes like to make it valuable for Twitter and Tweetbot which share a similar purpose. Both apps handle the same content but the URL scheme is different: twitter://… and tweetbot://…, however not knowing details, it makes sense for some power users to open a tweet once in the Twitter and another time in the Tweetbot app.

                          Which I don’t see a usecase for to be honest.

                          If Orion would just ask to open an URL with an external app, if the URL scheme is registered, I‘m more than happy.

                          You can even do it better than Safari which just asks yes or cancel and if you hit cancel it doesn’t do anything. I like your current user prompt because sometimes it makes sense to open links in the browser directly and sometimes it is only possible open it with other apps.

                          • Vlad replied to this.

                              rosenrot This was a long thread and you seem to have a point.

                              I am going to ask you to list steps you would like Orion to undertake from its current state to this new state, making it a specification. Also power user case, which caused us having this feature built in the first place needs to be satisfied. Be as detailed as you can explaining UI/UX options along the way.

                                  Vlad So let me think...

                                  This use case A combines the regular user and the power user in case there is a URL registered:

                                  1. Click on any link that has a registered URL scheme (as this indicates there is a dedicated app for this link).
                                  2. Orion pops up this user input; the user can select what he wants.
                                    2a. Selecting if he wants his choice to be remembered.
                                    2b. The app list holds first the registered app and follows the list of apps that can open such a link by link manipulation (e.g., change twitter:// to tweetbot:// - comes from the Orion-supported apps list).
                                    2c. The Orion should show as a separate app that allows opening the link within the browser itself.

                                  In case there is no registered URL scheme (use case B), but there is an app in the Orion-supported app list that would allow for link manipulation (e.g. twitter:// to tweetbot:// but twitter:// is not registered as the app is not installed):

                                  1. Follow use case A but don't show the Twitter app on top of the list.

                                  On long press on a link, there should be "Open In" shown as an additional option (otherwise grayed out) to change the behavior if

                                  1. "Remember my Choice" was set previously as this allows you to change your preset.
                                  2. An app was installed that registered an URL scheme.
                                  3. Another app was listed on the Orion-supported apps list.

                                  Additionally, universal links should be treated the same way as URL schemes. Universal links should lead to even better user experience and this is completely alright. However, it could become annoying to non-average users. This is where the above described UI/UX options are coming in. The user can freely decide if she/he would like to be a average user or not by simply selecting what she/he wants. The first app in the "Open In list" is mimicing the average user choice. Non-average users might be disturbed as universal links open external applications while in private browsing mode. We had this discussion over here: https://orionfeedback.org/d/3832-ask-user-to-open-link-in-associated-app-during-private-browsing/7

                                  Here is more information about universal links:

                                  It seems that universal links, the way service providers can tell which app can use their links, is exactly what the Orion-support app list is, just provided by the service providers themselves. The Orion-supported apps list adds freedom as the service providers prefer their apps to be used.

                                  I would say that's it. I'm, of course, open to comments.

                                      rosenrot Thanks for the extensive write-up and mock-ups. This is exactly how I would love Orion to work with links. It would give Orion a big advantage over all the other iOS/macOS browsers. Thanks for giving this the 'planned' tag @Vlad. Looking forward to it.

                                          janpeeters Thank you for confirming that these mock-ups make sense. I'm entirely with you that it makes a difference compared to most other available browsers, especially on iOS.

                                          Also, I believe this feature is not getting the attention it deserves right now as most users found their workarounds or think it can't be done as it isn't available in any other browser. Once it is implemented, it won't take long until other browsers mimic it.

                                          • Vlad replied to this.

                                              rosenrot This thoughtful contribution just granted you the Contributor status.

                                                8 days later

                                                Hello @rosenrot & @janpeeters,

                                                I'm nano, Orion iOS engineer. I'm working on this feature and I wanted to confirm that I understand the general flow for this feature. I'm attaching a flow chart showing the possible paths the app can take when you either tap a link, or long-press a link to show the contextual menu. Please let me know if this is the expected behavior, and if not, where it should be different.

                                                Additionally, @rosenrot, you mentioned not having this problem when using Brave. Would you mind sharing a test-case website that has links which show your desired behavior? It could help me see what the end-user experience could be. Thanks!

                                                  nanoscrew Thanks for reaching out. Before going into details, let me quickly comment on the flow chart.

                                                  In general, it would be great if the user could decide if she/he wants to open links externally, independent if it is an url scheme, url built-in, or a universal link. I think the flow chart doesn't address that wish, does it? I would like to see the "Open in..." popup in any case, url scheme, app listed in built-in list of apps, universal links. From my perspective there is no need for the confirmation alert.

                                                  What alerts me is your note. For me, this means that we can't rely on the registered url schemes. In case I would click on 50 (different) links not being https/http the Orion browser would from that moment on always get a "No" for new urls. So both cases "tap link" and long-press link" would return "No" at the first branch. Am I correct?

                                                  If I'm correct and having in mind that Apple suggests moving from url schemes to universal links, we might go in a slightly different direction - completely ignoring url schemes. I would be happy to hear your thoughts nanoscrew janpeeters .