These are the golden rule of computer security: "It is impossible to hide anything from a competent user with system administrator privilege" and "any competent user with physical access to the device can always elevate himself to system administrator".
You cannot hide any information from someone with physical control of the machine. If the secret you are trying to hide is really important, then you should never transfer the data to the machine and do your processing elsewhere in a place that you control.
Your program is running on a user's machine. You cannot protect your data from the user. With that in mind, does this mean we're doomed? Not necessarily. The operating system provides a wealth of mechanism for programs to communicate privately with another program that will not allow another unprivileged application to intercept it. So, while you cannot protect any data from the user themselves, you can protect your data from another unprivileged program. Providing security boundary between unprivileged programs is one of the main job of the operating systems.
The simplest of this is an anonymous pipe. A pipe allow a unidirectional stream of data to be transported between program. Anonymous pipe is available in Windows, Linux, OSX, and all Unix-like systems. Anonymous pipe most commonly recognized as a pair of pipe called stdin and stdout that allows a parent process to send and receive a stream of data to and from its children. Anonymous pipe can only be used between processes that have parent and child relationship. There is also a named pipe, but they behave differently in Windows and in Linux/Unix-like systems, we will get back to this later.
Another IPC that are commonly available is sockets. Sockets is like a bidirectional pipe. There are many different sockets but they work similarly. The most commonly known is TCP socket. TCP socket is primarily intended for networking between machines but you can also create a loopback TCP socket which can only be used within the same machine. A loopback socket provides privacy (only the program the program that connects and the program that listens can read the data passing through the socket), however it does not really provide mechanism to restrict who can be the other side of the socket.
Another type of socket available in Unix for communication between processes in the same machine is Unix Domain Socket. A Unix domain socket is exposed to programs as a "special file" in the filesystem, and unix filesystem permission is used to control access to the socket. A domain socket cannot be connected to by programs that does not have the right access permission to access the socket file. In Unix-like systems, this means that your service and GUI should run as the same user and/or group that are reserved only for your program and you set the socket file permission appropriately.
Let's get back to named pipe. In Linux/Unix-like systems, a named pipe is pretty much like stdin/stdout in that they are unidirectional. In Windows, however, a named pipe is actually bidirectional and is pretty much the equivalent of Unix domain socket in Windows. Like a lot of things in Windows, named pipe is secured with ACL.
With iOS things becomes a bit hairy. A non-jailbroken iOS only allows a very limited set of inter-process communication, and neither will give you a socket. But if we play loose with definition, in the iOS application, the service program and the GUI program is probably going to actually be the same application, and thus you can simply create a stream directly between different components of the application. This is also secure as the stream is accessible only within the application.
Android provides more options for IPC, including the ability to create domain socket. The API is different but they are conceptually similar with regular Linux. Alternatively, you may go the same approach like in iOS and package your service and GUI in the same application and just use in-process streams.