Community Tips

How Much Does It Cost To Appoint iOS Programmers?

If we consider the current scenario, then people nowadays utilize different categories of solutions to satisfy their purposes. Especially after the COVID – 19 pandemic, usage of smartphones has been bolstered to a considerable level. As a result, there was a massive rise witnessed in the utilization of applications among users. Since then, the usage pace has never slowed, and it has continued increasing till the current date.

It’s a truth to be told that Android devices are utilized in maximum numbers, but Apple devices are no more behind, as they stand second in global usage of smartphones. Over the past few years, the utilization of iOS applications has increased tremendously, and it’s because more than 1 billion users use iPhones, as per 2022 statistics. 

You might be fascinated to hire iOS programmers from an IT company for creating your business solutions and grab an advantage of rising requirements for iOS applications among users, which you might have derived from the figures mentioned earlier. 

So, refer to some things that should be kept in mind while hiring iOS developers and the cost of appointing them are discussed further in this post. Reading all those sections would reduce your hassles significantly for hiring them from firms to get an application for your enterprise ready.

Qualities To Be Considered While Hiring iOS Coders

When appointing iOS coders, you, as an entrepreneur, must ensure that they possess several characteristics to create your iOS solution for an enterprise. Which are those? They are stated below:

Must Possess Knowledge of Swift 3.0

It is an object-oriented programming language by Apple, which has a simpler syntax to access specific functions, making it easier for programmers to adopt. The iOS developers using Swift programming language can create a dynamic application loaded with demystifying features. So, you should appoint iOS coders having knowledge of Swift 3.0 and must be capable enough to deliver you the solution for your business with top-notch performance.

Experience in Xcode

You, as a startup owner, should know that the iOS coder you are looking to hire must possess Xcode IDE(Integrated Development Environment) in their skill sets. It is a solution that contains tools for debugging, interpretation, compiling, automation, and programming procedures streamlined for iOS developers while creating your application. By appointing iOS programmers to develop a solution for your business, you will also be charged a lesser fee for developing and deploying the platform, as Xcode makes such processes much more straightforward. It suggests that hiring iOS coders can assist you in building a platform with fewer expenses.

Problem-Solving Skills

Receiving the solution created by iOS developers is fine, but they should also be capable enough to quickly solve problems with any level of complexity. It is a must that you, as an entrepreneur, must appoint those iOS programmers who possess sufficient knowledge to get rid of any issue popping up in your application rapidly. 

Secured Application

You might be aware that the ios app store doesn’t allow an application to get published if it doesn’t match their set security standards. Hence, as an entrepreneur, ensure that the iOS coder you hire delivers a safe and secure platform to you or not for launching it in an application store.

By keeping all these things mentioned above in your mind, as a startup owner, you can look for iOS developers to hire from specific companies able to provide you with a helpful solution for your enterprise. It will assist you in appointing a perfect iOS programmer who is dedicated and skilled to offer you desirable and practical application for your venture.

Cost To Appoint iOS Programmers

Now, after knowing the several elements to remember while hiring iOS developers, you should see the cost of appointing them. There are numerous parameters that play a vital role in the costs of recruiting iOS programmers, out of which a few of them are mentioned below. Refer to each of them before analyzing the prices of iOS coders:


It is an essential component contributing to the cost of appointing an iOS coder to build a solution for your venture. The complicacy of an application includes:

  • The number and types of features.
  • The design of a platform.
  • Third-party apps to be integrated.
  • The specific database you select for storing user data of your application.

So, if you are thinking of building your iOS solution, then consider all these things about your app to be created. It will assist you in saving additional expenses after appointing iOS programmers.

Number of Coders

The cost also depends on a number of iOS programmers tenant by specific technology partners. The companies need to pay a certain amount to developers occupied working on your project, which relates to your application’s complexity, as discussed earlier. The rates of hiring iOS coders would likely be high if you want more attributes in your solution to be implemented, as a specific number of developers hired by you would not be able to work on other pending projects of the firm.


Based on how experienced an iOS programmer you have hired, the fees would be charged to you by them accordingly. It is because they will help you to avoid specific issues during and after creating the application for your business from their side. In addition, they will also provide you with a bugless application so that you don’t need to spend more money in the future to maintain your solution. Therefore, it’s suggestible that you should appoint a well-versed iOS developer that doesn’t charge much higher nor too lower fees for building your app.

Development Location

At last, along with covering all these factors, the cost to hire an iOS programmer is finally decided by the company, based on the development location. The charges for appointing an iOS developer from any specific country are determined based on their costs of living, hosting charges, and fees charged to them for accessing a particular function. Following are the rates of hiring iOS coders from different countries mentioned. Consider the table below to get an idea about appointing them from a specific location.

CountriesHourly Costs of iOS Developers(in $)
Australia$45 – $65
India$20 – $60
USA$60 – $90
Switzerland$55 – $80
Netherlands$50 – $75
Canada$35 – $70

Final Verdict

