Click Here to Request a FREE Quote to Develop an iPhone App or Android App

Internet of Things

Desirable Apps customers are increasingly interested in extending the internet beyond the box. The age of affordable internet of things has well and truly arrived. If you have an idea for internet of things, integrating mobile devices and websites with physical remote systems, contact us to discover how we can help you explore this exciting new frontier in business services.

Mobile Apps and Artificial Intelligence

I get asked a lot of questions about Artificial Intelligence. Artificial intelligence is processor and memory intensive, so despite advances in mobile battery capacity and processor speed, if a mobile app requires access to an artificial intelligence it is better to do the heavy lifting on a background server. Occasionally the AI task is lightweight enough so a mobile can perform the AI feat on its own, without help from a backend system.

The following is a simple AI demonstration – a solution for the Travelling Salesman Problem. The task is to find the shortest route which allows a travelling salesman to visit all of the cities on their itinerary.

(Click here for a full screen version of the demonstration)

A mobile device or computer could simply look at every possible path, but as you add more cities, the number of possible paths grows impossibly large – years, maybe millennia would be required to examine absolutely every possibility, when considering more than a handful of cities.

Thankfully artificial intelligence can help. Through use of an Evolutionary Algorithm it is possible to build on past knowledge, while combining the best traits of winning solutions.

As the name implies, an evolutionary algorithm seeks to mimic nature, by taking the fittest solutions, slicing them up, and splicing them together – very much what happens during sexual reproduction. Most of the time the spliced version will not be as good as the original parents, but sometimes it is better. The occasional win is enough to keep this particular algorithm wriggling towards a solution.

I like the Travelling Salesman Problem because it is one of the most visual of possible AI demonstrations – by watching you can get a real feel for how artificial intelligences solve problems.

If you have any questions about artificial intelligence and how AI could help your mobile app, please contact me at Desirable Apps.

Mobile App Search Company raises $60 million

Quixley just raised $60 million funding for their mobile app search business.
Quixley just raised $60 million funding for their mobile app search business.

Mobile App Search Company Quixley has confirmed it has successfully raised $60 million in funding, valuing the company at $600 million.

According to Tech Crunch;

Quixey has been a longtime participant in the mobile search space, and develops a technology that goes beyond just connecting people with new applications. Instead, it’s also focused on helping people find the content found within applications. For example, if you were searching on mobile for something like Thai food, Quixey’s technology could return results from across apps, including things like Yelp reviews of restaurants or a Groupon deal.

This technology, referred to in the industry as “deep linking,” is something that all the major tech players are taking advantage of today, including companies like Facebook, Google and Twitter, as well as startups like URX, Branch Metrics, Button, and many others.

Read More...

Quixley’s unique selling point is their technology for “surfacing” the deep functionality of mobile apps.

“Surfacing” deep functionality is a critical step in the process of building a searchable catalogue of mobile apps. Mobile Apps are difficult to map, compared to websites.

The reason why websites are easier to catalogue, is that (almost) all websites are built on top of a common set of standards. The code which web servers send to web browsers (or search engines posing as browsers), contains all the information a search engine needs, to construct a catalogue of the website – it contains the description of how to draw the web page, and contains links to other web pages on the same website. A web search engine can usually extract pretty much all the data it needs to analyse a website, by asking the web server for the home page, then following the coded links to all the other pages on that website.

Mobile apps are different, because they are self contained software. There is no web server broadcasting the structure of the website to anyone who asks. Instead, to catalogue the pages of a mobile app, you have to install the mobile app on mobile phone, and start pressing buttons at random, to try to work out all the different things the mobile app can do.

Quixley has circumvented this limitation, by devising technology which tricks mobile apps into thinking they are running on a mobile phone – but actually, the mobile apps being analysed by Quixley are running on highly customised devices, which are designed to capture and catalogue all the screens presented by the mobile app during the analysis process.

