4

Imagine that I've got a piece of custom audio hardware that I'd like to be able to control in a multitude of ways via a tablet/touchscreen GUI. In particular, my goals are to have the tablet's control GUI be "pretty" (i.e. nicely animated and modern looking, as one would expect from an iPad), have it be cross-platform (i.e. the same codebase can be run on iOS, Android, and/or on a desktop computer and behave roughly the same on each), and also make the app's run-time behavior as generic/flexible as possible.

Since the server hardware can do so many different things, I think it would be useful if I could avoid having to hard-code any particular GUI functionality into the tablet's app, except for the ability to discover and connect to the server hardware, and then download the appropriate QML file(s) and JavaScript and execute it, and have the QML and JavaScript execute to set up an appropriately customized GUI for that tablet on that server. That way the user isn't constantly forced to upgrade the client-app on each of his tablets every time new features or behaviors are added to the server (and I'm not forced to constantly push updates to both the iOS and Android app stores).

That approach seems like it would technically work, except I'm worried that Apple wouldn't allow such an app onto the Mac app store, due to their rule forbidding downloaded interpreted code. I'd hate to got to a lot of trouble designing and implementing this approach, only to find out at the end that I have to start over since Apple simply won't allow it.

So my questions are:

  1. Is this approach technically possible with Qt Quick and QML? (AFAICT it is, but it never hurts to double check)

  2. Is a program that does this likely to get rejected by Apple for the App Store? (AFAICT it will, but perhaps there is some loophole I can exploit, or perhaps I misunderstand the rule somehow)

  3. If this approach would get rejected by the App Store, is there an alternative/recommended design I could use instead that would pass muster, while still preserving the qualities I'd like to retain (i.e. full/turing-complete server-side specification of the GUI behavior and appearance at run-time, without forcing the user to upgrade the app every time)? (I suppose one approach would be to implement my app as a JavaScript-enabled web page instead, and have the user point his tablet's web browser at a web-server on my server hardware to "run" it, but I'm not confident that that would give me enough control over the user-experience to be very satisfactory)

Jeremy Friesner
  • 1,091
  • 8
  • 11
  • 1
    You might be looking at this from the wrong angle. Why does a GUI need to be Turing complete? It should not have any logic in it *at all*, but should simply display all your do-dads and widgets, and convey user actions to the backend. It sounds like you want your whole app function to be dynamic, which would be impressive and at best dangerous. How can you QA test an app whose behavior doesn't actually exist until the user downloads it and tries it? And, you want to do with (*expensive*) audio equipment? – jpaugh Jun 27 '16 at 14:55
  • 1
    I guess, as long as Apple allows Qtg Quick apps at all, then the worst case is you compile your new GUIs into the app and resubmit it to the store. Your architecture stays the same, just your deployment options changes for iOS. – gbjbaanb Jun 27 '16 at 15:09
  • @jpaugh One problem with implementing all of the logic on the server side is that every operation would require a round-trip across the network (possibly followed by the transmission of a new/updated GUI layout), which could be a bottleneck -- problematic when the app is expected to have a very quick response time. As for QA, we'd control the server, and QA the client in conjunction with the server, of course. – Jeremy Friesner Jun 27 '16 at 18:41
  • Sorry, my wording was misleading. When I used the word backend, I wasn't referring to the server by itself. (Ideally, any app would not need a server; but every app needs a backend: "business logic" or "controller" is a common term for it.) I'm trying to understand what you mean, since "GUI" does not cover every topic you want to discuss. – jpaugh Jun 27 '16 at 18:48
  • @jpaugh Here's an example: The app might contain an EQ graph that shows the cut/gain being applied for each frequency (e.g. something like this: http://dmgaudio.com/images/EQuick.png ). At some point we might decide to add a new type of EQ filter to the server hardware. Traditionally we'd have to release new client software at that point also, since otherwise the client app wouldn't know how to draw the curves for the new EQ type; but if we could download the new EQ math to the app at runtime, we wouldn't have to require an app-store update every time a new feature was added to the server. – Jeremy Friesner Jun 27 '16 at 20:33
  • Thanks! That concrete example makes it much clearer what you're asking. You might not be able to predict every unique input or output, but you should be able to predict every *kind* of input or output, right? Could every graph could be handled by the same function, which receives specific properties of the control as parameters? (And, similarly for other kinds of controls.) That way, no dynamic code is involved at all -- only data change. – jpaugh Jun 27 '16 at 20:52
  • @jpaugh The problem is that it's very difficult to predict in advance what feature management is going to want to add next. E.g. even if I came up with a mechanism that could handle every possible EQ function, that wouldn't help me if management decided they want to add a compressor, or a reverb unit, or a spatialization mechanism, or etc. Hence the desire to "future proof" as much as possible by being able to specify arbitrary routines rather than just parameters to existing routines. – Jeremy Friesner Jun 27 '16 at 23:58

1 Answers1

0

The only officially allowed way to run downloaded code on iOS is for JavaScript code that must be downloaded and run in a UIWebView/WKWebView.

So a possible solution would be to replace QML with HTML/CSS and make a hybrid app that runs UI in a WebView. This approach is quite common in the AppStore. It's used even by some top apps.

There are frameworks that help you to bootstrap a cross-platform app. One popular free framework is https://cordova.apache.org/ With this you can have a custom downloadable UI and access the native code part (via custom plugins). I've used it to make a simple app "objective c interview".

gnat
  • 21,442
  • 29
  • 112
  • 288
battlmonstr
  • 184
  • 2