In the last few years, usage of iOS devices has skyrocketed to the next level, so numerous ventures have launched solutions in an Apple store to receive the advantages of increasing demand for its apps among people. Apart from this, many startup owners are planning to build their iOS applications for their enterprises, and if you are one of those, then refer to some qualities while appointing iOS programmers and the cost to select them mentioned in a post. It would help you in getting a clearer vision for hiring them.


Is the Indie App Opportunity Gone?

The app stores created an opportunity for any developer to build their own products and reach a global audience with them. For some developers this offered the promise of an independent app business, giving them creative control of their work and hopefully a comfortable income. Recently there have been lots of posts (great summary list here) from current and former independent app developers about the state of the market and how much harder it is to earn a living from your own apps. If it’s tough for established indie developers then is it still possible to get started? We’ll look at how the market has changed and share some data on the revenues of over 500 solopreneurs and small indie developers versus their bigger rivals.


The indie developer gold rush

[tweetable]A key advantage of small indie app developers is their agility[/tweetable]. They can shift their strategy to take advantage of new opportunities incredibly quickly. The success story that may have started the iOS app gold rush was built before there was an official SDK or App Store. Steve Demeter was working on ATM software for a bank and built the game Trism in his spare time, initially releasing it for free to the jailbreak community. When the App Store launched it was initially a $5 paid download that earned $250,000 in profits in the first two months. Demeter quit his day job to become one of the first full-time iOS indie app developers. Trism was reduced to $3 to stay competitive but went on to sell around 3 million copies. Four months of evenings and weekends, just a few weeks equivalent in full time development, earned a life-changing amount of money.

It’s the overnight success stories like these that continue to drive lottery-like behaviour from some developers. Playing for the outside chance of winning big. Even the media coverage at the time noted the increasing competition with more than 1500 iPhone games available in the App Store! Today’s developers would love so few apps to compete against; there are now hundreds of times as many.

Raising the bar

By 2011 life-changing solo developer success on the app store looked rather different. A $5 app created in a matter of weeks wouldn’t stand a chance. Andreas Illiger is a gifted musician, artist and coder. His Tiny Wings took 7 months of full time effort to create and sold for just $0.99. The increased scale of the platform meant he was able to sell more than 10 million copies. In 2014 it’s debatable whether a solo developer will ever repeat the feat. Monument Valley looks like the modern benchmark for a chart topping paid game title but developer UsTwo primarily serves clients in three countries and has over 100 staff in the London studio that created the game. Sirvo’s Threes! is a better comparison yet it was created by three people over a 14-month period (not full time). Threes! was almost immediately copied with numerous free alternatives to the $1.99 original springing up. Whilst Tiny Wings enjoyed a year as a top 10 game and another two inside the top 50, Threes! is already in danger of heading out of the top 100. [tweetable]There’s just so much free-to-play competition[/tweetable]. Making a more complex game to differentiate from the crowd is just beyond the scope of most small independent developers.

Not just games

Those examples have focussed on games and it’s tempting to think non-game apps might be a different story. However, consider that our data shows only 33% of developers are making games. Those developers collectively earn over 80% of store revenues across iOS and Android. So [tweetable]67% of developers are competing for less than 20% of store revenues[/tweetable].

Lets take a look at what Hunters (our name for developers that are aiming for direct revenues from their apps) can expect to earn at different company sizes.

As you can see, iOS is still a much healthier place for an indie app developer to be than Android but unless your cost of living is very low then the chances of making a comfortable living aren’t great. The bigger developers are taking over the top charts. [tweetable]If you’re outside the top app charts then it’s incredibly hard to get noticed[/tweetable]. Some of the successful smaller developers in our survey already have established apps with a strong history of downloads and ratings that keeps them high in the search results. If you’re just starting out, is it still possible to join them?

Find the right sized niche

The key difference with non-game apps is that they don’t all compete for the same attention. If your indie developer dream is to build the app you really want to use and be richly rewarded for it, you’d better have a fairly unusual problem that you want solved. Jared Sinclair’s Unread is the cautionary tale for those wanting to build for other technology lovers like themselves. An RSS reader (or client for any popular internet activity), however beautifully executed, has to compete with a vast array of free alternatives. Many of those other apps will have been built by hobbyists with no need to make any revenue at all. Anyone wanting to succeed as an indie developer today needs to think like a small business. Trying to compete with hobbyists is as futile as trying to compete with Google.

The right sized niche for an independent app is one that’s small enough not to be interesting to much bigger competitors but big enough to earn a living. Even winning the niche is not going to support a big team. The best niches will need specialist knowledge or intellectual property that make them both unattractive to hobbyists and defensible. Ben Thompson provides a great case study of Pleco, a Chinese dictionary app with some high-value in-app purchases. This example has two key advantages worth replicating: unique licensed content and a natural channel to market outside of the app stores.

What about getting rich?