Why go to all this trouble to open the hood on the mobile app, when you could simply read the description written by the mobile app developer? The answer is that it is always better to look for yourself, than to take someone’s word for it. The mobile app developer might have done a poor job of communicating what their mobile app does, or might even have overlooked describing elements of functionality which the catalogue provider thinks are really important.

Quixley’s future should be very interesting to watch – no doubt Google and other search businesses, are watching developments, and weighing their options.

Mobile App Development: Native or Web?

Web App vs Native Mobile App - a Big Development Decision
Web App vs Native Mobile App – an Important Development Decision

Software Development Times has written an excellent article about one of the important early development decisions which needs to be made when developing a mobile app – should you use native mobile app development tools, or should you present your app functionality using web technology – HTML, CSS and Javascript?

According to SDT:

Native apps maximize performance and user experience

Native development is, on average, the most widely adopted approach. Forrester’s latest Business Technographics Global Developer Survey found that, overall, developers build native apps 38% of the time, hybrid apps 22% of the time, and Web apps 27% of the time. That’s not surprising: Native apps offer a great combination of performance and user experience. And when done right, they deliver a high level of customer satisfaction compared to Web applications, as well as enable superior offline processing and storage capability.

But regardless of these benefits, native apps are a challenge to maintain. Developers we’ve worked with report porting costs of 50% to 70% of the cost of the original app for every new mobile operating system the app needs to run on. Plan to support iOS, Android, BlackBerry and Windows? That’s an increase in development costs of 150% to 210%.

Web apps minimize costs and improve agility

While developers on average spend more time building native apps, at least 74% spend time building with a Web-based approach. But with native’s advantages in performance and user satisfaction, why would anyone want to use Web technologies?

Unless an unlimited development budget is available, taking a native-only approach exceeds the reach of many development teams. A good rule of thumb is to estimate 20% to 25% in additional porting costs when using Web technologies, significantly less than the cost of an all-native approach.

Web Apps vs Native Apps

Web Apps, at least for some types of apps, offer a cost advantage if you plan to target a large number of mobile platforms (iOS, Android, Blackberry, Microsoft, etc.).

HOWEVER, web apps in my experience present a challenge if you want to create an app which appears to be native – you can spend a lot of time and effort making web buttons look exactly like native buttons, only to have all the rules change next time Apple or Android upgrade their operating system.

In addition, there are many types of app functionality which would perform poorly if implemented using web app technology. For example, if your app presents a long list of database entries, particularly if you want the contents of the database list to update automatically as the user types text into a search field, the inferior performance of web app technology very quickly becomes an issue – if your database contains more than a 50 entries, it is very difficult to make a web app provide acceptable search performance, without developing native mobile app components to augment the search – which kindof defeats the purpose of using web app technology.

In general I advise clients NOT to opt for the web app approach, unless the functionality of their mobile app is simple and not computationally demanding. While the lure of being able to port the bulk of your app to different mobile platforms with minimal changes might seem attractive, in my experience the risk of unsatisfactory mobile app performance, and the difficulty of achieving that vital last 1% of polish to make the web app into a compelling user experience, more than outweighs any benefits.

The Facebook Web App Experience

I’m not alone in my assessment of the significant challenges associated with creating high quality web apps. Facebook chose to redevelop their web app into a native iPhone app, because of the stability and performance issues their team encountered during development of their web app.

https://www.facebook.com/notes/facebook-engineering/under-the-hood-rebuilding-facebook-for-ios/10151036091753920

Scaling up with HTML5

As mobile usage exploded over the last few years, our priority was to ensure that regardless of device, platform, network, or region, Facebook users had a good experience on their mobile devices. To support thousands of devices and multiple mobile platforms, we leveraged HTML5 to build and distribute Facebook mobile experiences across iOS and other platforms.

By allowing us to write once and ship across multiple platforms, HTML5 has historically allowed us to keep the Facebook mobile experience current and widely available, and has been instrumental in getting us to where we are today. We chose to use HTML5 because not only did it let us leverage much of the same code for iOS, Android, and the mobile web, but it also allowed us to iterate on experiences quickly by launching and testing new features without having to release new versions of our apps.

