3 Ways to Develop Cross Platform Desktop Apps with PHP

PHP as a cross-platform desktop app development language? Blasphemy! Nonetheless, it’s possible.

A few years ago, everything those interested in bringing PHP to the desktop had had was the now long abandoned GTK PHP. Since then, new players have appeared, though let’s first answer the “why”.

Why?

Why would anyone develop cross platform PHP apps for the desktop? Why not opt for something that can actually tie into the low level APIs of the operating system, like Adobe AIR? Why not go with something outdated and bloated but reliable, like Java? Why not make it a Chrome app and if you need native support, use Native Client? Hell, if you want a scripting language, why not just go with Python? Everything goes, as long as we avoid having to bundle a server with the whole shebang, right?

Off the top of my head, I can think of several far fetched scenarios:

1. You need a good middle ground between easy syntax and good structure, which is PHP, and you can’t be bothered to learn new languages like ActionScript
2. You’re running IT in a company with highly computer illiterate people, and the only way to force them into using a good browser for your company app is to embed it into the app you deliver. It’s still a web app, but opens in a headless Chrome!
3. You want to avoid paying hosting costs for your own personal application, and you like to carry it with you on a USB stick. You just plug it in, run it, and your app is there – using the same SQLite DB from before. If you need to sync online, you send the whole DB export to Dropbox or some such service at the click of a button, thus making sure you’re literally the only one who can access your “web app” even without your computer.
4. You don’t need low level OS API access – you just want to make a browser based game, or a helper app, or something similarly simple. PHP is perfectly fine for that, and you already know the language.

These scenarios might look like grasping at straws, and indeed, I really can’t think of a REAL, practical reason to want to do it that doesn’t have a viable alternative. Still, it’s nice to know it’s possible. Let’s see how.

1. Nightrain

Nightrain is a pre-packaged set of PHP-hosting prerequisites powered by PHP 5.5.x at the moment. It’s a packager written in Python that uses PHP’s internal server to host your app, thus avoiding Apache and Nginx and minimizing configuration shenanigans. However, this also means some more advanced aspects are unavailable, and you can only really use it for very rudimentary apps.

Another big con is that on Windows, a command prompt is launched first, and then the “app”. The command windows must stay open if you want to use the app, and this might be more than a little confusing to the technically illiterate people of scenario 2) above.

What’s more, you can only run one nightrain app by default, because it actually launches a server on port 8000 and then makes the headless browser that opens “secretly” visit localhost:8000. If you want to launch several different nightrain apps, you need to change the port in settings.ini. This also means that simply visiting localhost:8000 in your host machine’s browser will show you the same app.

Nightrain is compatible with most PHP apps/frameworks out of the box, as long as you change the database to SQLite, which is what’s used, and tweak the bundled php.ini for some missing extensions, if any. MySQL is not bundled and installing it alongside the regular stack is no simple matter. It’s very simple to make the app send the SQLite data upstream to a server you use for a centralized database anyway, so using only SQLite on the system where the app is running is somewhat logical.

By far the biggest drawback of the app is that it uses WX widgets to power the headless browser, and on Windows, this seems to come down to IE7. Changing it seems possible, by means of WXPython as mentioned in the issue linked above, but hasn’t yet been attempted. One can only hope the browser object will be updated to something more usable some time soon – until then, and until all the other critical drawbacks are fixed, I can’t even begin to imagine a use for Nightrain.

2. WXPHP

wxPHP stands for “wxWidgets for PHP” and is a PHP extension that wraps the wxWidgets library, which allows to write multi-platform desktop applications that make use of the native graphical components available to the different platforms. – Wikipedia

You install wxPHP as a separate program, which then gives you support for execution of .wxphp files by simply doubleclicking on them.

This means your applications are mere files, and you can distribute them everywhere with ease. You can organize your code into files and classes as usual and distribute folders. The main .wxphp file can then include these other resources.

The installation comes with several examples, including one which initializes WebView and loads the wxPHP website in a wx frame. One thing to note is that with wxPHP you aren’t developing websites as you would on the web. In other words, you don’t develop offline websites, but string together various wx widgets. As such, the library has a bit of a learning curve, and you’ll be lacking the HTML5 features you might be used to, or the simplicity of web development. There is some Proof of Concept of the internal PHP server running and serving requests, but that’s experimental and complex, and once again exposes the localhost, just like Nightrain.

wxPHP also comes with an adorable form building tool which will help you automatically generate the PHP code you need for your wxPHP apps by means of a wysiwyg editor.

Before you dismiss wx as trivial, people have developed more than basic apps in it. For example, here’s a PHP Editor with remote debugging and a plugin API.

If you’re serious about PHP desktop development, wxPHP is by far the better option when compared to Nightrain, even though Nightrain lets you write good old HTML for GUI.