If that sounds more like hard work than the indie developer dream of becoming an overnight app millionaire, it is. It’s also many, many times more likely to succeed. [tweetable]If you want to be an app millionaire then build contract apps for businesses and grow a team[/tweetable]. Then build some products for enterprise customers in niches that won’t attract immediate competition from much better funded rivals. Or get some venture capital and think really big! If you prefer the dream of being a millionaire, stick to building apps in your spare time. Better yet, buy a lottery ticket, it’s much less effort for about the same odds.

Business Platforms Tools

State of the Developer Nation: The App Economy Consolidates Before the Next Gold Rush

Our 7th Developer Economics survey broke all records again, reaching more than 10,000 app developers from 137 different countries. The full report with the survey findings has just been published and is available for free download!

The view of the app economy that they collectively provide is one of consolidation. Developers are focusing their attention on fewer platforms and app revenues are becoming increasingly concentrated amongst the top publishers. Consolidation in the developers tools sector may also be partly responsible for the decline we see in tools usage. This is also reflected by the platforms, with BlackBerry moving their focus away from consumer smartphones and Microsoft killing their recently acquired Asha and Nokia X platforms to double down on Windows Phone. Fortunately there are several indicators that the next gold rush is just getting started.

Platform Wars in the App Economy

On a global level the platform wars are ending with iOS claiming the majority of the high-end device market and Android winning almost everywhere else. This results in [tweetable]Android leading in developer mindshare at 70% with iOS a clear second with 51% of developers targeting the platform[/tweetable]. However, we’ve been tracking this metric since 2010 and there is a new pattern. [tweetable]Windows Phone was the only platform to gain developer mindshare, rising steadily to 28%[/tweetable], despite failing to gain device market share. Although Android and iOS lost developer mindshare, this was not fewer developers prioritising either platform, rather more developers are now choosing sides. The average number of platforms a developer targets has fallen from 2.9 to 2.2 over the last 12 months, with more than 40% only targeting a single platform.


BlackBerry 10 is rapidly leaking developer mindshare, down to 11%, having failed to gain traction with consumers. Meanwhile, it’s now becoming increasingly clear that [tweetable]the future of HTML5 lies beyond the browser[/tweetable]. Although HTML5 is used by 42% of developers as a technology for app development, only 15% still target mobile browsers as a distribution platform.

A surprisingly high 47% of iOS developers and 42% of Android developers are using something other than the native language on their platforms. While hybrid apps are the most popular non-native option for building Android and iOS apps, they’re only used by 13% of developers. Hybrid apps are HTML5 apps with a native wrapper, typically created by tools such as Cordova.


App Revenues

The majority of app businesses are not sustainable at current revenue levels. [tweetable]50% of iOS developers and 64% of Android developers are below the “app poverty line” of $500 per app per month[/tweetable]. 24% of developers interested in making money earn nothing at all. A further 23% make less than $100 per app per month. The overall app economy, including all revenue sources not just the app stores, is still growing but the revenues are highly concentrated. At the top end of the revenue scale there are just 1.6% of developers with apps earning more than $500k per month, collectively they earn multiples of the other 98.4% combined.


State of the Game Developer Nation

Games dominate app store revenues, yet most games developers struggle. [tweetable]33% of developers make games but 57% of those games make less than $500 per month[/tweetable]. Experience breeds success in the games market. The more games a developer has shipped the more likely they are to be financially successful. However, 70% of games developers have shipped less than 4 titles.

Games is a multi-platform world with the average games developer targeting 3 platforms versus 1.75 platforms for non-games developers. Multi-platform games benefit from cross-platform game development tools with Unity by far the most popular, used by 47% of developers. The next paid tool, Adobe Air, comes a distant second at 15%. Apple and Google’s latest graphics technologies launch a battle for the richest gaming experiences. Third party game development tools like Unity and the Unreal Engine will be key to developers exploiting these capabilities.


Tools of the App Developer Trade

Third-party tools are a critical part of successful app businesses. There’s a strong correlation between tool use and revenues, the more tools a developer uses, the more money they make. We successfully predicted the rise of the Mega-SDK, where consolidation amongst tools companies allows developers to integrate multiple tool categories from a single vendor. Despite this, tool use is declining, partly due to the rapid influx of new mobile developers. These new developers are typically not aware of the tools that are available and thus reduce the average usage levels. 26% of developers that are interested in making money don’t use any third party tools, up from 14% just 12 months ago.


The most popular category of tool is Ad Networks, with 30% of developers using them. However, this is one of the few tool categories that is not associated with higher than average revenues. More experienced and successful developers show a preference for Cloud Computing platforms, such as Amazon Web Services or Microsoft Azure, with 40% of those with 6+ years experience in mobile apps adopting them.

Enterprise Apps – The Next Gold Rush

[tweetable]Enterprise apps are already the safest bet in the app economy and they’re only just getting started[/tweetable]. 67% of mobile app developers primarily target consumers and 11% target professionals directly. The 16% of developers who target enterprises are twice as likely to be earning over $5k per app per month and almost 3 times as likely to earn more than $25k per app per month.