So while utilizing web technology has allowed us to support more than 500 million people using Facebook on more than 7000 supported devices, we realized that when it comes to platforms like iOS, people expect a fast, reliable experience and our iOS app was falling short. Now that our mobile services had breadth, we wanted depth. So, we rewrote Facebook for iOS from the ground up (I really did open up Xcode and click “New Project”) with a focus on quality and leveraging the advances that have been made in iOS development.

(Re-)Building for speed

One of the biggest advantages we’ve gained from building on native iOS has been the ability to make the app fast. Now, when you scroll through your news feed on the new Facebook for iOS, you’ll notice that it feels much faster than before. One way we have achieved this is by re-balancing where we perform certain tasks. For example, in iOS, the main thread drives the UI and handles touch events, so the more work we do on the main thread, the slower the app feels. Instead, we take care to perform computationally expensive tasks in the background. This means all our networking activity, JSON parsing, NSManagedObject creation, and saving to disk never touches the main thread.

To give another example, we use Core Text to lay out many of our strings, but layout calculations can quickly become a bottleneck. With our new iOS app, when we download new content, we asynchronously calculate the sizes for all these strings, cache our CTFramesetters (which can be expensive to create), and then use all these calculations later when we present the story into our UITableView.

If you would like advice on whether your proposed iPhone App or Android App is a good fit for being developed as a web app, or whether you should choose the native mobile app development option, please Contact Me

How to write a mobile app

A nice graphic to denote writing your own app
Writing your own app can save you money and be a lot of fun

Writing an iPhone App or Android App is expensive. Even the simplest mobile apps usually need at least a week or two of skilled developer time to construct.

If you have technical skills, perhaps past coding experience, one obvious solution to save money is to write your own app.

Why write your own app? Beside saving money, writing your own app can be a lot of fun. Writing an app is a creative experience, like painting a picture or composing a song.

How do you start?

You could do what I did – invest hundreds of hours of your time into learning how to create apps for your mobile app platform of choice.

Or you could ask an expert for help – you could cut through all the time consuming trial and error, and ask me to help set up your development environment.

I can get you started with app development essentials:

  • How to set up your development environment.
  • How to create your first app
  • How to transition between different app forms
  • How to create fancy graphics and transitions
  • How to package your app for publication on app store
  • What is the best development option for leveraging your previous coding skills

How long will it take?

The length of time it takes to get started with app development depends on your previous coding experience, and what mobile app platform you want to start with.

For example, if you have a background in developing web apps, you could leverage those skills by using a cross platform development environment like Cordova, which provides a framework for creating an app using HTML web pages.

If you have a choice of starting with iPhone or Android, I recommend you start with iPhone – though the Apple development environment only runs on Apple Mac computers. The Android app development environment is more difficult to set up than the iPhone app development environment, and creating your first Android app is a steeper initial learning curve. However, once you are past the initial learning curve, both environments are very similar in terms of the effort required to create an app.

If part of your app is too complicated for your current level of experience, I’m happy to assist, by creating blocks of code which you can insert into your app. But you can still potentially save a bundle by developing as much of your app as you can, yourself.

Lesson Plan

My recommendation is to start by booking 3 x one hour sessions, spaced 1 week apart.

  1. First Lesson – setting up your mobile app development environment.
  2. Second Lesson – developing your first app
  3. Third Lesson – deploying your app to app store or play store

You can book additional lessons as required. I charge $100 + GST per one hour session. The lessons are conducted using Skype, because Skype lets you share your computer screen, so I can see exactly what is happening, and give you realtime advice on how to achieve you mobile app development goals.

Contact me now for more information on how to develop your own app.

British PM – Ban encrypted mobile apps

Messaging app image used in The Guardian
Messaging app image used in The Guardian

British Prime Minister David Cameron has stirred controversy with a new push to ban mobile apps which allow users to communicate via secure, encrypted messaging.

According to The Guardian;

The prime minister has pledged anti-terror laws to give the security services the ability to read encrypted communications in extreme circumstances. But experts say such access would mean changing the way internet-based messaging services such as Apple’s iMessage or Facebook’s WhatsApp work.

