Scenario
In looking at the stats of views to our most customer facing app, it’s 90+% viewed and used on mobile. At what point are you guys building true mobile apps and what approach are you taking (raw native aka one Android stack, one IOS stack, flutter, React Native, Cordova, other toolkit. Final question on this thread, if you are going react native/flutter approach are you considering their web targets instead of a web app as well as the mobile app?
Constraints
Without full context, the answer is always “it depends”, but lets make some assumptions:
- App feature set and functionality work equally well on both web and native platforms
- The teams skillset is mainly web app development
- The marketing strategy fits both distribution strategies, Web or App Store
- There are no competition dependencies for either platform
- Risks are weighed and the focus has come down to the best technical solution for the team
Strategy
It is important not only to consider the short term “build” but also the long term “maintain” cycles, when thinking through a technical solution. It is likely that the maintenance can be a bigger expense than the initial build out. It is also important to consider the culture of your team and where they want to be, as they build out this product. Do they aspire to be native mobile developers or continue to grow down the web development path.
Don’t have all the answers? Choose a Progressive approach
If all the answers are not available to make the perfect decision now, maybe consider a progressive approach.
When starting a new product you will learn more when users actually start using the product versus in the lab. Being able to ship a quality product soon gives you a great advantage, so consider the time to first customer experience as a value. For example, you could start with a simple PWA approach with a standard service worker setup, create a manifest and all of the apple icons. Then focus on delivering a SPA application to your customers, using the technology stack your team is comfortable with, Svelte, Vue, React, etc.
Separate Business Logic from Presentation Logic
Spend the time to design your API and separate the decisions your application needs to make into an application layer. Often teams jump at BaaS service, or CMS service as solutions for their backend to quickly get a prototype off the ground. The team ends up implementing some overly complex business logic in the presentation layer of their application. Which results to a tightly coupled technology stack. Do not do that , keep your frontend simple and craft an API that contains specific commands to your application.
For example, if you are building a workflow application, do not expose all of your models to your presentation layer in a CRUD style api, only expose the bits needed for each purpose and step. If you are listing contacts in your application, do not send the entire contact object in an array for the list, if the list just requires name and email. Just send name, email, and identifier. And so on. Look at each need from the presentation and give the presentation what it needs.
Crafting your API into a Domain Specific Language for your application will help you separate the decisions that need to be made in the presentation layer and in the application layer.
Why separate concerns? Won’t that make the application more complex?
Yes, it may feel like overkill at first when you are getting started, but you are setting your future team up for success, because over time as they product gains traction, more features will be requested and pivots will be made and you want to set your team up for success. Make this small investment to not paint yourself in a corner in the future. It also helps flush out the design details of a product and gets them into a specification that can be discussed and collaborated on.
Progressive Mobile Development
- Phase 1: Design API
- Phase 2: Start SPA with standard PWA implementation
- Phase 3: Use CapacitorJS/Cordova and wrap SPA to ship to App Stores
- Phase 4: Migrate front-end to React Native or Flutter for a more native feel
- Phase 5: Migrate to full native using swift and kotlin and build a native development team
Consider this development plan as a phased process in which you build to each phase and weigh the needs and requirements then migrate to the next phase as the needs show and measure along the way. You might be surprised, you may only need a PWA, or maybe a hybrid solution like CapacitorJS. This will give you the ability to step through and validate each decision, because each decision will come with more cost for on going maintenance.
Summary
As you decide to build your mobile application, I hope this helps you in terms of the development effort. If you design an API you don’t have to commit to one mobile solution or another, you can set your team up to have flexibility and change over time as requirements and features are modified and introduced.
By creating strong boundaries between your technology layers you give your team the flexibility to change.
hyper63
Not only is it good to separate your presentation layer from your application layer, it is also a great design to separate your application layer from your services. We build an open-source project called hyper63 that enables you to do that without having to build the abstractions, hyper63 has them for you. If you are interested, take a look at our project: https://github.com/hyper63/hyper63
Top comments (0)