One of the biggest advantages of wx here is the fact that once installed, all .wxphp files can be run at the click of the mouse. No additional installs, no awkward console windows. For technically illiterate people, that’s a godsend – you can easily distribute the app inside your company via a simple email, and the update procedure is as simple as overwriting a file.

3. TideSDK

TideSDK has a somewhat different approach than the above two. You install an SDK to be able to develop applications, and each platform has certain prerequisites. TideSDK is actually the renamed Titanium Desktop project. Titanium remained focused on mobile, and abandoned the desktop version, which was taken over by some people who have open sourced it and dubbed it TideSDK.

Once installed as per the Getting Started guide, and once we have the TideSDK Developer app (a helper application which will guide us in bundling our application into a distributable package), we can get started developing. Apps you build with Tide (via the helper app, or via the command line) will be both distributable as purely executable, or can be distributed as installable packages which get the whole “app” treatment, including an installation procedure embedded, making them uninstallable via Add/Remove Programs on Windows or your package managers on other operating systems.

Applications resources are used in conjunction with a WebKit client and a familiar and extensive API. The API is privileged, providing filesystem access that allows you to read and manage files. APIs are also provided to create and interact with a local database. Network API allows to create clients and servers or to interface with HTTP at a much lower level. It is also possible to open socket connections to other services.

Generally, TideSDK uses HTML, CSS and JS to render applications, but it supports scripted languages like Python, Ruby and PHP as well. The engine behind the rendering is WebKit which means it’ll be somewhat slow to start, but it’ll support the latest web technologies.

The heart of TideSDK is an object bridge compiled into the WebKit component. The bridge allows other scripting languages – python, php or ruby – to run on the HTML page using script tags in the DOM, just like JavaScript. You can also directly call .py, .rb or .php files from within your application.

PHP is activated by adding a module statement to the manifest file, like so:

#appname:HelloWorld
#appid:com.tidesdk.helloworld
#publisher:Software in the Public Interest (SPI) Inc
#image:default_app_logo.png
#url:http//tidesdk.org
#guid:845e9c3c-c9ff-4ad4-afdf-9638092f044f
#desc:Sample Hello World application
#type:desktop
runtime:1.3.1-beta
app:1.3.1-beta
codec:1.3.1-beta
database:1.3.1-beta
filesystem:1.3.1-beta
media:1.3.1-beta
monkey:1.3.1-beta
network:1.3.1-beta
platform:1.3.1-beta
process:1.3.1-beta
ui:1.3.1-beta
worker:1.3.1-beta
php:1.3.1-beta

Note that using the script modules for scripting languages will incur significant performance penalties on the installation and runtime of your app(s).

Interestingly, TideSDK features an object bridge which lets you, when using PHP in your apps, convert data seamlessly from JS to PHP and back. You can read more here, but a detailed TideSDK tutorial is coming soon.

There are several major downsides to using TideSDK for PHP desktop app development:

1. The PHP development workflow is severely underdocumented and highly susceptible to bugs, but almost impossible to debug.
2. The bundled PHP version is terribly outdated – version 5.3.X at the time of this writing. While it’s relatively easy to replace it with an up-to-date one through the /modules folder in the SDK’s installation directory, it’s an additional nuisance and lacks many modern PHP features which might come in handy in desktop app development, not to mention the built-in server which also might get an esoteric use case here.
3. There is a learning curve. The DOM API is different from what you may be used to in web development. To echo something on screen, you would need to call $document->write() rather than echo. It’s a minor difference, but it isn’t well documented and can trip you up.
4. By far the biggest downside is the compilation. The package you get by building an app is bound to the platform you’ve built it on. To build the app for multiple environments, you need to HAVE those multiple environments. The Windows/Linux disparity is easily solved with virtual machines (though easier to solve if your host is Windows and you have Linux VMs than the other way around), but good luck compiling it for OS X unless you’ve got an OS X device, too.

TideSDK is a neat option, but it’s far from usable. It’ll do great for HTML/CSS/JS delivery, but when it comes to PHP, I believe wxPHP is still your best bet.

Other options

There are other options available too, but they’re underwhelming to say the least.

• PHPDesktop is similar to Nightrain, but is Windows only. On the other hand, it comes bundled with the Mongoose server and can thus execute parallel requests. It also runs Chrome, which means it’s slow to render/open but supports the latest web technologies. Its Windows-exclusivity disqualifies it from this list of multi-platform solutions, though.

• Webinder and PHP GTK are both severely outdated and probably shouldn’t be used. In addition to that, Webinder is Windows-only.

Conclusion

While the reasons for building PHP apps for the desktop vary from use case to use case and often aren’t easy to justify, I believe it’s good to know the option is there, should you ever need it.

Have you developed desktop apps in PHP? If so, please, please let me know why and which tech you’ve used – I would absolutely love to have you write about your experiences. Know of any other options? Let me know in the comments!

Frequently Asked Questions (FAQs) on Developing Cross-Platform Desktop Apps with PHP