The Need to Go Mobile

The Need to Go Mobile

The Mobile boom is well upon us and is part of the reason companies, both large and small are accelerating their mobile application strategies. That being said, enterprises are deeply involved in mobilizing applications that are already existing and in many cases are going with the mobile-first concept in developing new applications for licensing or internal use. This mobile-first strategy is quickly establishing mobile as the platform of choice for enterprise applications.

Now is the time that both companies large and small must understand the importance and necessity for going mobile. Beyond just going mobile, organizations must understand the ROI they stand to gain by mobilizing their enterprise applications, whether they be cloud or software-based.

Check out this whitepaper: Developing Mobile Applications

Your Users

The most important step when developing apps out of enterprise applications is knowing your audience and identifying who are your users. Are they internal, external or both? The bottom line is that mobile devices are not just about convenience. They are also about productivity. You want to be able to get the most out of your workforce. There are a plethora of business models that are based around the knowledge of users. These users are much of the time, if not all the time mobile.

When you make them more productive, they can bring more value to the organization internally, as well as externally to partners and customers.

Externally, you want to create mobile engagement that is slick and turn-key. You partners and customers must be able to access the most current data, get information about such things as shipments, delivery dates and contact information. You want to be able to empower your external user base. This will increase engagement and make them more loyal.

Choosing What to Mobilize

Next, you need to decide which applications or parts of should be mobilized to best benefit your users.

There is no shortage of corporations that are developing such a diverse mix of applications, and in some cases, thousands of them. To mobilize them in a timely manner is simply impossible. That is why it is paramount that you choose the business processes you see as the most ripe for mobilization.

Much of the time users just need access to data, so you would want to conduct an analysis of what data they need to access and to provide a mobile experience that gives them what they want when they need it most.

Many times, users just need access to sections of the most robust applications that they will utilize on the go. Whether they need access to just data, parts or all of enterprise applications, what needs to be provided to the users is data and/or access to applications on demand, whether they are offline or online.

Organizations also must decide which devices they will develop applications for, that will most increase the productivity of the users and give them unfettered access on the device they want, when they want, be it an iPad, iPhone or Android.

 

 

Mobile Testing Challenges – Surviving the Mad App Rush

Mobile Testing Challenges – Surviving the Mad App Rush

The rising popularity of smartphones presents a wealth of opportunities for app developers and publishers. As with most opportunities, there is no shortage of challenges. We’ve noted some of them below.

The primary challenge and the one we will go into the most in this post, is testing these apps, so that they work in all your target market environments.

Now, while a tester who is used to testing web applications gives them a leg up on other testers with no experience, mobile testing is a completely different ball game. In the web world, a tester might have to test a handful of web browsers. When the complexity of different devices, operating systems, and models is introduced, this creates a challenge of paramount proportions.

This is especially the case with the Android and Windows mobile platforms, where companies such as Samsung and Nokia dominate the market. We are not just talking about different devices. We are talking about the multiple operating systems that are resident on the devices of your target market.

One way, which is highly common in testing the array of devices, is by using device emulation. While emulation is less expensive, there is a reason for it. Nothing beats the real thing. With emulation there is always the high chance that your testing might not come close to a real life environment that is needed to test.

Research. Research. Research.

One way to cut down this hassle is to research your target market. Say, you are releasing an app to the Swedish market that delivers meatballs to you door, hot and ready to eat.

You discover that by conducting some research that Swedish mobile users mostly have Samsung and Nokia issued devices. In this case, you should test on the most used device models, indicating it in the app store description. You might want to say that specific devices have been tested and more are being tested. You cannot guarantee the successful use of the app on phones not specified.

Another important thing you should research are the most commonly used network protocols. You wouldn’t want to have built your app with the 3G network in mind for connection, when 3G doesn’t even exist in one of your primary target markets.

The Mad App Rush

Because bringing an app to market is almost always based on timing, there are mad rushes to the app finish line. With this release frequency, comes the heightened confusion regarding testing among the team, which could lead to a buggy release if things are not done precisely. Remember, there is no room for error. If you release a buggy app, you might just get booted out of the app store where you are publishing.

Additionally, functional testing isn’t the only type of testing you should be conducting. After the app is launched, utilizing an in-app analytics tool is key to optimizing the mobile user experience.

Remember, you only have one chance to make a first impression. This statement looms large over the mobile app sphere. If your app doesn’t work upon launch, as the user perceives it should, you may have just lost a customer, never to return.

 

5 Tips for Developing a Mobile Enterprise Solution

5 Tips for Developing a Mobile Enterprise Solution

In business, ideas are the impetus for great things, things that are so great and all encompassing that they change the world. Over the past few years, this idea has been mobile, which is indeed changing the world. It is changing the way people communicate, the way they consume media, the way they shop, work and live.

