Inactive/Failing Mobile Apps: The Many Benefits of Regular App Updates

This article applies mainly to mobile apps which are not in active development. It applies equally to mobile apps on the public app stores and also to enterprise mobile apps which get distributed via other means (such as MDM software).

Example scenario of an inactive/failing app:

• The active marketing of your app that happened at launch has now stopped
• Your app's last update was several months ago
• The uninstallation rate has started rising above your installation rate month on month

A way to prevent this happening is to release regular app updates, even when there are no major changes to your app's code.


Benefits of releasing regular app updates:

• Gain new users; many users look at the last release date on the app store page before downloading your app. Anything over a year old can be immediately rejected as out of date.
• Prevent uninstalls; seeing your app has been updated on their phone keeps it in the user's mindshare, so they know you are still actively developing it.
• Update the dependencies; you will likely have several dependencies on open source libraries and mobile SDKs. The more often you release, the more often these can be updated too.
• Update the toolchain; Xcode / Android Studio / Visual Studio get updated once every month or two. Same applies to hybrid and cross platform toolchains such as Unity, Ionic and Xamarin.
• Update the store listing; since you're doing a build, take the opportunity to review and tweak the store listing and screenshots. Apple's App Store Connect website and Android's Google Play Console get updated regularly with enhancements you can take advantage of.
• Less build issues; there will be a lower chance of a major build issue if you regularly update your toolchain and its dependencies. In my experience, the longer you wait between app builds and releases, the greater the chance of a major build issue the next time.
• Source control change visibility; the project is kept active in terms of source control history; especially relevant if its an open source project with other potential developers able to see the change history on github or bitbucket.
• Developer benefits; you don't end up with a legacy mobile app that noone can get building anymore.

What if there are no significant changes to your code?

• Have the dependencies or toolchain been updated? If yes, that means your app has gained some potential bug fixes and enhancements for free - just by doing a build.
• There's always some minor refactoring you can do to make small improvements to your codebase. Just spend a couple of hours if that's all you can spare.
• The release note; just use the standard "Bug fixes, performance and stability improvements" if you can't think of anything else.

How often to release?

• The more often the better.
• Aim for a regular release cycle of between 1-3 months.

Further reading

Distribution of Android apps per download range
https://www.statista.com/statistics/269884/android-app-downloads/

Download distribution of Android apps, and lifetime growth rates per download range
https://www.appbrain.com/stats/android-app-downloads

Statistics about the release schedule of apps on the Apple app store
https://stories.appbot.co/how-often-should-you-update-your-app-9405b85a967c

Best practices for Apple app store updates
https://developer.apple.com/app-store/app-updates/


Follow @dodgy_coder

Subscribe to posts via RSS

Setting up a Bonjour (Zeroconf) service name for your Raspberry Pi and accessing it from an Android App

I have written an Android app that communicates to my Raspberry Pi over SSH (using JSch) but the issue is that in the App the IP address of my Raspberry Pi has been hardcoded at 192.168.1.109 - ideally it would be good to be able to give it a local name, something like garagedoor.local - something that won't change when the DHCP assigns a different IP address.

It turns out that the way to do this isn't difficult on the Raspberry Pi and most of work is in changes to the Android App needed to make it happen. I've numbered the steps 1-4.

1. Configuration of your Raspberry Pi.

# Get superuser privileges
sudo su

# Change the host name of your Raspberry Pi from "raspberrypi" to "garagedoor"
# Reference: http://www.howtogeek.com/167195/how-to-change-your-raspberry-pi-or-other-linux-devices-hostname/

sudo nano /etc/hosts            # <== Replace raspberrypi with garagedoor
sudo nano /etc/hostname         # <== Replace raspberrypi with garagedoor

sudo /etc/init.d/hostname.sh    # Commit the changes.
sudo reboot                     # Reboot