Penetration of enterprises with mobile devices and solutions is already broad but not yet deep. Currently iOS appears to be winning the battle for enterprise adoption and revenues. Yet many developers are focusing on the wrong platform with 10% more enterprise developers targeting Android than iOS. Although enterprise apps have been a historical strength for them, Microsoft and BlackBerry are seeing very weak adoption for their new platforms amongst enterprise developers due to lack of demand from enterprises.

This battle is in the very early stages. Microsoft is re-focussing on their core competence in productivity software while Apple and Google move rapidly to embrace enterprises. Google’s integration of Samsung’s Knox platform into the Android platform is a major step forward. Meanwhile Apple’s new partnership with IBM gives them a strong proposition in all the major vertical markets. These moves will undoubtedly drive greater adoption of mobile technology in enterprises and create countless opportunities for developers to help re-think the way we work.

For more information, download the full Developer Economics Q3 2014: State of the Developer Nation report and check out the war between the European and the Asian app economy.



Permissions in Mobile Ad SDKs

If you’ve ever tried to integrate a mobile ad SDK into your application, then you’ve definitely had to declare a few permission for it to work. Permissions in mobile platforms such as Android and iOS have been baked in from day one as a mean to control what applications could do or access on your phone, preventing despicable people getting access to your most personal and sensitive data. In this article, we will review what permissions are required to integrate 10 of the most popular mobile ad SDKs out there.


For the sake of clarity and consistency, we will use the Android SDK permissions. Since most of these mobile ad networks mirror their Android and iOS SDKs this is an acceptable simplification, so without further ado, let’s jump right in.


The Internet Permission

This is a no-brainer really. If any ad SDK is going to be able to serve real-time ads, then it has to be able to communicate with an adserver over the internet. It’s no surprise then that all 10/10 SDKs require this permission.

The Network State Permission

Accessing the network state simply means identifying if the device is connected to the internet. If the answer to this question is yes, then this permission can also be used to identify if the connection is through a WiFi or a Cellular connection. This is the second most common permission across our sample with 7/10 SDKs requiring this permission and another 2 listing it as optional.

Access WiFi State Permissions

Using this permission is another way to check if a user is connected to WiFi or not but is clearly not the most popular method as only 2 SDK mark this as required with another 3 making it optional.

Read Phone State Permission

A less popular permission as only 3 SDKs require this but nevertheless all three make this a requirement.

Access Coarse/Fine Location Permissions

This is a very important set of permissions. Traditionally location has played a key role in advertising but has an especially increasing importance in digital mobile advertising. It comes then as no surprise that 7/10 SDKs are interested in this permission. There is a clear trend here that these permissions are mainly optional permissions because they can be considered as more “intrusive” by users so developers tend to avoid them if not using them already. On the other side, including location info with an ad request can usually boost potential by a great deal so this situation can present a great dilemma.

Other Permissions

While the permissions mentioned above are the most popular ones, you may encounter some less frequent ones like write to external storage or even record audio. Throughout the 10 SDKs mentioned in this article, we measure 12 distinct permissions which is not a very big number considering that the Android OS has more than 100 available to declare.

Most SDKs that we have reviewed for this article have very reasonable permission requirements. Ultimately, it’s up to the app developers to find the sweet spot on what they will allow these SDKs to collect and if they are willing to introduce new permissions in their apps just for this. On the other hand, by doing so, app developers can realise a substantial boost in earnings due to more targeted and relevant ads, which can be a great thing for the end-users as well!


Understanding Swift: 5 things app developers should know

The most surprising thing to come out of Apple’s WWDC event this year was a new programming language for iOS and Mac development – Swift. To the sceptical this might not seem like anything more than a way to entice more new developers to build apps exclusively for Apple platforms and lock them in. While investment in developer tools is always partly about making a platform attractive to developers, this move has far more benefits and strategic implications.


1. What is Swift?

Swift is a statically typed, compiled language, interoperable with the Objective-C and C code that are currently used to build Apple’s platforms and the native apps that run on them. However, it also has the feel and features of more modern scripting languages. In creating Swift, Apple has attempted to give developers the best of both worlds, the performance of native code but the convenience and productivity of a scripting language.

2. Faster, Safer and Less Code

In fact, Apple claims that Swift is faster than Objective-C, yet at the same time developers are freed from the burden of explicitly declaring types (they’re inferred), or manually managing memory (it uses automatic reference counting). With features such as “optionals” (a generic way of checking if things exist before using them) and type safety (no default attempt at an implicit cast), the compiler is able to prevent many of the worst bugs that crop up in the C family of languages while reducing the amount of code that has to be written and maintained. Another productivity enhancing change from the legacy of C is the elimination of header files, keeping interface definitions and implementations in one place.

3. Interactive

Although reducing the amount of code required to perform simple tasks is productivity enhancing on its own, even greater benefits are obtained by reducing feedback cycles. In the same way that a simulator allows more rapid testing of new code and ideas than building for a device and installing, live coding environments provide almost instant feedback as the code is written. Such tools are not traditionally available to compiled languages but Apple has created “Playgrounds” for Swift. These don’t provide live coding for an entire app but allow developers to experiment with new algorithms or bits of UI in such an environment before copying them into an app. Similarly, whilst being able to inspect variables in a debugger is useful, it’s even better to be able to interact with an app while it’s running. Swift provides a REPL (Read-Eval-Print-Loop) for this, much like the debug console for JavaScript in most browser development tools.