It is also changing the way enterprises do business. Developing a cohesive 360 degree mobile solution is something that much of the time eludes enterprises both large and small. In the age of BYOD (Bring Your Own Device) it is paramount that you hop on the mobile train or get left behind.

Estimates by analysts predict that mobile devices will be utilizing business applications at a rate of over 50%. Many enterprises are seizing the opportunity to implement business-based programs that maximize use of mobile. A large part of the reason is that enterprises today identify mobile as a technology that gives them an opportunity to mold their business in new ways and create practices that will ultimately maximize their offering to their customer base.

Below are 5 actionable tips to guide you in your quest for developing a mobile enterprise solution:

• Identify the mobile habits of key industry leaders and see how they are utilizing mobile to solidify relationships among partners, customers and suppliers.

• Make sure you implement the appropriate safeguards for security as well as support to enable you to manage mobile more effectively and in a way that is scalable as your enterprise grows.

• Constantly request feedback from end users. What are they happy with? What not so? What challenges are they facing? This will allow you to extend the mobile footprint within your enterprise.

• Give both light and heavy users of any ERP systems you might be using the ability to access information, wherever they are, whenever. This will give them the power to act upon any information in real time from any location. Get their feedback and refine as needed.

• Gain in depth understanding of your business’s essential needs. Learn what your staff needs to access remotely. Give users the ability to extend all communication beyond the desktop to increase their effectiveness in getting tasks done. This should be implemented no matter where they are or what device they are using.

By following these tips, you’ll be well on your way to implementing a solid enterprise mobile solution.

 

How to Successfully Outsource Mobile App Development

How to Successfully Outsource Mobile App Development

Outsourcing mobile app developmentIn my previous blog, I talked about the pros and cons of in-house app development vs outsourcing. So, say you’ve opted to outsource. You like that it’s cheaper and doesn’t require you to give up your best developers for the job. Now, the only question is how to outsource the development successfully so that you get what you want at a price that fits.

So without further ado, here are the 3 tips I can offer to guarantee successful outsourcing of your mobile app.

  • Selecting the right mobile app developer

Likely, your decision to outsource development stemmed from a need to reduce costs. Just remember, you get what you pay for! That’s not to say you have to go with the most expensive bid, but you should also be wary of the cheapest bid. To help figure out how much you should be budgeting for this task, try this simple equation.

(Selling price  X  Expected number of downloads)  +  download revenues  =  break even dev cost

Choose a developer that can do a quality job at the right price.

  • Provide clear specifications

You lose some control by outsourcing so it’s crucial to be as precise as possible. The developer will do exactly what is asked so make sure you fully understand the scope of the project you’re outsourcing. Simply put, make sure the developer can answer the following questions:

  1. What is your app supposed to do?
  2. What is your app supposed to look like?
  3. Who are the target audience?

The clearer your specifications, the less likely you’ll be to spend extra money on reiterations.

  • Don’t forget the NDA

Sign a non-disclosure agreement with your developer to ensure your app remains confidential and secure. All developers working on your project should sign on the dotted line.

Have you outsourced mobile app development? What has your experience been? Let us know in the comment section below!

How Much Does it Cost to Develop a Mobile App?

How Much Does it Cost to Develop a Mobile App?

app costI love this question. It’s somewhat akin to walking into a realtor’s office and asking, ‘how much does it cost to buy a house?’ or visiting a car dealership and inquiring about the cost of a car. Where do you want to buy a house? How many bedrooms? Do you want the luxury SUV or a little sports car? There are some approximate guidelines but the answer to this question is not as clean cut as the question requests. There are just too many variables.

To learn more about mobilizing enterprise applications download our whitepaper here

According to a guest blog on TechCrunch by former CEO of AppVee and AndroidApps, Alex Ahlund, a survey of 96 mobile app developers found that the average cost to develop an app was $6,453.  Another article reports that developing a “small app” can cost $3000 – $8000. More complex apps can cost anywhere from $50,000 to $150,000!

I’m guessing that you are clearing your throat right now to swallow the thought of such an expense. It is a lot of money but let’s break it down. The average app developer in the US charges around $100 an hour. The more complex the app, the more time required to create it which means a higher bill at the end of the day. When you’re developer shopping, you should have a good idea of what you want to create. This may seem like a given but I’ll spell it out just in case. If you want your app to stand apart from the other 500,000 in the app store, you’ll have to consider:

  • Integration with a back-end database
  • Development on multiple platforms (iPhone, Android, BlackBerry)
  • Design and animation
  • Versions (free, paid, something in between)

Do you have an app idea and want to know how much it will cost? Contact the Astegic team to find out what is involved in bringing your idea to life.

