There is no question that smartphones and other mobile devices are, and will continue to be, the gateway to the Internet and its wealth of services for the long term. Globally, smartphone usage is nearing 50%. Within major developed countries, smartphone usage is at or above 70%.
What do all these users have in common? Applications – apps. Mobile users generally use targeted applications for accessing network data rather than a browser. You want to quickly find the price for a flight to Cabo? Mobile users are likely to use apps like Hipmunk, Skyscanner or a price tracker like Hopper than a search engine like Google – even though Google does offer a flight search tool directly. And, mobile users tend to share information about the apps they are using with their friends, regardless of the platform they are using. The guy searching for a flight on his iPhone will share the information he has found with his friend, who is also interested, but uses an Android-based smartphone. If their friend wants the same information presented in the same way, the easiest way to get it is to simply search for the app on their platform and download it.
Knowing this, application developers tend to build applications for multiple platforms, or at least for the two major platforms, Android and iOS. By addressing these two platforms, their availability covers at least 80% of the market. In addition, most mobile apps use backend services that provide the “heavy lifting” of accessing, formatting and contextualizing of the data they receive when they answer user requests.
In application development, this kind of scenario can create many issues. If the development group does not have an established pool of highly experienced, cross-platform developers, it could mean they will need 2-3 teams that must stay in constant sync, or they will need to use a cross-platform development tool and environment. All three strategies have value in specific situations:
One team of agile, cross-platform developers, maintaining multiple, coordinated, native code bases
When properly managed, assures final product is consistent, is fast but uses platform capabilities fully, and deploys with a minimum of code
Sets the development team as the subject matter experts for product development and functionality
Requires highly-skilled and experienced developers who have worked in cross-platform situations on teams of highly interdependent individuals. Depending on the complexity of the application, this can be an expensive strategy to source staff for and to maintain through the product lifecycle.
If the team size is small and manageable, the total elapsed time required to develop the applications will generally be higher than if multiple teams can work in parallel, even with the required coordination overhead. If the team size gets larger, it becomes much harder to source and control.
Scrum of scrums team coordinating a sprint
Multiple agile teams of developers, dedicated to each code base, and coordinated across the project using a scrum of scrums approach to coordinate data, functionality and the user interface implementations across all platforms
Coordination is the key, requiring a high level of collaboration and communication across the entire project team. This requirement can slow development significantly, especially in early phases, as the teams decide on approaches to accommodate common functionality and requirements.
It is easier to maintain each team (and generally less expensive) with the skills needed, but replacing individuals becomes very dependent on team-level soft skills and personal compatibility. A person who is not the right match for a team can put the entire project out of sync and slow down productivity greatly.
Although generally this strategy can shorten the project timeline greatly, the overhead will be much higher. Each team will need to have a target code base QA capability, whether it is embedded in the team or separate.
One or two agile teams of developers (depending on if a backend, companion application is needed, its features and functionality) using cross-platform tools and development environment.
There are many cross-platform environments, some provide a better range of capabilities and tighter code than others and some have wider acceptance with larger populations of skilled developers than others. Picking the right environment for the product and the resources available is a critical step in project planning. Changes cannot be made mid-stream without serious loss. In outsourcing situations, the vendor team needs to be part of the platform selection to assure that there is a match with the resources and experience they can provide.
This strategy can bring some of the benefits of both approaches – depending on the tools and environment selected. Success depends on a selecting a capable set of tools that produce code that can be used on the target platforms with little overhead and that leverage the skills base of available resources without requiring a lot of specific retraining. To accomplish this, some tools simply use web-based technologies and embed what amounts to websites in their apps. This approach may be good enough for some light applications, but it can create serious functionality holes for others. It can also create issues for applications whose user base and functionality needs to grow over time. If the tools used have serious limitations, they may end up narrowing application functionality, usability or inhibiting application maintenance.
End app QA is based on successful achievement of functionality and less dependent on the native code deployed on each platform. This puts the weight for proper code development on the (smaller) development team and functional QA with the product owner and their team.
Of course, if you are, or are working with a high-volume mobile development provider – you are likely to have the resources and cash available to use the first or second strategy. But, not everyone can go that way on day one and not everyone wants to risk the upfront investment, even if it is possible for them. It is estimated there are over 4 million apps available to users from authorized platform stores. Getting a foothold in a market this large requires a lot more than luck and a nice interface. There is a lot to be said for native code apps, no matter how you accomplish the goal, but you have to be careful how much time and cash you burn on the way to success.
If you are an entrepreneur, using the lean startup approach to bringing an application-based service to market, you probably aren’t attempting to “bust a market” with some entirely new idea that you have kept hidden from the world until the right moment. In the lean-startup methodology, you are going to start with a minimum viable product (MVP) and work with your target market to evolve towards an offering that meets the needs of your users, even if they don’t know they have the need today. The strategy is lower risk, requires a longer commitment of resources and enough cash in reserve to “go big” when the application and service begin to solve some crucial problems that have high value, but has a better chance at success in general. In these cases, the third method begins to have some interesting points:
Team size can be small with relatively high productivity if the tool set used leverages team skills and fits well for the target application.
It is easier to maintain the team over the development period because the skill set and resources are relatively easier to find and the code base is unified, not separate and unique.
Smaller teams can be more agile, more adapted to the lean startup environment and more able to manage change as required to be successful with the methodology.
But we started all of this mentioning a specific tool and environment – Xamarin. Xamarin allows developers with experience in the C# programming language to develop native code mobile apps for Android, iOS and Windows with one code base. C# developers can work in the environment they are most accustomed to – visual studio – with companion tools that bring in capabilities from backend systems, cloud services, UI controls and third party libraries. It also provides a test cloud that allows the many flavors of devices using the common mobile operating systems to test applications without being jailbroken or dealing with multiple app stores during development. The rich environment available to Xamarin developers is largely due to the success of the system as well as the funding and eventual purchase of the company behind it by Microsoft. It is a prime example of a stable, rich, cross-platform environment for mobile development.
Using this approach, over 1 million developers are registered and developing mobile applications in 120 countries. The level of adoption makes a lot of difference if you are attempting to build a development team or find an outsourcing vendor. But, because the environment is relatively transparent to the development team – you won’t find many vendors or resources listed specifically for their Xamarin skills. Instead, you will find them being sourced as mobile C# developers. C# is the programming language being used, Xamarin is a tool set and compiler that provides the libraries and native code that enable the system to work across platforms.
So, once again – the bottom line:
Mobile applications will continue to grow and be the primary method for accessing global network services. There is no turning back.
Mobile application development needs to be able to reach across platforms (in most cases) to capture market share successfully. Because there are multiple, very different platforms and many implementations in the field – this is a serious issue.
Developing a strategy for development across multiple platforms is a critical step in any mobile development product plan. How you deal with cost, time-to-market, shifts in user requirements, usability and many more issues are part of the considerations you need to think about.
Available resources and their skills make a difference. Picking a strategy that gives you good access to resources and a competitive pool of vendors you can depend on during product development is another critical issue.
The developer cost per hour, once again, is not the sole determining factor in managing project cost. If the strategy you pick requires larger teams or a very specialized group of resources – you have to be ready to manage the risk that costs could go higher than you expect and time-to-market could be seriously pinched.
There are other development environments like Xamarin that can be good decisions for specific situations. There is no “one size fits all.” The skills available from your team or services vendor are a good starting point. Work with your team or vendor to clearly understand your needs and come to a conclusion that fits your situation.
Scio is a provider of nearshore, software development services for our clients in North America. We develop mobile and Internet-based applications using a variety of approaches, depending on the project and client requirements. We would be happy to talk to you about your next project and let you know how we can help you achieve success. Contact us for more information.
The post Cross Platform Mobile Development & Xamarin appeared first on Scio Dev - Nearshore Software Development Partner.