4. Functional friendly

The language also has functions (and closures) as first class objects with a much more readable syntax than Objective-C’s blocks, making it easier to apply functional programming techniques. This could be particularly helpful for fans of Functional Reactive Programming (FRP) – a programming paradigm that has been gaining in popularity for app development amongst a lot of smart developers. It helps to eliminate complexity when dealing with things like user input and asynchronous network communication – two key areas for most mobile apps. A team at GitHub actually created an FRP library for Objective-C, called ReactiveCocoa, which is extremely well thought out but forced into the most painful syntax by the language.

5. What’s the catch?

Sounds a bit too good to be true, right? Being a compiled language and using reference counting, rather than a garbage collector, developers are still responsible for avoiding memory leaks due to strong reference cycles. These happen when two objects refer to one another, directly or via a chain of other objects. So, while the language may be beginner friendly, it makes it fairly easy to write code that leaks memory. To avoid this, developers need to understand how the memory is managed for them and how to break these cycles. It’s not horribly complex but it’s a long way from not having to worry about memory management at all. That said, most iOS apps will get away with leaking a bit of memory – usually the device will just silently kill them in the background when the memory is required for another app.

Being compatible with C and Objective-C makes Swift a fairly big language – there are quite a lot of concepts and bits of syntax to learn for a new developer, rather than one coming from an Objective-C background. Also, as a type safe language, Swift is going to be much less forgiving to the novice that would prefer the compiler just figured out what they meant when comparing the integer 1 with the floating point value 1.0 or the string “1”.

Swift is currently an iOS & Mac only proprietary language. Unlike Objective-C, which has an open source compiler and runtime (used by Apportable) there’s not likely to be any way to use the code on Android or other platforms. However, most developers wanting a cross-platform approach are unlikely to have started with Objective-C anyway, so this is not really creating significant extra lock-in. It might just persuade some developers choosing a cross-platform tool to target iOS because it’s easier, to create a fully native app instead.

Why does it matter?

First, more developers. Although modern Objective-C has a lot of good points, it’s an evolution of a very old language. Syntactically it’s quite different from most other modern languages – it borrowed from Smalltalk while the rest of the world followed C/C++. This creates a barrier to entry for developers in other languages because the code initially looks alien. Additionally, any language that has pointers is a hard sell and steep learning curve for complete beginners. Swift fixes those things and should make developing for Apple products attractive to an even wider audience.

Second, more productive developers. Greater productivity means lower cost of development and/or shorter time to market. The combination of more rapid development and lower fragmentation versus Android should help to keep iOS as the first platform developers target, even as its market share continues to shrink through the faster growth of Android globally. This is very important if Apple intends to stay exclusively at the premium end of the market.

Last but not least, happy developers. Although several cynical commentators have latched onto the proprietary language lock-in angle, it seems rather unlikely that giving developers a new language to learn is going to lock them into developing for a platform when the barrier to exit is, well, learning a new language! Instead consider that Apple is primarily aiming to retain developers through loyalty rather than lock-in with this particular move. It should not be underestimated how much good tools can contribute to the enjoyment of daily development work. If Swift can deliver on its promises then other platforms will have to be that much more attractive to tempt the best developers away.


App Security 101: A list of top 10 vulnerabilities and how to avoid them

App security 101

App development is becoming more and more popular, as web and software developers are migrating to the mobile industry. Apps have become a part of mainstream culture and entered our everyday lives – at increasing levels. The app economy is comprised of approximately 2 million apps and is expected to continue growing in the years to come.

Secure development on mobile applications, however, has not shown the same level of growth or maturity. As an Information Security firm, we’ve seen quite a few apps suffer from vulnerabilities that are linked to development bad practices, mainly due to lack of awareness. Secure development guidelines do exist in the community, while organisations like OWASP have accumulated a lot of experience in the field and are now offering much of this knowledge for free. In this article we’ll sum up the best practices and show you the best ways to build secure apps. We’ll concentrate on OWASP top 10 (and similar) vulnerabilities, as these are the most common ones found in mobile apps.

So, let’s go through the list of the top 10 mobile app vulnerabilities and how to avoid them.

1. Insecure Data Storage:

This vulnerability occurs because information that is considered confidential is not stored in the device in a secure manner. You shouldn’t assume that the devices themselves are safe. Devices can be stolen and/or tampered with, and the confidential data contained in them may be stolen. Also, you shouldn’t assume that users will protect themselves against this possibility. In order to avoid this vulnerability, the best practices are:

  • Never store credentials on the device itself
  • Sensitive information such as user authentication credentials should only be stored in the device’s keychain, using the necessary API
  • All authentication should be done through HTTPS (updated)