To learn more about mobilizing enterprise applications download our whitepaper here

Native vs. HTML5 – looked at objectively, the debate is over

Native vs. HTML5 – looked at objectively, the debate is over

Posted by Jonathan Rende on Fri, Apr 12, 2013 @ 04:45 PM

Almost a year ago I wrote a white paper about Native versus HTML5 mobile app development, asking ‘Which option is best?’

Even then, the answer was pretty obvious: look at the question objectively, using a set of clear comparisons, and HTML5 is crushed by native development, even though HTML5 wins on a few points.

Strangely, though, the debate rages on. Just this month, ReadWrite’s Brian S. Hall felt the need to discuss “The Facebook Phone & The Triumph Of Native Apps Over HTML5” as if the issue had yet to be settled.

You could argue that triumph was already clear last August, when Facebook itself abandoned HTML5 for its rebuilt native iOS app. But bloggers and consultants continue debating the question, and customers still ask me about which way they should go.

Why are we still having this debate? My take is that it’s like a religious war, where people aren’t really interested in debating the actual facts. If you do take a serious, evidence-based look at the data that’s available, though, it’s not hard to settle the issue once and for all.

The power of numbers  

A good place to start is with app growth. A recent round up in Information Week  counted 775,000 apps now available in Apple’s App Store and roughly the same number in Google’s Play Store. Add the 135,000 claimed by Microsoft and Blackberry’s 100,000, and you get 1,785,000 native apps in the marketplace.

It’s harder to quantify how many HTML apps are out there. But in a 2012 Appcelerator survey of 3,600+ developers working in both the native and HTML5 space, we found that developers were actively writing roughly 6% of their applications in HTML5. Even if you assume that HTML development has always been as popular as native and then double that figure for a wide margin of error, the total number of HTML5 apps now available still would only just clear 200,000.

Shear volume is on the side of native solutions, then, and I’ve seen no evidence to suggest that that’s shifting. App downloads, meanwhile grew 11% in Q1 2013 over Q4 2012.

 

Nine points of comparison 

But there are plenty of other ways in which native- and HTML-developed apps get compared. In my research, I’ve found nine of points of comparison where it’s possible to make objective calls as to which is superior:

1) Rich user experience (native wins)

85% of mobile professionals in a March, 2013 Compuware survey preferred mobile apps over mobile websites. One of the main reasons was the richer experience users get with native apps. Features like VR, NFC, and passport simply aren’t available in HTML. Where HTML has 30-50 native device capabilities open to it, native developers have access to 6,000-7,000.

2) Performance (native wins)

When it comes to both loading and rendering, whether you have good, weak, or terrible internet access, native is always faster. Click on a calendar event in a native app, for example, and it opens instantly. The time it takes to do the same in an HTML app typically drives people nuts.

3) Monetization for developers (native wins)

Recent numbers from Canalys report that native app developers’ combined income in Q1 2013 was $2.2 billion. In contrast, the monetization available to developers building HTML5 apps is essentially zero. It’s pretty obvious, then, that financially ambitious app owners need a massive incentive to move out of the app store fold.

4) Cross platform development costs (HTML wins, but by less than you’d think)

This is usually seen as a big point in HTML’s favor. The line is that you ‘write once, run anywhere,’ and that’s true, but only up to a point. You certainly have to factor in costs for going native for multiple OSs, although solutions like Appcelerator will help reduce those costs significantly. But they are not zero with HTML5, either, thanks to the next point of comparison: fragmentation.

5) Fragmentation challenges (a wash)

If it’s a challenge to develop apps for multiple platforms (and for different versions of those platforms), even with Appcelerator’s help, it’s not the case that developers writing for the mobile web are writing simply for one HTML5. There are at least 15 mobile browsers in existence, each available in different versions and each supporting different levels of HTML. So there’s a fragmentation challenge with both. On this measure, the two are pretty much a wash.

6) Availability of programming expertise (HTML wins)

There’s no debate here. There are millions of HTML developers out there who will look at HTML5 and say, ‘eureka, I can now develop mobile apps.’ Objective-C, meanwhile, and to some degree Java, are much harder to learn, and people who know them are harder to find and cost more to hire. Again, solutions like Appcelerator’s address this by using JavaScript, a language that pretty much every web developer knows well, but the overall comparison still favors HTML5.

7) Immediate updates & distribution control (HTML wins)

Mobile is all about constantly innovating. Because they don’t sit on the device, HTML5 apps can be instantly updated. In contrast, having to go an app store for an update remains a barrier to offering the best, most up-to-date experience. A win, then, for HTML.

8) Timely access to new OS innovations (native wins big)