# Install the mDNS implementation - avahi
# Reference: http://www.howtogeek.com/167190/how-and-why-to-assign-the-.local-domain-to-your-raspberry-pi/
# Get superuser privileges
sudo su

# Update the package sources
apt-get update

# Ugrade the packages
apt-get upgrade

# Install the mDNS implementation - avahi
sudo apt-get install avahi-daemon


That's the end of the changes needed on your Raspberry Pi.

2. Test on either Windows, Linux or Mac OSX that the Raspberry Pi is visible on the network with its new name of "garagedoor.local".

On Windows, you will need to have Bonjour Networking Services installed, which comes bundled with iTunes.
Run a cmd.exe prompt and type the command ping garagedoor.local -- you should get a response from your Raspberry Pi.

On Mac OSX, Bonjour Networking Services are installed by default.
In a bash terminal window, type the command ping garagedoor.local -- you should get a response from your Raspberry Pi.

On Linux, first ensure you have installed the avahi-daemon package.
In a bash terminal window, type the command ping garagedoor.local -- you should get a response from your Raspberry Pi.

3. Using NSD (Network Service Discovery) on Android to resolve the Raspberry Pi's service name.

Browsers and terminal programs on Android won't be able to resolve the garagedoor.local since to do this requires use of either the official Network Service Discovery library (supported by API Level 16 up) or the open source Java Zeroconf library named jMDNS.

In my case, I am using a custom app I wrote to communicate to the Raspberry Pi, so I have decided just to use the Network Service Discovery library.

4. Source code changes needed in the Android App to support NSD (Network Service Discovery)

Notes:
 (1) Below is just how I decided to implement it, you may want to separate the NSD related code out of the Activity into its own class, but for me that wasn't a problem.
 (2) I probably need to do something related to NSD in the Application lifecycle events of onPause(), onResume(), onDestroy() and onTeardown(). I haven't done that here yet.

4.A. Add some members to the Activity

I added this to my MainActivity but my app is small and so that's all I needed to do.

// Network Service Discovery related members
// This allows the app to discover the garagedoor.local
// "service" on the local network.
// Reference: http://developer.android.com/training/connect-devices-wirelessly/nsd.html
private NsdManager mNsdManager;
private NsdManager.DiscoveryListener mDiscoveryListener;
private NsdManager.ResolveListener mResolveListener;
private NsdServiceInfo mServiceInfo;
public String mRPiAddress;

// The NSD service type that the RPi exposes.
private static final String SERVICE_TYPE = "_workstation._tcp.";
   
4.B. Add some init code to the bottom of the Activity's onCreate() method.

mRPiAddress = "";
mNsdManager = (NsdManager)(getApplicationContext().getSystemService(Context.NSD_SERVICE));
initializeResolveListener();
initializeDiscoveryListener();
mNsdManager.discoverServices(SERVICE_TYPE, NsdManager.PROTOCOL_DNS_SD, mDiscoveryListener);
   
