During some mailing list discussions about devices with low flash space, someone mentioned mobile apps.
I did some google searching and I found https://www.instructables.com/id/AndroidiOS-App-to-Access-Your-OpenWrt-Router-Remot/ which details how to make such application with Blynk
I'm posting this as a resource for people that might be interested.
Very cool! Would be neat if someone turned this into an official downloadable app.
I still haven't seen any apps made
I wonder what do people need in an app that is not already available in the web interface, or could be added to the current web interface easier than to an app... but I guess everyone has their own needs.
working with the web interface is harder than making an app, and might be useful for low-flash/ram devices where you can't use a web interface anymore.
It can be used to control custom applications too (i.e. the OpenWrt device is running some other custom application to do something, and you control that with the app, similarly to what an IoT device would do)
but yeah, this is a niche thing, not a "must have".
Furthermore, an App is more feasible than a web interface in a browser on mobile devices.
Not really, the problem is with how the web interface is made, many apps are in fact a web application running on the onboard browser.
I meant that it's harder to develop things for Luci than make an Android/iOS app with an easy app framework like that.
Afaik if you use the "Material" theme for Luci, the web interface should be much more usable on mobile devices too. But it's not a light package so it won't be installed by default.
I understand your point, but those browser-based apps are closer to a native app than going into the browser.
No, not really. This type of "browser-based app" is just a wrapper around a web application.
It is executed inside the browser just like a complex website would (think of youtube or even this forum, all the animations and interface and editors to post and edit are web application code executed in the browser).
The "app" simply loads the web application from a local folder in the smartphone so it does not need to ask the device to send this with a web server.
This can be done on PC too, that's what Electron-based applications do, you build a web application and bundle it with a Chrome browser engine to make it run on its own. https://www.electronjs.org/
So in case for an app you only need the web application backend (the application the app talks to) in the device, instead of bundling a web server, the web application and the backend inside each device.
That's what I mean. Create an Electron-style App instead of using a browser to enter LuCI.
It's just a bad idea, a distraction at best.
I've been playing with networking devices for quite a while now, both highend business gear with its own windows configuration tool and, contemporary highend consumer devices which really emphasize the android/ iOS app idea and quite a lot of inbetween[0]… Aside from the highend business gear[1], the provided tools have never really been full featured[2], despite having a much narrower focus than OpenWrt, so they have always been a dumbed down selection of basic configuration options.
Now, what would you actually win with such a smartphone app?
The way I understand the question under discussion however would be a nightmare for me personally. Leaving aside the questions of how to (ever-) make such an application feature equivalent to the webinterface or how to allow external contributors to allow development of new functionality and features, having to write an 'app' would mean doing everything at least three times, once for the webinterface, once for android (and there is android/ ARMv6. android ARMv7, android ARMv8, android/ x86_64, android/ mips), once for iOS, immediately trippling the development efforts (as they won't share a lot of code).
But the suddenly much higher development efforts aren't about my nightmares - my nightmares are about interoperability. As mentioned before, I've been playing with a wide spectrum of networking devices for over 3 decades now, I've seen standards come and go. My memories of ISDN pbx systems requiring RS-232C connections and DOS configuration tools aren't too fond, neither those ISDN pbx systems that were USB based, but whose tools only worked on Windows XP-SP2. Or the switches that hard-depend on JAVA JRE1.2 or MS ie 5.5. Some of these still cross my path today, way past their experation date - and it's not funny to keep virtual machines with ancient software at hand, nor to keep using notebooks with native (USB emulation isn't good enough) RS-232C interfaces at hand. I don't even want to be remembered about Windows CE or Windows mobile/ Windows RT (ARM). Especially 'invisible' infrastructure devices have a tendency to stick around for a long time, it is an advantage if those can be configured by a 10-year-old notebook with an equally ancient browser just as well as with the zPhone XXX from the year 2033, ~if man is still alive, if woman can survive, they may thrive~.
Yes, a webinterface might not be as hip or sexy as native smartphone app, but do you really need[4] a self-concious, cloud backed[5] smartphone app, which live tweets how bored it is?
--
[0] Neither of these can really do without a webfrontend completely, even if the primary focus is on their vendor based tools.
[1] where the alternative webinterface was really something to 'get used to', albeit technically full featured; contemplated with proprietary ssh/ telnet shells.
[2] OpenWrt comes with a lot of luci apps, plugins which hook into the common core without having to be officially blessed, adding features that would never be part of any smartphone app.
[3] well, at least if you concentrate on a single smartphone eco-system.
[4] or want?!
[5] quick, need to add a.i. acceleration and blockchains somehow
…and now get off my lawn, young whipper snapper. Back in my day, we walked uphill, both ways, in the snow to school - and we were happy with it 
With all of the exposure I've had with computers and anything IT/tech related I will admit I do like GUI's. However, over the last few years I've started not shying away from CLI understanding Unix commands and how everything works. Sadly there isn't a GUI for absolutely everything in OpenWrt which I wish there was. If there was a LuCI app for everything I think a lot more people would move over to OpenWrt. User management for use with Samba and an FTP server and a device map to show all of the interfaces and devices connected to what are a few examples.
In regards to an app I think we could benefit from it. I have tried almost all of the themes and tried to view them on my mobile phone. The bootstrap works the best most of the time but some of the pages I have to flip my phone landscape to be able to see everything properly. System > Startup and Network > Switch are two examples.
The beauty of an app is being able to redesign the navigation aspect so it makes getting around the GUI of the router easier. For example pulling the screen from the left could show a menu, a floating bottom could bring up a popup window, realtime graphs of network activity could be on its own screen and quick toggle buttons that restart services, turn the WiFi on/off or re-enable a network share.
Gosh if I could code both an app and make LuCI apps for the web GUI I would devote time to improving OpenWrt especially from a graphical point. I have so many ideas but I think some of them are just dreams.
You could argue at the end of the day OpenWrt in an embedded Linux system and for anyone to use OpenWrt they must understand Unix to some degree. I got into OpenWrt at Chaos Calmer 15.05 and had little to no experience with Unix or Linux, and therefore I heavily relied on the GUI. My point is, with more powerful OpenWrt capable devices becoming more popular, what's stopping us from creating LuCI apps and smartphone apps for this brilliant open-source firmware?
I'm not saying move entirely away from CLI because it will be still needed for a lot of things, but making almost everything with a GUI to configure the back-end is a lot more desirable in many people's eyes. What has already been done with LuCI should be ported into an app but just laid out differently so that images, tables and the elements scale up and display correctly.
Network tools could be interested into the app as well. Sometimes when I'm away from the PC and the web GUI won't show some information I'm after, I've had to SSH into the router via an app which is quite clunky without a proper keyboard. An app with tools to run as though you're on the router would be amazing.
You didn't even look at the article, didn't you?
We can talk about that when coding applications for Luci isn't a massive PITA. Anyone can make a smartphone app with that framework.
Really, any half-decent app framework is many orders of magnitude larger than the whole router's firmware, but it is massively easier to use.
how to (ever-) make such an application feature equivalent to the webinterface
It's a piece of cake to do that
That app is basically connected through SSH and sending console commands directly instead of doing stuff with arcane javascript on the client or an isolated Lua backend.
If you can CLI it, you can do it with that app. As simple as that. It's using Lua, but it has full console access, you aren't limited to a safe web interface interaction so you can send data back and forth much more easily.
You can offload a lot of things to the client too as it has libraries and pre-made functionality. Ever tried to place buttons or graphs in Luci? It's extremely stiff and does not allow you to do much more than a few predefined things (also no graphs, it's just posting images generated by something else and looks bad)
Really, writing a decent luci support application for something that isn't basic "select options and compile this UCI file" or some other basic use like that is a huge pain because you need to make it all from scratch.
Which is why for example the OpenVPN Luci app isn't inter-operable with a CLI OpenVPN setup and is instead doing its own thing.
And I know what I'm talking about.
I tried making some form of disk management application with Luci, but it's a huge pain in the ass, so I just dropped the project, and kept using Armbian or OpenSUSE on all devices where I need something more than basic routing/VPN functionality.
Indeed, I didn't - because it doesn't affect my arguments in the slightest (aside from triplicating the workload) how nice the framework is. Writing an interface involves two major components, the presentation (this is what your framework might make easier, you still need to design an ergonomic UI, which is not trivial) and the 'business' logic behind it - and this requires the very same efforts, regardless of you're doing it for the webinterface or a smartphone app.
Starting an app is easy, if you don't care about parsing, representing and editing existing state and don't do any input sanitation or validation, but neither of this is possible. Luci doesn't really do anything but calling uci either (in your terms, yes using a tiny abstraction layer - but that neither complicates it, nor do you have to use it), but it does have to parse the existing config, check the options and validate the input.
Just a simple example, wireless setups:
Either of these have different requirements in terms of key length and format (IEEE802.1X is another can of beans alltogether) - and yes, you do need to validate the input in the frontend. The uci backend structurally is more or less merely a variable/ value store and doesn't reject invalid input, if you do accept broken input you'd at least make the service you're going to configure fail to start (or misbehave in more subtle ways) - and open the door to Lil' Bobby Tables. So even if your framework would make writing interfaces a piece of cake, you can't avoid the heavy lifting between UI and committing values to uci - that where blood sweat and tears are hiding, where you really triplicate the efforts.
A real (respectively 'good') OpenVPN luci app isn't in existance because lua or html/ javascript would pose a problem, but because you'd have to deal with a rather free-form syntax of configuration options and even more difficulties in terms of cert handling - namely the parsing of existing- and validating of new configuration options. Yes, OpenVPN's config syntax isn't really free-form, but it has a rather large vocabulary with peculiar semantics, even for the common tasks. Of course this is solvable, but in order to do so, you'd re-create quite a bit of OpenVPN's input checking --> a lot of work.
Then there's the other issue, config options evolve…
How do you use your new-fangled smartphone app both with 19.07 and 12.09 (just taking these as examples, obviously this would only apply to future versions - but the issue remains, app and running OpenWrt version aren't necessarily in sync), how will your device running 18.06.0 react if you upload a WPA3 based config (not well, hostapd will fail to start up). With a webfrontend, running firmware and frontend can't get out of sync pretty much by definition, as long as it remains compatible to your web browser (not guaranteed, welcome ie5/ jscript, but hey, a lot more likely than smartphone apps).
Of course all of this can be solved, but just not easily.
You didn't read my post either. It's just establishing a secure channel and sending over console commands, so whatever can be done with console it can be done by the app.
Any decent app framework has multiple MB of libraries for parsing strings and stuff. You think everyone in the modern world rewrites basic parsing functions every time?
Yes, it's validating the input. Something the app isn't doing. If you don't care about validating the input because you are trusting the source with a token already and you are using a secure ssh you can do without a lot of complexity.
No you don't. This is not a public interface anymore, you can't connect to the device without manually exchanging the token first.
This allows to not waste time to defend against malicious attacks, and just do basic validation for lenght or available options.
The same way you use Luci both with 19.07 and 12.09, you update what changed?
Actually the CLI is more stable interface than luci, that is in the process of being migrated.
schema = validation and field generation 2 birds one stone...
That, I did. You can feed uci any garbage, it will take it without complaints, but the procd scripts and daemons will fail to start - too late for your fancy app to notice, too complex for it to fix it up. uci doesn't prevent you from entering a 65 character long wpa2psk, that's what the frontend needs to do. Neither does it help against Bobby Tables, another validation task for the frontend.
Again, I'm not at all saying that refactoring all this into a new backend or middle layer wouldn't be possible (actually rpcd and ACL already lay some groundwork into that direction), but doing so would require serious efforts - and all of that in triplicate. But hey, no one prevents you from trying, if it's all that simple and will magically recruit hordes of new contributors (that still doesn't solve the question in which way it would actually improve the user experience, but, hey, magic).
You do not need to convince anyone about all the good things that an app would bring, you do need any autorización to sit down and start coding.
Just because some people do not see it as an improvement, it does not mean it isn't an improvement for others. If people see it as a good thing, they will install and use the app, and probably will even join and start coding, too.
Checking the length of a string or if it contains non-ascii chars is a non-issue in any language, even shell. So I'm not sure why the app should fail to notice that.
The complex part of sanitization is avoiding code injection (the real name of the "bobby tables" issue), and that's what most apps using tokens do not usually need to care about.
Luci interface under the hood is klunky and hard to develop for (or even theme, check older threads were this was discussed) because it is designed to avoid code injection, so I can't just send up and down data and direct shell commands, but it has to use pre-defined interfaces and have a backend and whatnot, and this limits A LOT what you can do.
I'm just reacting to people that don't understand the difference between a public web interface and an app that is sending shell commands over a secure channel, and post misinformation with an "I'm the expert" attitude.
Note how for slh apps are UNVERSALLY worse. No exceptions. He didn't even read how that framework works, and reacted with multiple paragraphs of uninformed assumptions that are completely irrelevant for how such framework works.
I don't need any authorization to disagree with someone in a forum either.
The fact that I don't personally need either an app or even a web interface is tangential.
How foolish and bitter this guy is.