“In extremis, it has been possible to read someone’s letter, to listen to someone’s call, to mobile communications,” Cameron said. “The question remains: are we going to allow a means of communications where it simply is not possible to do that? My answer to that question is: no, we must not.”

My biggest concern about this kind of well meaning but wrong headed initiative is the depth of ignorance it demonstrates, about what is and isn’t possible, and how tech works. You can’t stop people using encryption for communication – even if messaging mobile apps were somehow banned, people could still use encrypted websites to communicate.

But you can cause a lot of trouble for fledgling domestic high tech industries by introducing ham fisted regulations, which put domestic businesses at a significant competitive disadvantage in the international market.

This controversy harks back to the 90s US crypto controversy. The US government banned the export of encryption technology which was difficult for their supercomputers to crack, classifying it in the same category as high tech military weapons. An ingenious response to this silliness was illegal immigrants, who had the export restricted encryption code tattooed onto their bodies, which made it illegal to export them.

Slow Web Day!

What do you do when your website is running slowly, or not responding?

I had to deal with this situation today, when someone pointed out they couldn’t see my home page.

My first action was to wait a bit – sometimes transient internet glitches occur, so simply waiting a few minutes can save a lot of wasted effort, trying to get to the bottom of a problem which doesn’t exist.

Waiting didn’t help in this case, so my next step was to examine the server logs, to find clues as to what was happening.

I immediately found the problem – thousands upon thousands of requests, for a file called xmlrpc.php.


89.248.168.46 – – [24/Sep/2014:10:00:27 +0000] “POST /xmlrpc.php HTTP/1.0” 200 370 “-” “Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)”
195.154.127.19 – – [24/Sep/2014:10:00:26 +0000] “POST /xmlrpc.php HTTP/1.0” 200 370 “-” “Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)”
195.154.127.19 – – [24/Sep/2014:10:00:28 +0000] “POST /xmlrpc.php HTTP/1.0” 200 370 “-” “Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)”
195.154.127.19 – – [24/Sep/2014:10:00:26 +0000] “POST /xmlrpc.php HTTP/1.0” 200 370 “-” “Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)”
89.248.168.46 – – [24/Sep/2014:10:00:37 +0000] “POST /xmlrpc.php HTTP/1.0” 200 370 “-” “Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)”
80.82.65.17 – – [24/Sep/2014:10:00:41 +0000] “POST /xmlrpc.php HTTP/1.0” 200 370 “-” “Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)”

xmlrpc.php is a legitimate web file, which helps some servers communicate with web pages. But these web requests were clearly not legitimate – my web server does not use xmlrpc.php. These web requests are incoming attacks from computers which are infected by a computer worm.

The attacks aren’t targeting the Desirable Apps website specifically – they are infected computers blindly attacking any other machines they can find, in the hope of infecting a new host. But there are currently so many computers infected by this worm, the effort of trying to respond to all the legitimate looking requests from infected machines is (or was) overloading my website, preventing legitimate visitors from getting a response.

The solution was, in this case, very straightforward. Since I don’t use xmlrpc.php, I modified the web server configuration to immediately reject any request which referenced xmlrpc.php, without attempting in any way to process it.

Desirable Apps is still being attacked – but it is now rejecting the attack requests far more efficiently, so the web server is now able to respond normally to legitimate visitors.

Could Android Apps replace Microsoft Windows?

Today The Register, a major tech website, published news that China has discontinued its efforts to develop a Red Chinese rival to Microsoft Windows, Red Flag Linux. China loves Microsoft Windows XP so much, even Chinese government departments refused to give up their Microsoft Desktops, despite widely publicised suspicions that the USA uses hidden back doors in Microsoft Windows to spy on rivals.

The Chinese alternative to Microsoft was to be based on Linux. Linux is a terrific operating system. Linux is the dominant operating system in much of the server market. I use Linux extensively – when I am creating web technology server components for iPhone Apps and Android Apps.