4.C. Add the following two new methods to your Activity.

 private void initializeDiscoveryListener() {

     // Instantiate a new DiscoveryListener
     mDiscoveryListener = new NsdManager.DiscoveryListener() {

         //  Called as soon as service discovery begins.
         @Override
         public void onDiscoveryStarted(String regType) {
         }

         @Override
         public void onServiceFound(NsdServiceInfo service) {
             // A service was found!  Do something with it.
             String name = service.getServiceName();
             String type = service.getServiceType();
             Log.d("NSD", "Service Name=" + name);
             Log.d("NSD", "Service Type=" + type);
             if (type.equals(SERVICE_TYPE) && name.contains("garagedoor")) {
                 Log.d("NSD", "Service Found @ '" + name + "'");
                 mNsdManager.resolveService(service, mResolveListener);
             }
         }

         @Override
         public void onServiceLost(NsdServiceInfo service) {
             // When the network service is no longer available.
             // Internal bookkeeping code goes here.
         }

         @Override
         public void onDiscoveryStopped(String serviceType) {
         }

         @Override
         public void onStartDiscoveryFailed(String serviceType, int errorCode) {
             mNsdManager.stopServiceDiscovery(this);
         }

         @Override
         public void onStopDiscoveryFailed(String serviceType, int errorCode) {
             mNsdManager.stopServiceDiscovery(this);
         }
     };
 }

 private void initializeResolveListener() {
     mResolveListener = new NsdManager.ResolveListener() {

         @Override
         public void onResolveFailed(NsdServiceInfo serviceInfo, int errorCode) {
             // Called when the resolve fails.  Use the error code to debug.
             Log.e("NSD", "Resolve failed" + errorCode);
         }

         @Override
         public void onServiceResolved(NsdServiceInfo serviceInfo) {
             mServiceInfo = serviceInfo;

             // Port is being returned as 9. Not needed.
             //int port = mServiceInfo.getPort();

             InetAddress host = mServiceInfo.getHost();
             String address = host.getHostAddress();
             Log.d("NSD", "Resolved address = " + address);
             mRPiAddress = address;
         }
     };
 }

4.D. Make use of the mRPiAddress member where previously you used a hardcoded IP address.

Check that its not empty before using it. If its empty, it means the RPi's name couldn't be resolved.


Follow @dodgy_coder

Subscribe to posts via RSS

Android development is the new .NET

Back in 2001 Microsoft Windows had 90% of the worldwide OS market for PCs. But desktop windows software development was dire.

Developers were using tools like ...

• Visual Basic 6 - very productive, with the downside of ugly, primitive syntax, lacking modern features such as interfaces and classes.
• Visual C++/MFC - serious windows developers were using this, but it was less productive and extremely verbose, with lots of boilerplate.
• Delphi -  the successor of Turbo Pascal and possibly the best of all frameworks on Windows at the time, but it never really took off.
• Borland C++/OWL - the Open Windows Library from Borland tracked pretty closely with Visual C++/MFC, verbose + boilerplate.
• Java - this had a reputation on Windows at the time for slow performance, bad visuals and bad tools.

At this point, Microsoft came out with Visual Studio.NET, the .NET framework and a new language named C#, with the help of former Delphi & Turbo Pascal language designer Anders Hejlsberg. Most Windows developers got on board - compared to what came before it was a breath of fresh air. Since that time, .NET has remained a large player, especially in the corporate and business market.

Fast forward to 2014, Android now has an 80% worldwide market share of approx. 1.75 billion smart phones.

Google has their own IDE, Android Studio and the open source Android SDK, which you can program using Java or any other JVM language. In the same way that .NET lets you use different .NET compatible languages such as C++/CLI and F#, Android supports other JVM languages like Scala, Clojure and Groovy, all of which let you cut down on the verbosity and boilerplate of Java.

Google is attempting to bring as many developers over to Android as possible. Their Head of Scalable Developer Relations, Reto Meier, aims to bring 50 million developers to Android.

Based on Android's market share and future employment prospects, Android is a decent choice for developers to try out. Compared to iOS, Android isn't as performant or profitable, but now it has a decent IDE, the weight of numbers, and the capability to use many Java FOSS libraries.

Follow @dodgy_coder

Subscribe to posts via RSS

Hyperlink vs Button in Android

After installing the Google Play Music app, the first screen allows you to choose which Google account to associate with it.

Seems straightforward enough; but have a look at the screen - what you would press?



Looks like there's a choice of two commands, either Add account or Not now. But there's another command there ... the email address is a clickable hyperlink, but there's no indication that it is - no underline or radically different font. The Add account button actually prompts you to type in a new email address, i.e. not the one listed. One of the most confusing UI designs I've seen lately.

As discussed in this StackExchange.UX post, there's no strict rule about it, but buttons usually perform a command and hyperlinks usually take you somewhere new.

To improve it, maybe there should be a "Use" button to the right of each email address.

