Want to build a mobile application? Check SSW's Mobile Apps consulting page.
If you need to build a binary app (rather than a web app) that will run on multiple platforms (e.g. iOS, Android, macOS, Windows), you can either build and maintain multiple versions of the app - one for each platform - or you can use a cross-platform (cross compiler) framework to build one app that runs on all of them.
Progressive Web Apps have transformed the mobile web practices to provide a native app like experiences for the users. They work just like native apps and include features such as smoother navigations, offline modes and push notifications, but are much more economical and do not use the device storage.
Progressive Web Apps are reliable which means they load instantly and the performance isn't compromised even if the network is shaky.
On the mobile the 'Add to homescreen' option can be used to create an icon on you phone.
PWAs also account for higher user engagements and conversions which is probably why many organizations are now adapting this technology to grow their businesses.
In today's mobile-first era, ensuring your website looks great on all screen sizes is crucial.
On mobile devices, viewport sizes fluctuate due to dynamic toolbars like address bars and tab bars, causing elements to potentially overflow beyond the viewport.
To address this issue, the CSS Working Group introduced dynamic viewport units (like dvw, dvh, dvi, dvb, dvmin, dvmax).
Implementing these units into your website allows it to be responsive across desktop and mobile platforms.
Getting configuration into the hands of mobile app users can be challenging, and you need to make it as seamless as possible. For web apps, this usually isn't a problem; for any given instance, you go to that instance's URL. But for mobile apps, they often don't even know which instance to connect to.
You don't have to charge users for your software. In fact, even free apps and games are designed to make money. Do you know the best way to monetize your apps?
A common approach is to submit your app to Testflight, wait for user feedback, then submit for App Store release. The problem with this approach is that your release cycle can be significantly impacted by Apple's review schedule. App Store and Testflight reviews can be very quick, but can also take up to 3 weeks!
Lack of access to physical devices for testing can significantly impact mobile development. Issues can arise that you don't know about until UAT. Do you know the best way to mitigate this and avoid spiraling development costs?
.NET MAUI (Multi-platform App UI) is a framework that enables developers to create cross-platform applications for different devices efficiently. However, the efficiency of this framework could mean nothing if the developed apps are not tested on various devices, especially the older once.
Choosing between bare React Native and Expo is a bit like choosing between React and React plus Next.js. You can absolutely build everything yourself, but once routing, native APIs, upgrades, build tooling, app configuration, and deployment enter the picture, you quickly realise you are not just building an app anymore. You are also building and maintaining your own framework.
That is now the official direction from React Native as well. The docs recommend using a framework, and Expo is the recommended community framework for new apps.
React Native makes it easy to move quickly in a simulator or emulator. That is great for day-to-day development, but it is also how teams end up shipping bugs that only appear on real hardware.
Touch handling, keyboard behaviour, safe areas, permissions, notifications, and performance often feel "close enough" in a simulator right up until they are not.
One of the easiest ways to make a React Native codebase messy is to scatter Platform.OS === ... checks through every component. It starts small, then turns into components full of branching for iOS, Android, and older OS versions.
Keep most of your code shared and only branch where the platform or OS version genuinely requires it.