Developing for Mobile
The world of mobile app development is much like any other industry; there are camps devoted to specific technologies and methodologies with some rather strong adherents in each camp. If you consider that each technology and methodology takes time and effort for a developer or team to gain proficiency – it makes perfect sense. Switching to another approach means building new skills and knowledge that may not be rewarded in the marketplace. But, on the other hand, application development is always moving forward, so as a developer, you can’t afford to be left on an island with no bridges to new technologies either.
Consider the case of a team developing for iPhone. At some point, you need to consider if your app needs to accommodate “universal code” standards so it can also be used on iPads and iPad Mini. And – you also need to consider if you would benefit from extending functionality to the iWatch. But, you can’t stop there – the market is actually bigger for Android devices in many forms. Can you afford to leave them behind?
Who makes the technology choices for mobile apps?
There are many valid routes to developing successful mobile applications. If the resulting product meets the market required successfully, provides pleasing user interaction, and is both maintainable and scalable over time, arguably the choices made were correct because they have met the need regardless of the route chosen to get there. If you as the business product development team, specified native code clients without considering the cost and effort required, that is a business decision. Perhaps you have an internal development team with native code skills or you read that native code apps can be faster and richer. In the trade-off, you have also set a course that eliminates some other choices and if you understand your options it is just fine.
But that is the point. With so many valid routes to a successful mobile client, you should understand that each has adherents in the development world, who have built up the skills and understanding necessary to use them. If you approach a development team with business requirements, they can answer with the technologies in their domain that fit the problem and the effort required for your project. If you approach from a technical point of view, they can still answer, but they won’t have the freedom to give you the most efficient and best answer from their background. Another team will have a different answer, but (hopefully) with much the same outcome. It can be just as valid.
How do we deal with this situation?
We face this type of decision quite frequently. In mobile development, we want to be able to quote projects using best fit technologies, skilled resources and the most competitive approach possible within our constraints. There are many technical choices, including the development environment we work in. Increasingly, frameworks like PhoneGap, Xamarin, and jQuery provide ways to develop in a single environment for multiple mobile platforms. In some projects, this is a very efficient way to work and provides highly maintainable mobile apps. We also use web-based applications as backends for mobile clients to cut down the code needed on the mobile device itself and to provide a “hub” that can run processes asynchronously – across multiple devices and providers. We also use native device code when it provides advantages that frameworks cannot. These are choices and mobile development is not a “one-choice fits all” world. Your technical team should be able to give you clear answers within the constraints of the project and the teams involved.
So, if you are a business team approaching a mobile app, consider these points:
- Have clear business-driven requirements and let your technical team navigate the technology alternatives as much as possible. Simply ask for an understanding of what drives the key decisions and validate as needed.
- Understand and expose your priorities. Accept trade-offs that are necessary to meet them but don’t go deeper than you need to.
- Make technical decisions that have a direct impact on the product feature set, cost, and effort. Expose your decision process to your development team for validation, but require that they give some depth in their review. Stay away from “religious” arguments that do not move the ball forward.
- Ask for regular demos during development. If you are working with an agile-based team, it should not be a burden and it should give you opportunities to adjust development priorities and direction during the project.
- Accept the fact that all products and technologies have a lifecycle. Only rarely can you expect to use the same technologies and methodologies throughout. At some point, technology will force changes, but if choices were well thought out, you should have recovered your costs many times over.
Frameworks for Mobile Development
At Scio, mobile apps and mobile app integration are a key part of our competency. We’re here to work with you and solve problems. If you would like to know more – please check our mobile development page for more information.