However Linux never really made it as a desktop operating system. Outside of a few geeks, most people use Microsoft Windows or Mac computers. Linux never attracted a critical mass of desktop applications.

Or did it? There is a branch of Linux which did make it to the mass market – Android OS. All Android phones run Linux under the hood.

But Android is a phone operating system – what has this got to do with desktop computers?

It turns out that efforts are already underway to create a desktop version of Android. Android apps are very adaptable – they are designed to work on a wide variety of devices, with a huge variation in screen size. So making an app work on a desktop is not a big stretch – a small desktop monitor has a similar screen size to the largest Android pad devices.

Whether Android makes it on the desktop is still an open question – but unlike all previous attempts to displace Microsoft Windows, Android already has a very large, loyal following. Many people use Microsoft on their desktop, but have an Android phone, and love their Android Apps. The battle between Android and Microsoft for ownership of the desktop promises to be a popcorn event, rather than yet another Microsoft slam dunk.

So my advice to China – if you want independence from Windows, and the confidence of being able to examine and inspect every line of the code you are using, the solution may be right under your nose. Take a look at Android.

Why does my App Need a Website?

Every app needs a website, or a web page, to help promote the app, and sometimes to offer functionality which is more appropriately provided via the web than through the app.

What can a Website do for My App?

The most important job of your app website is to generate sales – to convert interest interest into a purchase decision. This means presenting your app in a positive way, extolling the features of your app, posting positive testimonials, and anything else that might convince someone to choose your app over your competition.

Why else might I Need a Website?

Sometimes apps need a web server component to function. This is usually because an app needs to share data with other copies of the app. For example, a messaging app would use a server to pass messages to the recipient.

The reason a server is required for sharing data is because apps usually don’t know how to find other copies of the same app. Every app with an internet connection has a presence on the Internet, but the actual internet address of the app is completely random – it could be any address the mobile phone provider or WIFI provider decides to assign.

However, every copy of the app knows where to find its server – the server has a fixed internet address, which is programmed into the app. So apps can use the server to contact each other, in the same way that people who don’t know each other’s address can agree to meet at a cafe they both know.

The other reason an app might need a server is if it needs access to data storage or computation power far greater than a mobile device can provide.

For example, an optical character recognition app might use a server to extract the text from scanned documents. Optical character recognition – extracting text from images – takes a large amount of computation effort, often too much effort for mobile devices to handle in a reasonable amount of time. The greater speed and power of a server can often more than make up for the time lost passing the scanned pictures from the mobile device to the server.

If the app uses a very large database, a server might be required to store the data. Usually where possible, data is stored inside the app, to reduce the need to access data across the internet. But if a very large amount of data is required, or searching the data requires a lot of computation effort, the data needs to be moved to a server.

Finally, a server can provide a safety backup, protection for your data in case you lose your phone or other mobile device.

What Website Technology Should I Use?

The answer depends on what you need the web server to do.

If your app does not need a server component, if your website is purely for app promotion, then use the WordPress Website. WordPress puts ordinary people in charge of the technology – it has grown to utterly dominate the web content provision market. With literally thousands of off the shelf plugins and extensions, offering a vast array of ready built features and functions, a lot of the time it is possible to create and maintain a sophisticated website with no software developer help whatsoever.

If your app does need a server component, then you will need a custom server. There is a large array of server options to choose from, including Amazon EC2, hosted servers, ISP provided servers. Your developer should advise you what solution best matches your needs. Where possible demand to use free technology – Linux or Free BSD. Avoid solutions which require a costly license, such as Microsoft, unless absolutely necessary, unless that is the only way to obtain a specific capability you require – there is no sense spending money unless you have to.

The great thing is, if you do require a custom server component, you can still use WordPress to manage the promotional side of your website. WordPress is also available as a free software package which can be installed on a third party server. Better, it is possible to mix WordPress functionality and custom website functionality, to make custom web pages blend seamlessly with your promotional website look and feel.

I want to know more!

For more information, please contact me on +61499650511, or click here to send me an email.