Creating a real Alfred iOS app (not Remote)

[nikivi]

I've been thinking about this idea more and more and recently I think I found a usable interface in which you can use the full power of Alfred in iOS.

 

My problem lies in that a vast majority of my workflow around using my mac relies on the Alfred launcher. There are many workflows I use and I try to use Alfred launcher as interface for everything that is searchable.

 

This brings a huge issue in that, all this power in terms of workflows does not translate at all to iOS. Specifically I want to use my Web Searches workflow inside iOS. I want to fuzzy search for a website to search on and make my search. There is nothing like that on iOS that does it. Sure, you can probably make an iOS app that does this and release it but why make an entire app around this one feature. Or take @deanishe incredible Searchio workflow. It would be amazing to have a way to make a search with suggestions from an iOS device. Not only ones that are preconfigured as default search in Safari. Again you can probably make an entire iOS app that wraps Searchio capabilities and release it.

 

I think though that you can realistically make an iOS Alfred client that can use Alfred workflows you can use on mac. Or even make dedicated iOS Alfred workflows that you can then test out on mac and use from iOS. All you really need in the iOS app is ability to use the workflows you make and have the ability to call these workflows via external triggers which in iOS land can be used from url schemes. It can use the same format as Alfred uses. The JSON schema for script filters and some objects should be transferrable. i.e. Open URL object can instead of opening URLs in mac browser, open the URL in Safari iOS browser. The script filters can be dumbed down to only include the return action. No modifiers as you can't use them on iOS. 

 

And then you can either use these iOS Alfred workflows from Alfred app itself where the interface can be designed to achieve this calling of any Alfred workflow in your iOS Workflow library with ease or you can provide external triggers to these workflows with URL schemes (similar to external triggers). This way you can call the workflows through something like Launch Centre Pro and the workflow will open to be operated from Alfred.

 

The using of workflows should be simple. I am thinking of a simple search bar on top that gets activated as you enter the workflow. And then as you type, suggestions you programmed to show will show. In case of my Web Searches workflow, it would be nice to have a similar ability to control the flow from one script filter to another. Although of course not as complex as mac's. For example I would love to use Alfred My Mind from iOS. This workflow is really simple in that it is one script filter that lists my bookmarks which on return will open in the browser. One can imagine an iOS app that can achieve this simple task. A search bar on top that searches through a list of items (Alfred JSON schema) and on return does the action of opening the URL in browser.

 

I can give some design mockups on how I envision the app to look that I can make in Sketch. I can also offer my help to make the actual iOS app that provides these features as I believe @Andrew is really busy with making the mac Alfred app the best it can be. I genuinely think that if implemented well, this would be incredibly valuable as it will bring at least partly the power that the mac platform has and bring that power to iOS. 

 

I do everything through Alfred interface and I really need the ability to translate this Alfred world and use it from iOS. I hope I am not alone in feeling this way. I am very eager to help make this happen and can offer any help needed to bring this to life.

Edited January 9, 2018 by nikivi

[vitor]

Respectfully, you present a lot of pie in the sky ideas but address none of the myriad of very real and very big constraints. Just a handful:

•  You cannot use your Alfred Mac Workflows on iOS because iOS does not have the tools. iOS does not bundle Bash, or Python, or Ruby, or …, for you to call.
•  Apple’s relationship with automation on iOS is finicky at best. Launch Center Pro itself has been crippled in the past
•  Part of Alfred’s appeal is that it’s always there. On iOS that is not possible.
•  Calling an interface you have to type on is considerably worse (slower and more cumbersome) on iOS. That’s likely a reason why Alfred Remote does not follow that pattern.
•  Workflow, which Apple owns, is the best anyone could come up with yet that is accessible to any user and got popular and Apple allows. And since they have that rule they selectively apply about not allowing apps that duplicate functionality of their own apps, that makes bets on similar apps a lot worse.

I could come up with more, but any one of those is enough to give pause to the idea. Heck, the first one alone outright kills it.

Edited January 9, 2018 by vitor

[nikivi]

2 hours ago, vitor said:

You cannot use your Alfred Mac Workflows on iOS because iOS does not have the tools. iOS does not bundle Bash, or Python, or Ruby, or …, for you to call.

 

For this point, perhaps you can run binaries created with Swift or Go to mitigate this issue?

 

2 hours ago, vitor said:

Part of Alfred’s appeal is that it’s always there. On iOS that is not possible

 

True. But it is still better than what Apple provides. A single Spotlight search that searches everything and is not programmable.

 

2 hours ago, vitor said:

Calling an interface you have to type on is considerably worse (slower and more cumbersome) on iOS. That’s likely a reason why Alfred Remote does not follow that pattern

 