Follow @dodgy_coder

Subscribe to posts via RSS

Modern Cross Platform Development

Why isn't there a modern technology available for using the same codebase to produce native apps on all of the currently popular platforms - I'm talking iOS (iPhone/iPad/iPod Touch), Android, Windows, Mac and Linux?

That was my original question before I started looking, and since then I've discovered there actually are plenty of new options out there for cross platform development catering for all of the above platforms.


A Brief History of Desktop UI Toolkits

In the 1980's the problem of a cross platform desktop user interface was for the most part solved by the X Window system, known as X11, (1984-) along with one of the first widget toolkits, Motif (1989-), which was built on top of X11. Back then, the dominant platforms used by business were Microsoft Windows and the various flavours of Unix, like Sun Solaris, HP-UX, IBM's AIX etc (later Linux came along and maintained full support for X11 and Motif). Developers who wanted to target multiple platforms such as these had this option of developing one codebase, usually written in C/C++, using X11 and/or Motif.  The UI code for the most part could remain the same and the application just needed to be recompiled with the provided X11 libraries.

Since then Motif has pretty much faded into the background and been replaced with newer widget toolkits, still built on top of X11, including Qt (1991-), wxWidgets (1992-) and GTK+ (1998-). These now run on many different platforms and bindings are available for many, many languages, including for their native C or C++.

These three free open source toolkits have been successful for the desktop application case but looking towards mobile and tablet platforms, these toolkits don't currently have the support there to take them into the future.

Qt
Native language: C++
Platforms: iOS (unofficial), Windows, Mac, Linux.

Probably the C++ based Qt widget toolkit is the most well established way of writing desktop cross platform applications. Smartphone support isn't really there yet, but there is an unofficial port to iOS. Linux's KDE desktop environment is written with the Qt toolkit. Many significant apps have been developed with Qt, including Autodesk Maya, VLC media player, Mathematica, Virtual Box and Skype. Qt is now owned by Nokia (although is still open source), and there was a release of a new version recently (Qt 4.8).

GTK+
Native language: C
Platforms: HTML5 (unofficial), Windows, Mac, Linux.

The C-based GTK+ widget toolkit is also a very well established way of writing cross platform desktop apps. Smartphone support isn't there, but there is an unofficial port to HTML5. GTK+ powers Chromium on Linux, the open source forerunner to Google's Chrome browser. The GNOME desktop environment is written with the GTK+ toolkit. The other notable app written with GTK+ is the one that launched the toolkit itself, GIMP, an open source bitmap image editor.

wxWidgets
Native language: C++
Platforms: iOS, Windows, Mac, Linux.

A C++ native mode toolkit that provides a thin abstraction to a platform's native widgets. It was originally developed as a desktop GUI toolkit in the same vein as GTK+ and Qt and support for iOS is still beta. There are a number of notable apps developed with wxWidgets including BitTorrent, Audacity, TortoiseCVS and RapidSVN.


Java and Silverlight

Sun's Java Swing UI Library (1997-) and Microsoft's Silverlight (2007-) were both attempts at "write once, run anywhere" (WORA) technology that provided a rich user interface library. Although technically successful, they failed in their attempt to become the ubiquitous technology that everyone uses to develop UIs. They both attempted to replace the 'native' look of apps developed on a particular platform and instead impose their own look and feel based on graphical primitives, which although being more powerful for developers, users on the whole didn't like.

As Johannes Fahrenkrug discusses here, people actually want to run Windows apps that look like Windows apps, and run MacOS apps that look like MacOS apps. To be fair, the Java Swing UI has actually undergone a lot of advances since it was first released and can now generate apps that do look perfectly native on all desktop platforms. The problem may be however that people's original experience of early Swing apps having a slow and inconsistent UI might have put them off using other Java apps and so contributed to its demise.

