Ok, I admit “Mobile first” is kind of a buzzword nowadays, but it’s one of the few buzzwords that don’t lack the complete technical background or original meaning behind it. How do you enter the world of “mobile” development?
Let me try to provide you an overview…
First things first
What does “Mobile first” actually stand for? Let me answer this with some swift bullet points to get us going:
- Describing a system and UI/UX architecture designed to focus on mobile usage pattern and viewport sizes
- Doesn’t have to be a native App, it can be applied to web solution as well
- Depending on the project, can come along with “offline first”, allowing data to be stored on the device (again, works for web and apps)
- Mobile first doesn’t exclude desktop usage, scaling and responsiveness are key factors of this concept
Ok, you got me… another buzzword has sneaked into the above list: “Offline first”. The idea is that you design your application to be used without any connection, depending on your application it might contain all features or a subset.
One last thing I want to point out before we compare different options, is that designing an application for mobile first usage can still include desktop, smartwatch, TV and even your car (that would be referred, too, as “Multiexperience”).
I will promise to stop with the buzzword bingo from here on :)
Choose your path
You have more or less two paths to choose from (with some shortcuts between them), both will get you to your goal. For now, let’s go with the following options:
- Web-based technologies, your toolset will be HTML/JS/TypeScript/CSS
- “Native” solutions, you can choose from a wide range of languages like C#, Dart, Kotlin, Swift etc.
So, what’s the right path for me?
This depends on your project — let me try to provide you the pros and cons for the different options. Please note, there are frameworks that can go both ways (which is great) but of course makes the decision more complex.
With a native app, you will be able to use the device hardware, enabling you to work with sensors, camera and of course the GPU to render stunning animation. Running on a device also takes away the storage limit you face when you want to store offline/permanent data on the device. Depending on the platform you choose, you might have to write and maintain two different code bases. This can and should only be done if it is really needed!
Producing a native app means you have to use the platform related app store (of course, for Android you can ship your app without the store, but you will need to take care of the distribution, updates etc.). Using the app store will allow you to reach a huge user group, payment and invoices will be handled for you as well as updates. In case you plan paid services, you have to provide some revenue to the store owner.
Beside the financial aspect you also need to follow the rules of the store regarding content, technology and design.
To sum it up, going native means:
- Facilitate the hardware access you got alongside the performance you can get out of it
- No worries about storage limits
- Vendor lock in for the stores, you need to follow the rules
- Higher maintenance if you have to keep two code basis
Please note: You can go with frameworks that allow you to have the same code base on multiple platforms, this includes native apps, websites and good old desktop applications (that would move you in the direction of multiexperience)
A website will directly enable a huge range of devices to use your application, all with a single code base. You can choose from an ever-growing pool of frameworks and concepts to do what you need to do.
Websites are limited when it comes to using device-specific resources and on device storage, still you have options to use some of them. You can even design offline first websites and allow users to “install” the website on the device (without the app store in between).
A website might not look and feel like a native app and getting a pixel perfect layout can be challenging.
Let’s sum it up:
- One code base for a wide range of devices
- Limited resources and offline/on device storage
- Look and feel (UI and UX) are not like native and pixel perfect layouts require substantial amount of work
- If wished offline first and even a “local installation” is possible
As I mentioned for the native frameworks, there are web-based solutions that can be compiled to be a “native” app. You can use HTML/JS/CSS to build the UI and business code. This framework also offers access to the device hardware. As any other app they will be again shipped by the store and all related rules and regulations apply.
Spotlight on Native frameworks
Before somebody complains about the usage of the term “Native frameworks”, I use this to divide solutions that are rendered in a web-view or browser from the ones running a full app. I tried to keep the overview as short as possible. Of course, there are more options, I just picked platforms that I either have experience with or are well-known solutions.
How to choose the right candidate?
Tough question and like many other tough questions, there is no direct answer to it. But what I can offer is a guideline to your personal answer:
- Do you already have experience with one of the used technologies?
- How big is your team? Can you afford to maintain multiple code bases?
- What platforms do you really need?
- Do you need to hire? .NET developers can be found “easier” than for example Dart developers
- Are you planning a “pixel perfect” UI/is your UI very different from the default controls?
- Are there any critical 3rd party components you must use (like AWS/Azure etc.) integration that might not be available on a given framework?
The above list could go on, with questions about how you plan to test or how to integrate the new project into existing workflows etc.
Move it to the web
You decided to go with a web-based solution — great! Now you have to find one out of many (many, means actually a day by day growing pool of options). The table below shows an overview about possible option that are well-known players and can get you quickly to your goal.
Like the native frameworks you should choose the best fit for your current situation. Think about the complexity your application will have later.
- Do you have a lot of user interaction or do you preset content (like a blog)?
- What would be the concept for your page, multiple pages or single page application?
- Are you planning to follow a design concept like Material from Google and reuse existing UI components?
One note: I’m aware that in the above list Bulma is not directly comparable to the other options as its “just” a CSS file. Sometimes this is all you need based on your project. Keep in mind, the framework is a tool to help you to get to your goal as easy as possible. Maintaining a single CSS file compared to a “huge” framework is more straightforward.
Choosing the best fit for a new project is not that easy, choosing an addition or alternative for an existing project can be even more difficult (feel free to get in touch, I do have many stories about this…)
The golden rule is to see it as a tool to solve your need and ensure that it will not end up in sleepless nights trying to maintain a bleeding edge code monster. Try to keep it simple and small.
In case you want to start collecting your own information about frameworks and technologies used around the industry’s, below is a list of resources you can use:
I hope I could help somebody with this to take a step further, any feedback is very much welcome.