Also true. But it would still be better than nothing. There are many Alfred workflows I use that I would love to use from iOS. My own web searches workflow and my mind workflows are two prime examples but there is many more. In fact it would be quite amazing to see some innovation come in regards to making workflows that actually use some iOS APIs. Like searching currently open Safari tabs in iOS Safari (ala Safari Assistant). 

 

The way I envision the app will work and feel would actually make the app top 3 of my most used apps so it would sit right at my dock. My dream for iOS would be an easily accessible interface of Launch Centre Pro (where you have 200+ actionable buttons accessible with < 2 taps where the buttons activate alfred workflows or Workflow's app actions (this one is already possible with URL schemes)).

 

The Alfred app itself as I see it simply needs to have a search bar on top. You type things. Suggestions you programmed to show, show and you can action on them to do things. Open URLs, go places in iOS perhaps and more.

 

Alfred app should then allow to somehow allow users to write the programs (workflows). Transfer them to iOS Alfred app and then users can run them from there. 

 

2 hours ago, vitor said:

 Workflow, which Apple owns, is the best anyone could come up with yet that is accessible to any user and got popular and Apple allows. And since they have that rule they selectively apply about not allowing apps that duplicate functionality of their own apps, that makes bets on similar apps a lot worse.

 

The Alfred iOS app I am thinking of pays only small resemblance to workflow iOS app. Alfred iOS app should only provide the means to do specific programmable searches where you can transfer workflows made on mac to iOS. In fact it would be quite cool to combine Workflow's sophisticated and less sophisticated actions and treat them as building blocks for workflows. For example make a workflow to present some results where some items from results will activate Workflow macros via URL Schemes. The big point here is that you can make iOS Alfred workflows on your mac and then simply transfer them to iOS. And that would make developing iOS workflows quite enjoyable. Thus Alfred app will simply act as a way to run these iOS workflows via a similar to Launch Centre pro interface. 

 

In my mind this all looks reasonable to do and would be a killer app for iOS if done well. Aside from restrictions of only running compiled workflows, I think this should work. But also I believe there are apps like Pythonista that probably bundle a python interpreter with app. Perhaps Alfred can do the same with ruby and python to run scripted language workflows too.

Edited January 9, 2018 by nikivi

[vitor]

20 minutes ago, nikivi said:

For this point, perhaps you can run binaries created with Swift or Go to mitigate this issue?

 

Right off the bat that cuts a huge chunk of the usefulness of Alfred, by limiting languages. Apple wouldn’t allow you to anyway, judging from their history. Running random binaries a user can load is an accident waiting to happen. Also, just because it’s compiled doesn’t mean it can automatically run everywhere.

Again, dead idea. At that point might as well stick with Workflow or use Pythonista.

 

26 minutes ago, nikivi said:

But it is still better than what Apple provides. A single Spotlight search that searches everything and is not programmable.

 

Arguably. If one of the major appeals of Alfred is that it’s present anywhere and you take that way, by definition you just lost a major selling point.

 

30 minutes ago, nikivi said:

But it would still be better than nothing.

 

Again, arguably. A bad app is not better than no app. You of all people, who are obsessed (I say this positively) with configuring everything your way should be able to see that.

The rest of that section is just dreaming again, and it does not offer any solutions.

 

34 minutes ago, nikivi said:

In my mind this all looks reasonable to do

 

It isn’t.

 

35 minutes ago, nikivi said:

and would be a killer app for iOS if done well

 

It would be a killer app for you. Considering the state of the App Store for independent developers, all statistics are against you. The truth is the app would likely not be profitable.

Might as well make Alfred Remote for Android or Alfred for Windows. Those are also not viable at the moment (there are threads on these forums on that) and some of the reasons overlap. However, I believe both of those would be astronomically more viable than your current proposal.

 

35 minutes ago, nikivi said:

Aside from restrictions of only running compiled workflows

 

Which is a huge restriction, as stated before.

 

36 minutes ago, nikivi said:

Perhaps Alfred can do the same with ruby and python to run scripted language workflows too.

 

And you’re not taking into consideration the monster size this app this would be nor the amount of bug reports and 1-star reviews due to incompatibilities in versions, and the like.

What you should realise is you are not asking for Alfred on iOS. You are asking for an automation tool on iOS, and happen to be familiar with Alfred on macOS. What you want from Alfred can’t be ported for both technical and political (Apple’s decisions) reasons and your proposed alternatives describe something entirely different.

 

Before Alfred’s team can build your vision, Apple has to change theirs.

[deanishe]

27 minutes ago, nikivi said:

you can run binaries created with Swift or Go to mitigate this issue?

 

That’s not mitigation, that’s re-writing almost everything.

 

29 minutes ago, nikivi said:

use some iOS APIs. Like searching currently open Safari tabs in iOS Safari

 

You appear to have a profound misunderstanding of which APIs are available on iOS. You absolutely cannot get at another app’s data (unless you wrote it) except via whichever x-callback-url API (if any) it supports.

 

33 minutes ago, nikivi said:

apps like Pythonista that probably bundle a python interpreter with app.

 

This is the app you should be looking at, tbh. It not only contains a full Python interpreter,  but also provides an x-callback-url API to run your Python scripts and a rudimentary GUI library to give them interfaces.

 

36 minutes ago, nikivi said:

Perhaps Alfred can do the same with ruby and python to run scripted language workflows

 

Pythonista is already 500MB thanks to including enough Python to be useful. It’d be twice the size if it contained Ruby as well.

 

It’s also worth bearing in mind that Apple forbids apps that download and run code (unless it runs on iOS’s own JS engine—that’s why Chrome on iOS uses WebKit, not Blink). So, a program that downloads and runs workflows that contain code is very likely to be rejected.

[deanishe]

Now that I think on it, why don’t you try to get a few workflows running under Pythonista? As a proof of concept.

 

With many workflows based on Alfred-Workflow, you’d “just” have to change the library functions that return paths and change Workflow3.send_feedback() to generate a Pythonista GUI instead of Alfred JSON.

 

Searchio!, for example, also contains a Python version of the search runner, and only needs a Script Filter and an Open URL action for its core execution path. Most command-line commands map closely to function calls internally. 

Edited January 9, 2018 by deanishe

[nikivi]

1 hour ago, deanishe said:

Now that I think on it, why don’t you try to get a few workflows running under Pythonista? As a proof of concept.

 

Will give it a go. Haven't used the app in years. Nor am I any good in Python or the coding part. But will try. ? 

 

If this actually works and would let me transfer some of my favourite workflows to iOS, I would be really happy. 

Edited January 9, 2018 by nikivi

[nikivi]

But now that I think of it, I can also potentially make a few web pages that would serve the same purpose as I outlined above. A simple search bar with programmable suggestions. I can open web pages quickly from Launch Centre Pro and then do my thing on the web page. Will give that a go I think, I think it can host these web workflows  under GitHub pages too so all is free. Plus I can potentially use some other cool features web stack provides.

 

Will try to port my Web Searches workflow first. Although I really hate having to rewrite my Go code logic in Javascript even if it's not as much. Maybe I can use this and have my Alfred Workflows I write in Go have a very easy web partner to go with the workflow so I can use it from iOS or other devices. Holy shit, why haven't I thought of this before. I really like this idea. ✨

Edited January 9, 2018 by nikivi

[nikivi]

The goal is to try to make a library or something that would make the transition of my Alfred workflow Go code to the web as painless and easy as possible. So I can write for both platforms in a way.

 

This of course only applies to workflows that actually need an iOS counterpart.

[deanishe]

10 minutes ago, nikivi said:

Maybe I can use this and have my Alfred Workflows I write in Go have a very easy web partner

 

I think you’ve got that completely arse about tit, to be honest. Think about it. In web terms, Alfred is the frontend and your workflow is the backend. Translating your backend to JS doesn’t gain you anything: Go is a better backend language and you still have no frontend.

 

You'd be better off adding an HTTP endpoint to your workflow with Go’s built-in webserver and writing a simple JS frontend that understands Alfred JSON.

 

Perhaps take a look at my Google Calendar workflow. That has a built-in webserver for showing Quicklook previews of events (and is written in Go). Adapting it to your own needs should mostly consist of deleting the code that automatically stops it after it hasn’t received any requests for 60 seconds.

[nikivi]

 

9 minutes ago, deanishe said:

You'd be better off adding an HTTP endpoint to your workflow with Go’s built-in webserver and writing a simple JS frontend that understands Alfred JSON.

 

This makes perfect sense indeed. 

 

9 minutes ago, deanishe said:

Perhaps take a look at my Google Calendar workflow. That has a built-in webserver for showing Quicklook previews of events (and is written in Go).

 

I will give it a look. Thank you.

 

I think I have an understanding of how I can make this work.

Edited January 9, 2018 by nikivi

[deanishe]

39 minutes ago, nikivi said:

I think I have an understanding of how I can make this work.

 

You do realise that using the webserver without issues requires understanding goroutines, and therefore threads, right?

[nikivi]

4 minutes ago, deanishe said:

You do realise that using the webserver without issues requires understanding goroutines, and therefore threads, right?

 

I do. There are places people wrote about how to use them in Go. Will read that and try.

[deanishe]

The main thing to understand is don't touch any shared data from a different goroutine (thread) without putting a lock around access. If you follow that rule, you're golden.

Edited January 9, 2018 by deanishe

[dfay]

By far the easiest way to address this is to write all your Alfred workflows in python and port them to Editorial and/or Pythonista on iOS.  And/or Drafts & Workflow.