Apple and Google offer, on average, 1-3 updates a year that offer major new capabilities. When they are making so much money from their app businesses (see #3 above), they have every incentive to coral those new capabilities within their native OSs and zero incentive to offer them in HTML. Meanwhile, it takes years for the HTML consortium to ratify new standards. At the rate at which device manufacturers are innovating, there’s no way that the HTML consortium can move swiftly enough to compete.

9) Security (native wins big)

People are increasingly worried about security, especially as mobile moves ever further into the enterprise and, frankly, there is no way that anyone could say that HTML is more secure than a native app. Native clearly wins thanks to:

– the security of the source code of itself; browser source code is open for all to see, and to then work around.

– the security of data at rest on the device; on a native app, it’s completely secure. In HTML, the browser is typically not secure and as a result exposes the data it’s accessing within its caches.

– the security of data in transit; when using HTML, you are pretty much restricted to using SSL. VPNs are just too slow. With native apps, you can also run VPNs and other encrypted solutions, without ruining performance.

– URL security vulnerabilities; these are unique to web applications and beloved by hackers. Native apps simply don’t have them, so hackers can’t get into native apps in the same way.

From my perspective, that last set of comparisons are the final nail in the HTML5 coffin. It’s clear that from a security perspective, native is the only way to go.

Overall, it’s a strong 5 to 3 win for native development, with one comparison a wash. The icing on the cake is the shear number of native apps now out there and the low current developer interest in building on HTML5.

Looked at objectively, then, the world has already spoken on native versus HTML5, and it’s bizarre that some people seem to be confused about this still.

At Appcelerator we continue to support developers however they want to build their apps and we believe that HTML will continue to have value in niche areas. But we also believe that success and innovation is built on a solid grasp of the facts; and here they indicate a strong advantage for native development, and have done for a while.

Given the evidence, it makes you wonder: why are we even debating this any more?

Jonathan Rende is the VP of Products at Appcelerator.

Who can unify my communications?

Who can unify my communications?

Posted by Perry Nalevka

As I start writing this blog post I find myself surrounded with devices – Smartphone, Tablet, laptop, TV and a desk phone.  This provides me with great flexibility in the way I can communicate and get my work done but I can’t help but notice that the user experience needs much improvement to allow a smoother transition between screens.

Vendors are doing a good job of making services available on multiple devices but need to spend more time and effort in the fine details. It’s great that when someone sends me a message I can receive it on all of my devices, but do I really have to see the notification in three different places AFTER I have read the message. Isn’t it a little strange when I’m chatting with someone on my iPad to receive the notifications about it on my laptop & smart phone? Shouldn’t it be easier to see all of your conversations with someone in one place.

The idea of unified communications has been around for a long time now, but it hasn’t kept up with the times. When all of the communications was clearly contained “inside the network” this was easier to control and manage but now that much of the communication is happening on top of the network and intelligence has moved into the client the problem got more complex.

It’s clearly time for some innovation here. In the short term vendors will need to respond by ensuring that their service is available in every device and through strategic partnerships and service integrations but ultimately there needs to be some true unification. The question is, will this come from one of the many software startups or will it be enabled in the network (and in which one). In short who will unify my communication?

Mobile Testing & QA Tools – Should I be using automation?

Mobile Testing & QA Tools

mobile-headerI am not going to answer the above question as there is not right answer but hope to have a conversation that will help answer for those asking. With the smartphone revolution upon us and the multitude of applications being released on a daily basis there is an increasing need for tools and automation to test all of these mobile applications. We are partnering and continuously vetting out tools for our customers.  One thing I can see now after 8 years in this space is that there is not one tool that is perfect or that can be called the best.  This is because it highly depends on the application.

Some questions are:

  • What parts of the app can be tested through automation?
  • Is location relevant?
  • 2G, 3G, Wifi, LTE or is connectivity available?
  • Does usability need to be tested?
  • Is this an enterprise or consumer app
  • How important is security
  • Does the backend need to be stress tested?

These are only some questions – please feel free to add more.

I have seen the tools fall into 3 categories with each one having a multitude of solutions:

  • Crowd Testing
  • Remote access to devices
  • Mobile QA / Test automation

Mobile Testing – Automation or Manual

Mobile Testing – Automation or Manual

Posted by Perry Nalevka on 

mobile-application-testing1-300x222

In previous posts we wrote that there is not enough testing being done in the mobile space but we see that the trend is changing as more outsource vendors (like us) are offering Mobile QA as a service.  The next problem I am seeing is that most testing being done today is manual which creates a lot of delay in today’s agile development world.  Although some manual testing will always be needed there is definitely room for more automation.  What’s driving more a more companies toward test automation is also the ever shrinking release cycle they’re facing for their mobile apps. Whether it’s a mobile web app which can see multiple versions per day, or a native/hybrid app which can be released any other week, the need for continuous feedback is critical.