In the case of Microsoft's Silverlight and WPF, although not officially dead yet, they are now taking a back seat to newer technologies that were released by Microsoft at the September 2011 Build conference; Windows 8 allow developers to create new style 'Metro' applications by using either web technology (HTML5/JavaScript/CSS) or a traditional language - C#, VB.NET or C/C++ paired up with XAML for describing the UI. There's more detail about this topic on StackOverflow here for those interested.


The Rise of Web Applications and the App Store

The two big changes since the desktop UI toolkit days has been the rise of browser-based web applications and more recently the rise of downloadable apps running on smartphones and tablets such as Apple's iOS (powering the iPod touch, iPhone and iPad devices) along with Google's Android (powering a vast array of different smartphones and tablets from many hardware vendors). Google's recent Chrome OS also deserves a mention for creating an OS around the browser itself. These new class of devices offer a quick method of downloading, paying for and installing apps (often with just one click) and appear in the easy to use 'App Store' on iOS and 'Android Marketplace' on Android.

Microsoft is getting in on the App Store action a little late with its 'Windows Store' for Windows 8, which will be appearing some time in 2012. Its thought by Hal Berenson (a former Distinguished Engineer at Microsoft) that the upcoming Windows Phone 8 OS will be based on the same technology as Windows 8 and hence will unify  the development platform for Microsoft's desktop, tablet and smartphone operating systems. This will likely be announced some time in 2012, probably at the same time Microsoft launches the 'Windows Store'. This will mean Windows 8's new 'Metro' style apps on the Windows Store will run on phones, desktops and tablets - something that neither Apple nor Google can lay claim to, just yet. Add in the possibility of an XBox update which adds support for running Metro apps, and you have a huge carrot which will make the unified Windows 8 platform very attractive to both application and game developers.


Choosing Your Platform - Desktop, Web or Mobile Application?

When choosing your platform, if you need full access the underlying file system, or access to hardware devices like serial ports, microphones, webcams, etc, then you may be better off staying with a desktop application. If you need platform independence on top of this then you can go with one of the traditional widget library technologies like wxWidgets, GTK+ or Qt to provide a full cross platform UI solution.

Alternatively, if you don't need so much access to hardware and can remain restricted to the browser, then HTML5 and JavaScript may be the way to go. Browser based web applications have their own set of problems however, including the browser incompatibilities, varying support for the HTML/CSS web standards and the Document Object Model (DOM). In addition, web application development generally makes it harder to create rich UI apps than for desktop or mobile applications. HTML5 will provide massive improvements, but web apps are still running in a browser and so will always remain sandboxed and limited in what they can achieve (no access to file system, serial ports, microphone, webcam, etc.).

The main advantage of the browser app however, and its a massive one, is that its everwhere and supported by every device, so if HTML5 takes off, then it could become the defacto standard for developing apps of any kind, desktop or not. As Jeff Atwood discusses in his seminal blog post All Programming is Web Programming; "the web is the most efficient, most pervasive, most immediate distribution network for software ever created - its almost completely frictionless".  As Atwood mentions, more and more users gravitate towards preferring to run their apps inside the browser, on smartphones and on tablets where things 'just work' and there's generally nowhere near as much friction caused by the traditional desktop software setup and update process.

A third option available now is the cross platform mobile development SDK as detailed below (Mono, Appcelerator Titanium, Rhodes, PhoneGap, MoSync, Moai, Corona SDK and JUCE). Smartphone and tablet based applications are taking off, and these SDKs allow you to write once and run on any of these new class of devices, as well as in some cases also being able to run on the traditional desktop. These would seem to offer some of the 'power' of the desktop in terms of native code execution speed and access to hardware functionality, along with the enourmous 'frictionless' benefit that you get when publishing to an app store, where installing an app is literally a one click operation.

Mono
Native language: C#
Platforms: iOS, Android, Windows, Mac, Linux, Browser (e.g. via ASP.NET WebForms or MVC).
Cost: Windows, Mac & Linux: free. Android and iOS: from US$399 each. Free trial available.
License: LGPL/GPL/X11 combination. Commercial license available.
Source: Mono for Windows/Mac/Linux is open source. Mono for iOS/Android is closed source.

