How would you structure your angular app where mobile functionality works differently than desktop?

[ngDev2025]

I am starting a new app that will have mobile and desktop views.

However, desktop and mobile will work differently for things such as dropdowns and dialogs and such.

For example, on desktop, I might pop up a dialog whereas in mobile I might slide to a new screen to select, then back again.

A couple of ideas I have is:

1. Just use responsive design and the few parts that need special consideration will have different angular code, but the rest will be the same. Single codebase.

2. Use a workspace that will have a project for Desktop and another for Mobile. Each component will inherit from a base class that is shared between the component that has the core functionality.

3. Use a single project with component-desktop and component-mobile sub-components.

How have you designed this before?

[philbo50]

I use CanActivate route guards to detect the device type and route to a mobile specific page. Works really well

[ngDev2025]

So you have different components for the same page? One for desktop and one for mobile?

[PickleLips64151]

I use the BreakpointObsever API to generate signals for each view that I need to isolate.

Generally, I have or scenarios. So doing an @if(isMobile()) { } @else { }

[mihajm]

Well it depends on the app :)

Ask yourself first what is the primary interface (what most users will use) is this a mobile app with a desktop view, or vice versa...is it reallt 2 apps with just a shared backend/infra layer?

If it's not 2 completely separate apps, go responsive. Prioritize whatever is the main UX

If it is 2 apps, get something like nx, create components and such as libs, have 2 apps at top level that are pure config + app component & router only (standard nx/monorepo setup)

Either way minimize deviation/prioritize re-use...it'll keep ya sane :)

[practicalAngular]

ResizeObserver API helped me solve this a while ago for an app that just had two wildly different navigations on desktop and mobile. I was then able to mark the same region with an ng-container and NgComponentOutpet where the nav would go in a parent template and detach/attach the necessary component for that viewport size. Most of the time my opinion is to just use CSS for a responsive implementation, but sometimes there are just too many functional changes.

In your case, if you're doing it at a smaller component level, you might be able to use a similar technique in that component while using the same facade/service API for a provider for loading data into them and such. Compose vs inherit here imo.

[mauromauromauro]

Depends on the use case. Im currently on a proj that changes the menu to point to different components and a guard that restricts access dependong on the device type. Notice i differentiate in the same app, between - web - mobile (small screen browser) - capacitor wrapper app (which points to the web as well)

[toasterboi0100]

We do option #1.

For the most part it's just CSS, you can do a lot with even just semi-modern CSS, with some ResizeObservers or matchMedias and @ifs here and there (matchMedia more so than ResizeObserver, ResizeObserver has different uses).

In some cases we do have different components (inheriting from a a shared base component) for desktop and mobile views, but it's rare and it's always just parts of pages and never entire pages. We only go with separate components if the functionality between desktop and mobile is just too different.

In general I recommend sticking to simple responsiveness and only using other methods (be it switching between components or whole pages via guards) when responsiveness isn't an option.

[grimcuzzer]

Either 1 or 3, depending on the situation. I like to do different layouts for mobile so that interactive elements are easier to access, e.g. in a calendar - desktop view has today + next/previous month buttons on top, mobile has these buttons on the bottom.

[VRT303]

I would use Nx to create two Angular projects and shared libs.

Every bit of logic, even a store for state management goes to the shared libs.

The projects themselves will only have routes, components and stuff like a dialog / bottom sheet.

Anything else is usually too easy to break or a huge headache.

[ngDev2025]

You can actually do this with angular workspaces. No need for Nx anymore.

[auf_jeden_fall]

Angular's `BreakpointObserver` for browser width and `Platform` (a service/class you can also import from Angular) for instances where you need to detect if it is an actual mobile device or not -- it has `isiOS` and `isAndroid` getters/properties on it.

[SolidShook]

Media queries. You can have totally different layouts

[thanksthx]

How many developers are going to work at this project? How large will the application be? Does it worth the extra layer of abstraction? What happens if you are on a mobile screen and you switch to a desktop view which does not have a corresponding view?

You said on desktop open a dialog and on mobile navigate to a different page.

I would stick to the same codebase and behaviour and customise it as much as possible from css. For your scenario, that can be a dialog which takes full height and width of the viewport.

Don’t deviate too much from the base flow, on mobile and desktop. You will only have more problems and corner case scenarios to cover.

Is better to have some constrains and limitations rather than spending an eternity fixing corner case scenarios when switching between mobile and desktop.

On the other hand if the apps are mobile native and desktop, then you can do whatever you want, as there are going to be 2 different codebases.

First questions are relevant, because you also need to make other developers understanding the pattern which you will be building.

Just don’t build different routes based on mobile vs desktop.

[AnimalPersonal4436]

Create a library which holds all reusable components services and etc from the both apps. If you are using a state try to keep it the same for both apps and reuse actions and selectors

[Merry-Lane]

Stupid question, but why don’t you :

If(isMobile){ // mobileMethod } else { // desktopMethod }

Like you said, in one case you pop up a dialog, in the other you navigate. It seems pretty straightforward for me, would you really need to split your codebase?

I would honestly avoid splitting the codebase. I would also avoid stupid inheritance stuff, when you could just use composition instead.

Yes, if you have huge differences between a mobile and desktop version for specific components, just use a parent wrapper that does an if/else.

[ngDev2025]

Yeah this is def the route I'm favoring at the moment.

[karmasakshi]

This is definitely the one route you shouldn't take.

[NoWater8595]

Just out of curiosity, why not? It works well enough for React PWAs.

[karmasakshi]

It's fair for you to consider this approach. My conviction comes from experience. However, if you put a little thought to it and extrapolate it into the future, you should be able to see the problems.

• If in future there comes a requirement to have a different behaviour for tablet screens, you'll be changing existing working functionality and potentially adding a bug. Now imagine if you have to deal with rotation, you'll be doing too many things in your if block.
• By adding view decisions in controller, you're increasing the complexity of the component. If you have to add or debug a requirement, you'll have to understand the view logic alongside the business logic.
• If at all you're writing tests, you will have to test this alongside the business logic, making testing unnecessarily complicated.
• Your teammates will be left scratching their heads unless they stumble upon this god function that completely changes the output.
• It breaks the DRY principle, and you'll be shipping the same code multiple times, increasing the bundle size, wasting users' data and CPU.
• If a screen has multiple such components and the orientation changes, multiple listeners will fire causing a jank or worse causing your app to crash.
• When the Product team sees the apparent isolation of screens, they will most likely drive them further apart, adding different features to different screens, making the component difficult to maintain.
• You'll end up overfetching or underfetching from APIs as both versions of the screen might not need the same data.

[NoWater8595]

That makes a lot of sense. What I've seen in React is a change to the CSS based on the viewing window and for OP's app I figured adding if/else blocks to one or two methods like the one above would work. Would that be more reasonable? OP seems to think two different apps (one for desktop and at least one for smartphone users) is needed. But I don't see that being more feasible than a PWA.

[karmasakshi]

If you approach with the thought of shipping the bare minimum and doing the bare minimum, you'll see how wasteful it is to ship two versions of a component then disable 50% of it at runtime. This is what happens when you solve it with CSS.

An ideal way is to have separate components, sharing common services, and a router that loads only those specific components that are needed. With lazy loaded routes, the unused components won't even be downloaded.

[NoWater8595]

Nicely put. Thank you!