Specific guidelines for iOS developers:

  • You could avoid using iOS Encryption Libraries such as Commoncrypto
  • You should encrypt SQLite databases with SQLcipher
  • You might want to avoid NSUserDefaults, as well as plists in general
  • Keep in mind that the NSManagedObjects will be stored in an unencrypted database

For Android devs:

  • You should use the SD Card Storage the javax.crypto.
  • You can use the enterprise Android administration API to force encryption for local files by utilizing “setStorageEncryption”

2. Weak Server Side Controls

You should implement most controls against input attacks on the server side of the application. Nevertheless, app design should include input validation checks and controls, in order to reduce the load of work to be done by the server. Therefore, you could ensure that both the server side and the mobile client development security requirements include at minimum:

  • Input validation. You can use this kind of data validation in order to detect, and therefore prevent, unauthorized input before it gets processed by the app itself
  • Canonicalization. Data input in the app should be converted to its canonical (simplest) form in order to be processed by it
  • White lists on allowable data. The white list validation approach allows only specific types of data as input to the application; everything else that’s not included in this list, is not authorized.
  • Output encoding. You should encode the output that is presented to the user in order to prevent different kinds of attacks (e.g. XSS[1][2], format string attacks).

3. Insufficient Transport Layer Protection:

You should enforce the TLS/SSL encryption with strong algorithms between communications. A common development mistake is unencrypted connections from the application to 3d party companies. You should program your apps to display any certificate error or warning messages, so that the user is informed of the quality of the encrypted connection.

For iOS developers:

  • Use the CFNetwork API that utilizes NSStreamSocketSecurityLevelSSLv3 / TLSv1.2.
  • You should use,the setAllowsAnyHTTPSCertificate parameter to prohibit accepting all certificates

For Android developers:

  • You should set the AllowAllHostnameVerifier parameter to prohibit accepting all certificates

4. Client Side Injection

This category is comprised of a wide variety of input attacks against the application itself. General best practices for mitigation of client side injection vulnerabilities include the input validation of the application entry points, on the server side.

For iOS developers:

  • You should consider using parameterized queries (e.g. ? instead of %@, libXML2 instead of NSXMLParser)
  • In addition, you should avoid functions that are known to be prone to code vulnerabilities, such as strcat, strcpy, etc.

Android developers:

  • You should use parameterized queries
  • You should disable Javascript and plugin support for Webviews
  • You should also disable file system access for Webviews
  • You might consider using input validated intent filters between Activities

5. Poor Authorization and Authentication

These vulnerabilities are controlled mostly on the server side. The best practices that you should follow are the same with web applications. In addition to these rules, specifically for app development, device identifiers should be avoided (UDID, IPs, MAC Addresses, IMEI) since devices can be stolen and tampered with. Finally, out-of-band authentication tokens should not be sent to the same device.

6. Improper Session Handling

Although session handling mechanisms are mainly applied at the server side of the applications, secure session management practices can be applied at the devices themselves. As with the Authorization and Authentication, you should apply the web application Best Practices for session handling. Same as with authorisation and authentication best practices, device identifiers should be avoided here as well and you should implement safe mechanisms to revoke session on lost/stolen devices. Finally, the Confidentiality and Integrity of session tokens should be protected at all times (secure transmission via SSL/TLS connections, etc).

7. Security Decisions Via Untrusted Inputs

While these issues mainly affect Android-based applications, there has been precedent for iOS apps too. In general, the Best Practices that you should follow are the same with the web application ones. Specifically, input validation, output escaping, authorization controls and canonicalization should be carefully examined. Also, you should exercise extra caution when validating and accepting URL schemes.

8. Side Channel Data Leakage

This category involves data exchange that usually enhances app performance (e.g.: keystroke logging, web caches). As with Insecure Data Storage, you should build your app under the assumption that the device might be stolen. All side channels and 3rd party libraries included should be identified and enumerated for any possible data leakage that might occur. The application should be dynamically tested in order to verify that it doesn’t leak data during runtime.

iOS developers:

  • You might consider disabling screenshots, along with cut-and-paste buffers. It is also recommended to disable keystroke logging from within the application.

9. Broken Cryptography

Crypto-keys should never be hard-coded in any construct (plaintext, property files, compiled binaries) and should be controlled at the server side.

10. Sensitive Information Disclosure

Different kinds of information may be considered sensitive in an app, as application logic/business purposes define that. You should keep mind that apps can be reverse-engineered and information like this might be exposed. The best practices in this case suggest avoiding storing private data inside the device; unless absolutely necessary.

The vulnerabilities presented here are not an exhaustive list – they’re just the tip of the iceberg! During the past year, we’ve witnessed numerous attacks against apps by direct code exploitation that usually leads to the device becoming compromised. We’ve also seen attacks that leverage various app weaknesses in order to hijack legitimate user sessions and steal information and money.

Since the app market is constantly growing, we expect to see an increase in the number of attacks against mobile devices themselves. So, if you want to keep up with the times, [tweetable]you should build your next apps with app security in mind[/tweetable].

