When talking about building applications for growth, the conversation often devolves into a technical debate over whether to scale up or out or which specific technologies will suit an application. These debates forget one of the most important rules of enterprise technology: business goals should drive the tech, not the other way around. Leaders should start by clarifying what is needed from the app as it grows before nailing down the tools.
There are three key concepts which all scaling technology should support in order for an app to be considered “built for growth”.
“User-centric” refers to traits which directly affect the user’s experience. For example:
Reaction times to button clicks
Fast and reliable return of updated information
Applications are highly sensitive to user perception. More than half of users will abandon a web app entirely if it seems too slow.
It damages their overall perception of the sponsoring business’ modernity, as well.
On the flip side, better performance leads to higher revenue and better ROI on advertising campaigns.
Apps that load in 5 seconds or less see 25% more ad visibility and 70% longer session duration on average. They’re also enjoy higher user retention rates than slower applications.
When deciding between two technologies, choose the one that reduces the user-perceived delay the most.
Determine how much of the delay is caused by each step of the data retrieval and presentation process, then prioritize tools that target the problem areas.
Web apps shouldn’t have a bigger cost to grow than to build in the first place, but that’s what can happen when growth isn’t considered from the start.
Companies sometimes make design choices that are less investment during development but require complex, expensive scaling techniques.
An app can’t be called fully scalable unless it has a fixed marginal cost to grow. Adding users or capacity should be predictably priced and simple to implement.
“Predictable” is a big part of being scalable. There’s no way to tell exactly how quickly an application will grow, but it is possible to create a scaling plan that shows leaders how much they can expect that growth to cost at each stage.
Surprises when scaling generally mean the original plan wasn’t thorough enough. Be sure to take into account vendor stability and projected rate increases.
Also, don’t leave out any higher costs for maintenance at scale.
Despite the interest, 90% of web applications have at least one avoidable vulnerability. Common weak areas include encryption, authentication, and access control.
Hard-coded passwords are another serious risk. A full tenth of applications still use them for administrator-level privileges despite general discouragement by the security industry.
The risks from these vulnerabilities increase exponentially as an app grows into an appealing target for malicious actors. When planning for scalability, focus on growing securely as well as quickly.
Don’t take risks with customer data that could lead to breaches, legal issues, and loss of reputation.
On a hopeful note, the problem does seem to be shrinking. In 2016 the average number of vulnerabilities per application was four, and that fell to three per app in 2017.
That average may fall even more if the emphasis on security continues to drive safer design practices.
The True Measure of Scalability
Scalability isn’t only about whether applications do or don’t crash under unpredictable workloads. Availability is part of the puzzle, but not all.
The true measure of scalability is whether a system is flexible enough to efficiently meet a company’s needs within an acceptable range of quality regardless of workload.
Make that the focus of technology decisions and an highly scalable app will always be the result.
Concepta has more than ten years experience designing web applications that maintain high performance and security at scale. To learn more about the technologies we use and how they can benefit your business, set up a free consultation with one of our skilled developers.
Although consumers are spending more time in apps than ever, the number of new apps they adopt is shrinking. More than 65% of mobile users download less than one app each month. Getting attention for a new app is hard, and only 26.4% of people who do visit the store page go on to download it.
In the past creators have tried to get around this using web apps. Web apps don’t need to be downloaded at all. They’re accessed through a browser, and as such are mostly device agnostic (though each browser has its own quirks that may affect how the web app performs).
Traditional web apps have a lot of pitfalls, however. Performance is noticeably worse than with native or hybrid apps. There aren’t many features available when users are offline or in a low-service area. Even when they are online access to device utilities like the camera or gyroscope is severely limited. Web apps don’t offer nearly the same experience as a native app.
At least, that was the case.
The Web App Revolution
A major change is underway in how the mobile web works. The new breed of web apps- called progressive web apps or PWAs- have more in common with native applications than they do with mobile websites. They offer a broad range of features typically only found in native and hybrid apps without consumers being required to download anything.
Google’s VP of Product Management, Rahul Row-Chowdhury, compared PWAs to the paradigm-changing advent of AJAX some ten years ago, saying, “Progressive Web Apps are that same fundamental shift for the mobile Web.”
PWAs solve a lot of problems for creators. First, they save time and money by allowing developers to focus on one product. Native apps require a separate product for each platform while hybrid apps use platform-specific wrappers to function on different platforms. Progressive web apps just need a browser, so companies are freed from the burden of building and maintaining a handfull of codebases.
Most apps aren’t included in search engine results; prospective users have to visit the app store in order to find them. Creators get around this with the imperfect solution of a “landing page” with a link to the store. That lets them apply the SEO needed to help users find their app, but that adds steps to the process.
The more steps involved in doing something- even something a person is excited about- the less likely the user is to continue. Only 90% of those who download an app will use it, and every additional step knocks out up to 20% of potential users. This is the biggest advantage of progressive web apps. More users complete the app onboarding process because there are dramatically fewer obstacles between them and the content.
What Makes a Web app Progressive?
Progressive web apps aim to provide the same experience as native apps, or as close as possible. There’s a list of requirements a PWA has to meet to be considered progressive:
Progressive – It’s most important that PWAs take advantage of evolving browser features and device functions to provide a forward-facing experience. They should work on every browser, for every user.
App-like feel – PWAs need to be built on the app-shell model with few page refreshed, giving users the feel of an app as opposed to a mobile website.
Connectivity Independent – A progressive web app should work in low signal areas and offline.
Responsive – No matter how a user accesses it- via tablet, smartphone, etc.- a PWA’s UI needs to fit the device’s form factor.
Discoverable – PWAs should be as easy for search engines to find as websites are.
Installable – While PWAs don’t need to be downloaded, they should be able to be saved to a device’s homescreen for easy access.
Linkable – Like websites, PWAs need to be able to retain their state when shared via link or bookmarked.
Re-engageable – Re-engagement should be driven through native features such as push notifications.
Safe – Because they’re susceptible to “man-in-the-middle” attacks, PWAs should always be hosted over HTTPS.
Fresh – New content should be made immediately available to all users within network coverage, or as soon as they reenter coverage areas.
Analysts call progressive web apps the app model of the future, but there are still valid concerns with the structure. While PWA components are W3C compliant, they aren’t supported by all browsers when integrated into a web app. This lack of universal support is the main issue limiting their popularity. Fortunately, major browsers like Google Chrome, Firefox, Opera and Samsung Internet already support progressive web apps and Edge has announced it will at some point. Safari is being vague about whether PWA component support is in the cards.
PWAs are more difficult to build properly. Since they’re an evolving format, the number of developers skilled in their creation is limited. That’s a serious problem when accessing device functions is as complex as it is. Progressive web apps can access most (not all) features ignored by their traditional cousins, but getting them to operate smoothly across all browsers is a demanding task. The need for more expertise seems to cause higher development costs per app. The total investment is lower since only one app is needed, though, so paying for a better developer still results in a net lower investment.
Some developers have criticized progressive web apps for not appearing in app stores. This isn’t necessarily a bad thing, however. PWAs are meant to be found through browser searches using SEO, not downloaded through an app store. Publishers are promoting them elsewhere. It’s an entirely different approach to attracting and holding users.
App store absence may not be a valid criticism, but the limitation on social media interactivity is. Plugins such as Facebook Login and Google Login can’t fetch data from apps, so users will have to log in separately. On top of that, major social media players are building their own PWAs. They’re interested in promoting their own options, which makes promoting progressive web apps on social media difficult.
PWAs in Action
Despite the complications of progressive web apps, some big companies have seen enough promise to adopt the technology.
Twitter has a healthy user base for their downloadable app, but they wanted to create a responsive mobile presence as well. Developers aimed for a mobile experience that was indistinguishable from their existing native app. Their Twitter Lite Progressive Web App became the default mobile option for Twitter this past April.
In the few months since its release, it seems like Twitter Lite hit the right mark. They’ve experienced a 65% increase in pages per session and a 20% decrease in bounce rate. The Engineering Lead for Twitter Lite, Nicolas Gallagher, revealed another advantage of the app: “The web app rivals the performance of our native apps but requires less than 3% of the device storage space compared to Twitter for Android.”
Lancôme has a spread of small apps for the Android and Apple markets. When mobile traffic to their site passed desktop traffic last year, however, they needed to amp up their mobile presence. A progressive web app seemed like a better choice than competing for downloads.
The Lancôme PWA was released last October. It loads nearly three times faster than the old mobile site. The app is most popular with iOS users, where mobile sessions grew by 53%. Lancôme saw a 17% boost in conversion rates, but what really drove business were the push notifications and reminders. Lancôme was able to remind customers about items left in the shopping cart, and 7% of notifications resulted in a purchase.
E-commerce is a constantly growing field. AliExpress uses a native app for the absolute best user experience. Like many retailers, though, they had a problem with drawing new users. They saw their mobile web presence as a platform for attracting users to their app, and their mobile website was not meeting those needs. It gave users a substandard shopping experience that didn’t represent the brand well.
The AliExpress PWA has been a wild success. Conversion rates for new users has increased by 104%, with 92% conversion rates on Safari. Users across browsers spend 74% more time in the app per session and visit twice as many pages.
Progressive web apps are still a young technology, but they have a lot of promise. They offer workable solutions for most of the biggest problems facing app development: customer engagement, availability, performance. The drawbacks should be worn down as technology becomes more standard.
Can a dynamic progressive web app work for your company? Concepta has the experienced developers to maximize your mobile performance!
Firebase is a backend as a service mobile and web app development platform from Google. Although developers have the option of skipping server-side programming, Firebase’s powerful suite of cloud-based features can expand functionality using server side code.
Backend as a Service platforms provide a subscription-based backend so developers don’t have to write one.
App development platform: Software that allows developers to create and deploy applications.
What problem does Firebase solve?
Firebase helps developers build dynamic, scalable mobile apps quickly. It negates most (if not all) of the hassle of creating and managing infrastructure.
Benefits of Firebase
Remote configuration variables for apps
Performance monitoring/Crash reporting
User management system
Cloud storage and functions
Test Lab for Android
Users like Firebase for its huge feature set (currently 16 well tested features). Developers don’t have to pay for the complete package; they can pick and choose which features they want to use independently of each other. Besides the features listed above under benefits, Firebase offers push notifications, Google Analytics, dynamic links, invites, cloud messaging, AdMob, and Adwords.
Mobile apps are Firebase’s strong point. It’s cross-platform friendly and optimized for realtime apps. Firebase is also scalable; the number of users can grow very quickly without an appreciable affect on performance.
Firebase excels when it come to prototyping. Freed of the need to recreate a custom stack for each mobile app, developers can focus on building their front end and begin generating revenue up to four times faster than possible through non-BaaS methods. In addition, a mobile developer without backend experience could conceivably test a new idea without involving a full-time backend expert. (To be fair, that method would be much slower than traditional app development since one person would be doing all the work. The savings there would be financial.)
Speaking of financial matter, projects with slim budgets are a good fit for Firebase. The large up-front investment associated with backend development is broken into more manageable subscription payments. Shorter app development also leads to lower labor costs since the time of skilled programmers is one of the most significant costs of any development initiative.
The biggest weakness of Firebase is that, while it’s great for prototyping and scales well, it only handles a certain level of complexity. Embedding third party services requires adding a server code. Users also need to to create their own API to integrate their app with Firebase. To build a truly robust application developers use cloud functions to create custom logic for different flows and to integrate with other third party services. This means that once an app grows past that certain level of complexity developers can find themselves doing much of the work Firebase was intended to avoid.
As a NoSQL database, Firebase is not the best solution for large amounts of structured data. It doesn’t easily support transactions and is not HIPAA compliant. There are limits on queries imposed by the streaming data structure.
With subscription services like Firebase, it’s important to remember that this leaves apps vulnerable to potential Firebase issues (company changes or closure, fluctuating prices, disruptions to uptime, etc). Closure isn’t a serious threat since Firebase is a Google project, but there have been notable periods of downtime in the recent past. Migrating to another service could be a significantly difficult experience, too.
Kinvey: While Kinvey is easier to implement with a shorter learning curve than Firebase, it’s priced accordingly.
Couchbase: Couchbase is similar to Firebase. While it is open source, it lacks the bevy of features that attract users to Firebase.
Hoodie: Hoodie’s advantage is its offline support. It has a very small developer community, though, and few of Firebase’s trademark features.
Parse Server: Parse Server was popular, but after struggling with some intrinsic faults Facebook (who owned it) decided to shut it down earlier this year. It is still brought up as a comparable tool to Firebase, though it’s been shuttered.
NPR uses the analytics feature of Firebase to improve targeting and insights. Playbuzz employed a combination of Firebase features to increase campaign efficiency. TradeFix.io, a real time stock/option trading company, uses Firebase in its mobile app.
Within its area of focus, Firebase is enormously successful. Most criticisms of Firebase can be attributed to using it outside that area. For rapid prototyping and deployment, there are few tools that match Firebase for features now that Parse Server is out of the picture.
If you need highly experienced backend developers who know Firebase, share with us your challenges and we’ll help come up with the right solution tailored to fit your needs.