The C# based Mono cross platform library allows apps to be built using purely C#. However this is not strictly a cross platform UI library, since each supported platform has its own different set of Mono C# UI libaries, each with their own capabilities. The idea is that you build your software using the MVC (Model View Controller) pattern, so that the Model and Controller components (both written in C#) can be shared across all platforms without any changes. Only the View component needs to be re-written for each platform (again, in C#). Mono targets both mobile and desktop apps, however if you are just looking at developing a desktop application, then Mono probably isn't a big improvement over GTK+ or Qt, after all a well written C++ Library (with a Model and Controller component for example) will enjoy the same capability to be shared across more than one platform if you use Qt or GTK+ and then you wouldn't need a different UI library on each platform to create your view. There are several advantages that Mono has over Qt or GTK+ however - firstly in leveraging a team's existing knowledge (and codebase) of C# which is a popular language. Secondly, being able to target iOS, Android and the browser. Lastly, via Mono's .NET CLR implementation (Common Language Runtime), code is compiled into modules of bytecode, which are binary compatible across all the supported platforms.

There is also an open source library for Mono called MonoGame which lets you port with minimal effort XNA based games (which originally target the .NET platform and run only on Windows Mobile, Windows and XBox) to any of the Mono platforms such as MacOS, Linux, iOS and Android.

Appcelerator Titanium
Native language: JavaScript, Python and Ruby
Platforms: iOS, Android, Windows, Mac, Linux.
Cost: Community Edition is free. Indie Edition (extra APIs, help, support): US$499 per year.
License: Apache Public License v2
Source: Open source

An open-source solution which allows you to use web development languages (HTML, JavaScript, CSS, Python and Ruby) to build mobile and desktop apps. App data can be stored in the cloud or on the device, and apps can take full advantage of hardware, particularly camera and video camera capability. Appcelerator apps go through a complex compilation and optimization process which result in it creating apps that look, feel, and perform just like native apps, because you are using native UI components... so an iPhone app developed with Titanium will actually feel like an iPhone app. They also offer an API repository marketplace to buy and sell code to extend Titanium. One of the downloadable components allows you to develop your app using an MVC (Model View Controller) pattern. There is an active developer community Q&A site for Titanium developers which is similar in usage to StackOverflow.

Rhodes
Native language: Ruby
Platforms: iOS, Android, Windows Mobile, Blackberry.
Cost: Free
License: MIT License
Source: Open source

Rhodes is an open source, Ruby-based framework that allows the development of native apps for a wide range of smartphone devices and operating systems. The framework lets you write your code once and use it to quickly build apps for every major smartphone. Apps can take full advantage of available hardware, including GPS and camera, as well as location data. Rhodes enforces a strict MVC (Model View Controller) pattern on your apps. Views are written in HTML5 while Controllers and Models are written in Ruby.

PhoneGap
Native language: HTML5/JavaScript
Platforms: iOS, Android, Windows Mobile, Blackberry, Symbian, Palm.
Cost: Free
License: Apache License, Version 2.0
Source: Open source

PhoneGap is an open source framework that helps you develop apps for smartphones using web development languages such as JavaScript and HTML5. It also allows for access to hardware features including GPS/location data, accelerometer, camera, sound and more. PhoneGap lets you take a web app, run it in a UIWebView, and through javascript you can access iPhone features such as the camera an accelerometer. This means that it won't necessarily have the look and feel of a native app (like the other cross platform SDKs listed here). The idea is that you develop your web app like you normally do, and then use PhoneGap to 'bridge the gap' to the phone, and give you access to phone's hardware, that traditionally you couldn't access from a web-only app.