For more insights, get in touch.

– George

George Karagiannidis is a Senior Information Security Consultant at TwelveSec ( George is a seasoned pen-tester, having accumulated a wealth of experience from performing, as well as leading, Information Security projects that range from System/Network/Web/Mobile Application Penetration Tests to Reverse Engineering, Security Design and Architecture of critical Information Systems, and Information Security Management System (ISMS) implementation.


The Android Monetisation Myth: iOS still rules the west

[tweetable]Revenues from Android apps saw tremendous growth in 2013[/tweetable]. If you look at the headline global figures then revenues from Android apps on Google Play are rapidly closing on those from iOS apps on the App Store. It looks extremely likely that 2014 is the year that Android will overtake iOS in total app revenues. However, dig a little deeper and you’ll find the distribution of revenues, both geographically and across apps is rather different. If you’re planning your platform strategy for this year then a dive into the details might prove invaluable.

Almost a year ago, I wrote about two important app market trends to watch in 2013, which were continued growth of app revenues (they’re still growing, Android significantly faster than iOS) and revenue distribution (it’s getting even more concentrated at the top). According to Distimo:

“On a typical day in November 2013, we estimate the global revenues for the top 200 grossing apps in the Apple App Store at over $18M. For Google Play, our estimate is about $12M. In November 2012, these estimates were at $15M for the Apple App Store and only at $3.5M for Google Play.

That’s 20% annual growth at the top of the market for iOS and just over 240% annual growth for Android. Add to that there are also alternate stores for Android that have been growing revenues too. These figures and relative growth rates make it seem as if Android is the place to be in 2014. It might be, if you can make it to the very top. If we look at AppAnnie’s report for a similar period, they estimate that total iOS App Store revenues roughly doubled year over year*, while total Google Play revenues were a bit more than triple their year ago levels. So although Apple seems to be improving the revenue distribution slightly, it’s getting even more concentrated at the top of the market on Android.

Even the wider distribution of revenues on iOS may not be quite as good as it looks when we also consider geographic spread. Although the US is still the top revenue earner for iOS, the bulk of the growth is in Asia, particularly China and Japan. The top grossing charts in these countries look very different from the global top grossing apps and this may account for much of the widening range of high revenue apps. [tweetable]On Android, the bulk of the growth and total revenue is in Asia and thus so are the top grossing apps[/tweetable]. Japan has overtaken the US as the top revenue earning country for apps overall mostly due to growth on Android. The vast majority of the increased revenue is in free-to-play games and App Annie’s report shows that in Japan, almost all of this was attributable to just five publishers. Two of those publishers were existing major games powerhouses before the mobile era and they have several well known franchises. Two more reached the kind of scale where TV advertising became a viable route to market and exploded from there. The last of the five is LINE, who built a messaging platform with over 300 million users as a channel to promote their games.

This concentration of revenues amongst five publishers in Japan is mirrored elsewhere in the world. Consider Supercell (makers of Clash of Clans and Hay Day) were at $2.4M per day in revenues in April 2013, when they were still only publishing on iOS (they’ve since launched on Android) and were in the middle of expanding through Asia. That’s more than 10% of daily global App Store revenues for the top 200 grossing apps made by one publisher with 2 apps. Supercell aren’t unique either – according to Think Gaming’s estimates,’s Candy Crush Saga is making more than $900k per day, just on iOS in the US. Indeed Think Gaming give us a better idea of the distribution. Their estimates show that the number 10 grossing game makes only a 10th as much as the top grossing game and by number 100 you’re down to nearly 100th of the revenue.

So, with revenue concentration at the top of the charts on Android even greater than on iOS, Android is the platform to target if you’ve got a world beating app with global appeal on your hands. Otherwise you’re almost certainly still better off on iOS first. Our own data, which considers revenue sources outside the app stores as well, agrees with this. If we only include the publishers earning less than $5M per month then iOS comes out on top, although if we include everyone with non-zero revenues then Android sneaks ahead. Significantly higher revenues for a tiny number of top Android developers pushes the average ahead of iOS (although the median remains way behind – there were more iOS than Android developers earning >$5M per month in our survey).

Android may become the top earning platform from App Stores in 2014 but it seems that only an elite few developers will reap the rewards. We’ve already shown that building enterprise apps and avoiding the app stores is a better bet financially but Android is not currently a lucrative platform in the enterprise market either. Still, it’s not all bad news for Android developers – the rising tide of revenues will lift all boats to some degree. Also, even 2014’s cheap Android device should be running at least Android 4.0 and have hardware capable of running almost any app well. This should reduce costs and increase the real addressable market for all Android developers. Last but not least, for an increasing number of developers [tweetable]it’s not a question of Android or iOS, it’s becoming ever more important to target both[/tweetable].

* Distimo’s year was November to November, while App Annie’s was October to October, so there may be some impacts from the relative timing of new product introductions.


Is Android First Really a Myth?

Popular perception in the tech press is that iOS gets all the best apps first. With Android market share beginning to dwarf that of iOS globally, there’s lots of speculation around when developers will switch to Android first. Our data shows iOS is still the priority for startups in the U.S. but that doesn’t necessarily apply outside the high-growth consumer app market, or elsewhere around the globe.


The importance of platform priority

Just over a week ago, Steve Cheney wrote the very widely shared “Why Android First is a Myth”. The post makes some well-reasoned points about an important issue for the future of the smartphone market. One of the things that makes iOS attractive to a significant subset of early adopters is that it gets most apps ahead of other platforms, sometimes exclusively. [tweetable]If most developers start targeting Android ahead of iOS then those users will switch platforms, taking their app and service spending with them[/tweetable]. Where the early adopters go, most of the rest of the market will eventually follow. As such, developer priorities are considered an early indicator of platform fortunes, particularly at the high end. So if, as Steve suggests, iOS is set to dominate Android in this area for many years yet then Apple will keep making the bulk of the profit in the smartphone market. So is he right?

Silicon Valley doesn’t dominate apps globally

The major problem with the “Why Android First is a Myth” argument is that it is incredibly Silicon-Valley-centric. Whilst the two major smartphone platforms may be developed in Silicon Valley and dominate globally, the content and services used on them does not follow that pattern. Although there are lots of apps in common between U.S. and European app store top charts, there’s still plenty of highly ranked local content in most countries. Looking at the top grossing charts of massive smartphone markets like South Korea, Japan & China, U.S. users would struggle to recognise the name of any publisher (major exceptions being Supercell and from Finland and the U.K. respectively). Not only is the assumption that the apps that make a platform attractive are going to come from the U.S. (or even “the West”) flawed, the assumption that they’ll primarily come from “sophisticated startups” is as well.

Mobile messaging services provide a good example. While VC funded startups may be the way many new services get built in the U.S., WhatsApp being a typical case, the global competition is rather different. KakaoTalk comes from a startup of sorts, although founded by a former CEO of Korea’s internet giant NHN, while LINE came from the Japanese subsidiary of that same Korean internet giant. WeChat comes from Tencent, China’s largest internet company and one of the biggest in the world. It’s more than just how the apps get funded and built though, it’s the types of apps too. The breadth and depth of the app offering on a platform is essential to have all the apps that are important to any individual user, whether it be an app from their bank or niche apps catering to their interests. Otherwise the Windows Phone strategy of paying for the most popular apps to be ported would be a lot more successful. As Paul Graham says, VC funded startups are all about growth, so they have to address issues that they believe are relevant to very large markets. They don’t build more niche or local apps and they don’t build the essential extensions of existing services to mobile devices. This suggests that the platform preferences of a much wider range of developers are important, not just the “sophisticated” startup developers.

Global platform preferences

With this in mind, VisionMobile has a great source of data for monitoring this important platform priority trend. Our regular Developer Economics surveys ask thousands of developers to rank the platforms they use in priority order. Just looking at the data from the last survey on which platforms are most frequently cited as primary by developers in each country we can see strong geographic patterns.

[tweetable]In almost all countries there are a significant fraction of developers who treat Android as their primary platform[/tweetable] and overall the number of developers with iOS and Android as primary platform is almost exactly even. This is biased by a large number of Hobbyists and Explorers* who overwhelmingly prefer Android, largely because it costs less to get started and the platform is more open. As such, iOS still leads by a decent margin (39% vs 32%) amongst those full time developers trying to build or grow businesses. However, this is not true everywhere with South America being dominated by mobile web developers and most of Asia ruled by Android. Europe is fairly evenly split between the two platforms. Most countries’ developer populations follow local user preferences with a slight bias towards iOS. A major exception is Russia, where iOS penetration is low but developers have an unusually high preference for the platform – this is not just outsourced development either; good technical education, a low cost of living and access to affluent global markets seems to be a great combination for smaller independent developers too.

What about startups?

Finally, if we’re purely talking about startups (or Gold Seekers in our segmentation) then iOS is clearly preferred to Android in North America. Out of those with iOS or Android as their primary platform, 70% are iOS first versus the 30% starting with Android. By the same metric, Asia has a 66% majority of Android first startups and Europe is split 50/50. Although our data set for this particular segment might not be large enough to be comprehensive, it’s clear that “Android First” developers are far from mythical!

If you work in a startup cluster and don’t agree with our numbers then please leave us a comment.

* Explorers are part time mobile app developers with a different day job – for more information on developer segments and their preferences see our segmentation report.

Platforms Tools

Mobile Platform Wars: Winners & Losers in 2012

[This post first appeared on the VisionMobile blog on 9 July 2012.] The game of ecosystems is in full bloom, with each player attempting to draw as many developers as possible around their platform. As we finally see some signs of consolidation, VisionMobile Senior Analyst Andreas Pappas, talks about mobile platform wars, the rules of engagement and identifies the winners and losers in this game of ecosystems in 2012.

Moreover, we’re proud to introduce VisionMobile Visualisations – live. These are interactive graphs with tons of data from the Developer Economics 2012 research!