In part 1 of our Cross Platform App Development series, we challenge you to revisit your own assumptions, and ask strategic questions to find the right solutions for your team and projects. Look for future posts in this series that will break down specific platforms, tools, and features.
It’s a great time to create in software development: There are so many tools, frameworks, and platforms to choose from to build with at relatively low costs. It’s also a confusing time because it’s difficult to know which tool is the best one for your project. This confusion can create roadblocks as one of the most important decisions for a cross platform project is made around development tools.
Should you create separate projects and use the native systems built by the manufacturers, like Xcode and Swift for your iOS team, or Android Studio with Java on Android? Or should you have a cross platform native project built with Xamarin or React Native? Or maybe even a hybrid or a fully web-based solution?
Unfortunately, there isn’t a silver bullet solution out there, and we can’t promise there ever will be. However, there is likely a good solution for your project and for your team. Here at L4 Digital we’ve built apps with many different teams over the years, and in that time we’ve shipped with nearly all of the approaches mentioned. The question of “Which should we choose?” is still one of the hottest topics when starting a project and likely a decision that has the largest impact on your results. We’ve generated this series to break down your options and give guidance on traversing this question to create tangible solutions.
Exploring Some Assumptions
If you are looking to get to market quickly, aren’t hybrid apps or cross platform native solutions like React Native cheaper? They might be, but hiring and training a team of developers for a cross platform solution might be prohibitively expensive. Or there might be reusable libraries and code that best fits for a native app. Don’t native apps perform better and have the best user experience? Generally this is true, but definitely not for all circumstances. There are many things that markup languages do well that are much more difficult with native components. Can’t you write something once and have it run on all platforms? Potentially yes, but it ultimately depends on the system. With some solutions, you might be able to share business logic, but write separate UI components per platform. And with others, you might be able to share the code fully but trade off on some of the native OS experience. Without the context of the project, jumping to conclusions that have been generalized in the market is potentially harmful to the success of your project.
Define Before Building
Typically, a “Discovery Phase” for the project will be a time to define high-level items like development platform, systems architecture, and the project plan. In order to make an informed decision on the development platform, it’s best to gather some information about the team and the project that may factor into your choice. The following are some examples of questions we like to answer for a project:
- What type of user experience will there be for the project? Are you looking to have something that is exactly the same across devices and platforms or something that is more tailored to the platform experience?
- Who is on your team? Do you have a team of experts or interest in a particular platform? Generalists? Or potentially separate teams? How about your QA team?
- What are the most complex components of the project? Are they UI, business logic, systems integration, or a mix of several different things? Are you accessing lower level items that might only exist on certain types of systems (rfid/sensors/etc.)?
- How flexible do you want your experience to be? Do you want to require updates in order to change large components or does it need to be more dynamic?
- Are there existing things that you might want to (re)use, like libraries, previous versions, or open-source projects that might help with the project?
- How much might you be able to share code between platforms? Do you have complex data models or business logic components that would benefit from one shared codebase?
- What are you going to do with this after you’ve shipped version 1? Who is going to maintain the project? Will your future selves be happy with today’s decisions?
So, how do you decide? Our goal for this blog series is to help guide teams to understand this decision process as well as make the act of choosing as simple as possible. We believe that there isn’t only one way to build an app, and that there might be several right answers for your project. Each one of these platforms provides environments for high quality and budget conscious apps. Rarely is there only one factor in arriving at the right answer, and often, we’ve seen people jump to conclusions after considering only one item. The decision of a development platform will need to consider the features, the budget, the team, and future plans for the project.
Stay tuned- we’re going to explore several solutions in upcoming posts, outlining the benefits and tradeoffs of each one.
Read part 2 of our cross platform app development series: Building Native Apps.