MoSync
Native language: C++
Platforms: iOS, Android, Windows Mobile, Blackberry, Symbian.
Cost: Free for Indie developers. From €199 (Euros) per year for Enterprise developers.
License: GPL v2. Commercial license available.
Source: Open source

The MoSync Mobile SDK is a cross-platform mobile application development SDK which allows the development of native apps. Free open-source, it is based on C++ but allows development also in HTML5 and JavaScript. MoSync provides access to a wide range of underlying device functionality, via a C++ SDK or optionally via JavaScript.  It requires probably a greater degree of software skill from the developer, but in principle can enable a rich variety of different kinds of application.

Moai
Native language: Lua
Platforms: iOS, Android, Chrome Web Store, Windows, Mac, Linux.
Cost: Free
License: Common Public Attribution License Version 1.0 (CPAL)
Source: Open source

Although intended to be a mobile game development SDK, I think it deserves a mention here due to its unique scripted approach to cross platform development. Games developed with Moai run on iOS and Android as well as the Chrome Web Store, Windows, Mac and Linux. Designed to be programmed with the Lua scripting language, Moai is designed for experienced game developers who wish to use Lua for mobile development. The Moai framework itself is written in C++ and is intended to be called from the Lua scripting language, but can also be called from any other language supported by the host platform. The Lua script is run as interpreted byte code, but since very few Lua instructions are processed among all the input handling, this means that rendering, animation, collision detection, and physics math runs natively. Moai's physics engine for example is the Box2D open source C++ library. Moai is free and open source, however to build apps for iOS devices you'll need the iOS SDK and the Xcode IDE (presumably running on MacOS) and be a member of the Apple iOS developer program (US$99/year). To build apps for Android you'll need the Android SDK, the Eclipse IDE and an Android device.

Corona SDK
Native language: Lua
Platforms: iOS, Android, Kindle Fire, Nook Color.
Cost: US$199/year for Android. US$199/year for iOS. $349/year for all platforms. Free trial available.
License: Commercial, price as above.
Source: Closed source

A similar toolkit to Moai in that its primarily aimed at game developers, and apps are written with the Lua scripting language. Corona SDK was developed by two former Adobe mobile engineers and has been in development since 2007. It features a proprietary OpenGL-ES rendering engine, which allows for full hardware acceleration of graphics, including sprites that animate at full GPU speed. The Corona physics engine is built around Box2D as with Moai. Its free to try Corona and run your apps in a simulator on your desktop computer, but to build an app and publish it to an App Store, you'll need to pay a yearly subscription fee (of either US$199 per year for Android or iOS or the premium subscription of US$349 for all platforms). Your apps are built "in the cloud" on Corona's server. Note that if you are developing for iOS you'll still need to pay the yearly Apple iOS developer program fee which is currently US$99. There seems to be extensive documentation available for Corona and an active developer community forum. There has been a recent push to promote Corona for use not only for developing games but also for general apps and also interactive ebooks.

JUCE
Native language: C++
Platforms: Windows, MacOS, Linux, iOS, Android (Note that Android support is a work in progress).
Cost: Free for GPL license. Commercial license from £399 (UK pounds) per product.
License: GPL. Commercial license available.
Source: Open source

JUCE is an all-encompassing C++ class library for developing cross-platform software. Its designed to contain everything you're likely to need to create most applications, and is particularly well-suited for building highly-customised GUIs, and for handling graphics and sound. JUCE is developed by Raw Material Software and consists of a small team of developers based in London, England, founded by Julian Storer in 1999, who is still the primary developer today. It would probably be best suited to experienced C++ developers. Julian Storer himself is a professional C++ coder with over 15 years of C++ experience; he takes pride in the fact the source for JUCE is literate, coherent, cross-platform and high quality. Adding JUCE to your C++ application is very simple - the easiest way involves simply including juce.h in your files and adding a single .cpp file to your project. No need to compile any libraries or worry about dependencies.

Follow @dodgy_coder

Subscribe to posts via RSS