Ionic vs. React Native: Compare across core technologies, performance, UI consistency, and integration capabilities to determine the best framework for your mobile development needs.
This blog post will uncover how ilert status pages work, the challenges we encountered while developing this feature, and the problem-solving approaches we adopted.
Observability, beyond its traditional scope of logging, monitoring, and tracing, can be intricately defined through the lens of incident response efficiency—specifically by examining the time it takes for teams to grasp the full context and background of a technical incident.
Building a mobile app often involves selecting the right framework that aligns with your team’s skill set and project requirements. Two popular choices are Ionic and React Native, both of which enable cross-platform development.
In this post, we’ll compare these frameworks and share why we, at ilert, decided to use Ionic for our mobile app.
Ionic vs. React: Quick overview
What is Ionic?
Ionic is an open-source UI toolkit for building performant, high-quality mobile and desktop apps using web technologieslikeHTML, CSS, and JavaScript/TypeScript. Ionic apps are essentially web apps that run inside a native container via tools like Capacitor or Cordova, giving access to native APIs and device features.
What is React Native?
React Native is a JavaScript framework for writing real, natively rendered mobile applications for iOS and Android. It leverages React, Facebook’s popular UI library, enabling developers to build UIs with declarative components that are compiled to native components under the hood.
Comparing Ionic and React Native
Why did we at ilert choose Ionic
We evaluated both React Native and Ionic. Ultimately, Ionic resonated more with our needs and tech stack. Here are the primary reasons for our decision:
Capacitor Capacitor is Ionic’s official cross-platform app runtime. It allows you to build web apps and then deploy them across iOS, Android, and the web with ease. Capacitor offers a streamlined approach to accessing native APIs compared to traditional Cordova plugins, making our development process more efficient.
Consistent UI out of the box Ionic provides a robust library of pre-designed UI components, such as buttons, lists, tabs, and forms that automatically adapt to each platform’s design guidelines. This consistency saved us time that would otherwise spent building and fine-tuning a consistent user interface from scratch.
Capacitor’s native layer flexibility Capacitor integrates with native iOS and Android projects, allowing developers to write custom native code when needed. This flexibility enables us to easily incorporate specialized features or optimize performance-critical parts of our app.
Flexible styling Because Ionic is a web-based framework, we can apply CSS and popular frontend libraries, such as MUI. This approach offers more flexibility in design and theming than React Native’s style system.
Code and component sharing Since Ionic apps are web-based, we can share code, components, and even design patterns from our existing React-based web app. For us, this was a huge advantage—reducing code duplication and ensuring consistency across our product.
Large community and plugins Ionic’s community has grown significantly over the years. Capacitor’s ecosystem is packed with plugins and integrations. The community support and the library help us quickly integrate new features without reinventing the wheel.
When might React Native be a better fit?
While Ionic excels in many areas, React Native also has strengths that might be better suited for some teams:
Heavier emphasis on native-like performance: React Native uses native platform components directly, which can be a benefit for apps demanding highly optimized performance or that heavily use complex native functionality.
React ecosystem familiarity: If your entire team is deeply invested in React (JSX) and is already proficient in React Native’s style and navigation paradigms, React Native can lead to faster iteration.
If your project demands advanced native integrations with intricate animations or direct access to platform-specific UI elements, React Native might be more aligned with those goals.
Ionic vs. React: Making your decision
Ultimately, whether you choose Ionic or React Native depends on:
Team skill set
Does your team have a background in web technologies, or are they more familiar with developing native apps?
Project requirements
Does your app require deep native functionality or are you building an app that closely mirrors a web experience?
Code sharing needs
If you plan on sharing a large portion of code between your web app and mobile app, Ionic can reduce duplication.
Time-to-market
Ionic’s pre-built UI components and familiar web tech can accelerate development for many teams.
React Native can be similarly fast for teams already well-versed in React Native’s approach.
Ionic vs. React: Conclusion
Both Ionic and React Native are strong contenders for cross-platform mobile development. Each framework has its own ecosystem, community, and unique way of building apps.
Choose Ionic if you want to leverage standard web technologies like HTML, CSS, JavaScript/TypeScript, require a consistent UI library out of the box, and seek an approach that simplifies code sharing with a web application.
Choose React Native if you’re already heavily invested in React Native patterns, require close-to-native performance for complex apps, or want direct access to a wide range of third-party native modules.
At ilert, we opted for Ionic due to our existing expertise in web technologies, the flexibility offered by Capacitor, and the ability to reuse code from our web app. This choice has streamlined our mobile development process and allowed us to focus on delivering new features to our users quickly and efficiently.
2025 kicks off with a portion of handy ilert updates!
Deployment events
Deployment events bring your CI/CD pipelines to ilert and enrich your alert contexts, helping to root cause analysis during downtimes. Deployment Pipeline integrations automatically send successful deployment events to ilert and provide you with a 360-degree view into your development process. If an incident happens, engineers have quick access to the latest code changes and can swiftly identify if those changes might have caused a disruption. You will find this new feature under the Alert Sources tab in your ilert account. You can use on of the pre-built integrations, like GitHub or GitLab, or use a generic API deployment pipeline. Our roadmap includes more integrations with popular CI/CD tools! Feel free to share which solution you use and would like to see in ilert among the first at support@ilert.com.
By the way, ilert Deployment events are already available in the Terraform provider, too. See the documentation.
Alert reports 2.0
We have completely revamped ilert reports. The section now has an up-to-date design, and you have quick access to the key metrics: alert volume, MTTA, and MTTR. You will also find more filtering options for a more precise view of your team's and organization's performance.
Even better call routinig
In 2024, we introduced a beautiful, intuitive call routing builder, and now you can try even more features of one of the most advanced hotline solutions on the market!
AI Voice Agent (closed Beta)
We are introducing a new node in the call flow builder: AI Voice Agent! It is a human-like agent for natural conversations and intelligent routing. The Agent handles the first communication with callers, processes the information provided, and, depending on the input, creates an incident or calls an on-duty engineer. This new feature aims to make the first line of interaction via call routing even more personalized and comprehensive and to provide an informative context to on-call engineers before they can take action toward remediation.
The first step in setting up the new node is to define an intent—the reason callers contacted you via hotline. There are various intent options you can choose from: report a critical incident, a system outage, or a security breach, request technical support, and make a general inquiry. You can also configure an intent yourself, assigning specific words and phrases to it. As for the next step, you can specify what information you want to gather from the caller. For example, you can ask for a name, a contact number, or services affected. As soon as the purpose of the call is clear to the AI Voice Agent, it will create a new node in the flow and enrich a notification to on-duty engineers with all gathered data.
If you want to be among the first to test this feature, please let us know by contacting our support team. Please note that only users of the Call-Routing add-on can test it.
Templates
No more need to start a new call flow from scratch. We've created templates for three of the most popular call routing scenarios that you can use as a starting point for your own flow. Simply go to the Call routing tab in your ilert upper menu and start creating a new flow; you'll see new pre-built flows there.
Block numbers
A new node enables ilert users to create blacklists and reject calls from specific numbers. You can find it under the plus icon.
Recurring attempts
We simplified building the flows for recurring attempts when no one answers the call from the first time. You can now set up the number of retries and don't have to rebuild repetitive flows. Find this setting in the Route Call node.
Ring timeout
With the recent update, you can also specify the maximum ring time in seconds before marking the call unanswered and escalating it to the next user.
ITL—ilert template language
The ITL lets you customize and design alerts tailored to your specific use cases. In addition to offering flexibility in formatting and structuring alerts, it also provides a variety of built-in functions to enhance the alerts' readability. ITL also includes functions such as string manipulation, date-time formatting, and joining arrays. This flexibility makes it simple to handle text formatting, data extraction, and transformations, all within the same template. Learn more about syntax in the documentation.
Audit logs
A new feature for Enterprise customers. Audit logs are detailed records of system activity that capture a chronological sequence of events, changes, and actions taken within the ilert platform. Audit logs are essential for tracking system use, ensuring accountability, and meeting compliance requirements.
You can now ask your colleague to cover your shift—partially or fully—right from the app. Navigate to the ilert mobile application menu and find the Request Coverage button in the on-call section below your avatar. You can also do that by going to the "My on-call shifts” calendar and tapping the three-dots icon. If you receive a request, you will get a push notification. Override will be processed only when a recipient accepts the request.
Some of the custom sounds in the ilert app are longer now to ensure you don't miss the call when downtime happens.
The header design color was changed to a more subtle one to improve readability.
If you haven't tried the ilert mobile app, we highly recommend giving it a try! ilert users who regularly use the app see a significant reduction in MTTA. Download for Android and iOS.
Small but helpful improvements
Use a re-route alert action to automatically direct alerts that have reached the end of the escalation policy or haven't been resolved in a specified period to another escalation policy.
For those who don't want to display all the recipients in notifications from ilert Email outbound integration, we've added a BCC field.
Creating an alert from a call flow alert source is even more straightforward now.
Resolve alerts in bulk using ilert global search. Find instructions here.
Integrations
Find even more alert source options that are ready to use out of the box.
Honeybadger.io—a monitoring tool that tracks errors, uptime, and performance in web applications.
ServerGuard24—a monitoring service that provides server performance tracking and alerting for IT systems.
Healthchecks.io—a monitoring tool that tracks scheduled tasks and alerts you if they fail to run.
Amazon DevOps Guru—a machine learning-powered service that identifies and helps resolve operational issues in applications.
AWS CloudTrail—a service that logs and monitors activity across your AWS account for security and compliance.
AWS Security Hub—a centralized service that provides security insights and compliance checks across your AWS environment.
ThousandEyes—a network intelligence platform that monitors application and network performance across the internet and cloud.
As always, you are welcome to request more integrations that are relevant to your business, via our support.
This blog post will uncover how ilert status pages work, the challenges we encountered while developing this feature, and the problem-solving approaches we adopted.
Backstory: Why we introduced status pages
ilert has long been a trusted platform for critical notifications, alerting, and escalation processes. In early 2021, we identified the need to broaden the scope of our offerings to better serve our customer’s needs. This led to a significant refinement in our approach: the separation of notifications into alerts and incidents.
Alerts are critical notifications aimed primarily at development and support teams. They relate to issues such as server anomalies, which may or may not directly impact the overall performance of the client’s systems. On the flip side, incidents signify more severe problems affecting the client's systems, often escalating to affect their end-users. This article has a detailed breakdown of how we arrived at this decision.
By categorizing problems as either alerts or incidents, we were able to tailor our response strategies efficiently. Furthermore, this differentiation logically pointed toward the adoption of status pages as a new core communication tool during incidents, ensuring transparency and up-to-date information sharing to all stakeholders involved.
In mid-2021, we embarked on envisioning the future of status pages. The guiding principles for developing these status pages were twofold: flawless technical execution and seamless native integration with our existing platform. The last one was the most challenging. Back then, there was no industry experience (and not that much even now) of combining an incident management platform and status pages as a natively integrated solution. If you look at the most well-known solutions on the market, like Atlassian Status pages and OpsGenie, those are separate products. We were aiming to combine two solutions as if they were one. And, of course, we wanted to make the status pages a transparent, easy-to-understand feature that enhances the usability of our platform for both our direct users and third-party entities.
Development
Our mission was to ensure lightning-fast performance for both our pages and APIs. Initially, we thought of CDN-based state pages to optimize the rendering process. However, as the development progressed, we faced several challenges with this approach, including dynamic certificate generation for custom domains, speedy status page updates, mutual authentication for private pages, and dynamic content adaptation based on user engagement, among other constraints.
These challenges led us to shift towards a Server-Side Rendering (SSR) approach, using a multilayer caching strategy. We explored various off-the-shelf solutions but found them unsuitable for our needs. So, we developed a custom SSR solution tailored to our requirements, allowing us ultimate control from the initial user request to the final pixel delivery. As a result, we have the ideal performance on both the desktop and mobile devices.
One of the biggest difficulties was the process of preparing the data before rendering the page. We had to completely separate the data needed for the status page microservices from the underlying data, such as the data that the user changes in the management UI.
To achieve this, we deploy a specialized microservice tasked with monitoring any modifications tied to the status page, including updates to properties, incidents, maintenance windows, and services. This microservice receives the necessary data through events from the ilert platform core. Subsequently, this data is transformed into what we refer to as an "invalidation event" and is then dispatched to a dedicated message queue for handling status page updates.
Another microservice dedicated to processing these updates consumes the messages from the queue. It handles the data storage into a long-term database and updates the cache store accordingly. The processing microservice operates continuously, pulling new invalidation events from the event queue as they arrive, ensuring that the information remains current and accurate. This invalidation event structure allows our system to swiftly render and display up-to-date status page information with minimal latency.
This approach also allows the logical components of the platform to be physically separated at the data storage layer, allowing the status page microservices to operate without delay or interruption, even if the main database is experiencing performance issues for whatever reason.
To structure the feature's complexity, we divided status pages into microservices: Gateway, Content Renderer, Content Updater, Certificate Updater and Background Cache Runner.
Gateway. This microservice initiates the process upon each request, locating the status page via the domain name input from the user's browser. It assesses page type and user permissions based on pre-configured settings in the ilert management UI.
Content Renderer. Intervenes once the Gateway authorizes access. It first checks if a pre-rendered page is available in the cache. Public pages or private pages without specific configurations are cached under their domain. Audience-specific pages, however, are individually cached to cater to unique user access restrictions. If a cached page is available, it is instantly delivered. If not, the renderer attempts to quickly generate and cache the page on-the-fly. Should this process exceed time limits, a basic pre-rendered page layout is sent to the user’s browser, which completes the rendering locally, displaying a skeleton loader briefly as the page assembles; this is especially helpful for our larger enterprise customers who sometimes need support to create huge amounts of relationships in their resources.
Content Updater. The microservice processes content updates by first receiving requests from the gateway. It then collaborates with the "Content Renderer" to convert data into an HTML page, which it sends back to the gateway for user display. Additionally, it caches the HTML to speed up future requests, ensuring quick and responsive access to updated content for users.
Background Cache Runner. It signals missing caches to generate the page in the background, regardless of the generation time, ensuring it is ready for future requests in milliseconds. It also updates pages in response to any change from the management UI or related components like services, incidents, or maintenance windows, keeping the status pages up-to-date.
Certificate Updater. This microservice dynamically manages the security of custom domain status pages by consuming events from the Certificate Manager. Upon receiving these events, it automatically updates information related to SSL certificates, ensuring the status pages always operate with optimal security and compliance.
Infrastructure
Our infrastructure is designed around the versatility and reliability of Kubernetes, which orchestrates the deployment of our stateless and stateful microservices. Whether scaling up during peak demands or ensuring fault tolerance, Kubernetes provides the robust backbone needed for uninterrupted service. We use Redis for both caching status pages and facilitating rapid communication between services. By configuring multiple Redis databases, we optimize these processes separately and efficiently to fit the demand of our services.
Page Caching. Redis caches the rendered status pages, allowing them to be retrieved quickly for subsequent requests without re-rendering.
Service Communication. Microservices of our system, such as the Content Renderer, Background Cache Runner, and Certificate Updater, communicate through events using message queues, enhancing fault tolerance and scalability. This setup allows services to operate independently, ensuring system integrity and responsiveness even if one service fails, and enables flexible scaling based on traffic or data demands. It also increases resource efficiency by deduplicating high frequency redundant updates to status pages.
We utilize Redis exclusively for caching purposes across our platform, configuring separate cache databases for almost each microservice like the Gateway, Content Renderer, and Background Cache Runner. This division ensures that each microservice operates independently, maintaining its own cache to guarantee fast, reliable access to data without interference from other services, while we can reduce Cloud costs by scaling instances relevant to their workload. NGINX serves as the reverse proxy and load balancer, efficiently directing user requests to available resources and enhancing security protocols, such as SSL/TLS termination for HTTPS connections.
In terms of security, especially for custom domains on status pages, we employ CertManager within our Kubernetes clusters to automate the management and issuance of TLS certificates, streamlining the security operations without manual interventions.
So, let's put it all together in a rough diagram.
This architecture guarantees that every component is stateless and scalable across multiple instances or geographic locations, wherever Kubernetes can be deployed. The agility that Kubernetes, Redis, and NGINX provide in our setup ensures that we can serve users efficiently and maintain high availability and reliability across ilert.
ilert status pages today
In April 2022, we made ilert status pages available for all our customers. As we continue to innovate and improve, our Kubernetes clusters are now operational in multiple key regions, with plans for further expansion. We also introduced a new type—audience-specific-status pages, and brand new authentication options for our private pages.
ilert's built-in status pages within the incident management platform are inherently more reliable and robust than standalone solutions because they integrate with existing workflows, ensuring real-time synchronization of incident updates. Unlike separate tools that rely on external APIs or manual processes, an integrated status page automatically reflects the current status of the systems without delay, reducing the risk of outdated or incorrect information being displayed. Additionally, this tight integration simplifies maintenance, eliminates compatibility issues, and enhances data security by avoiding sharing sensitive information with third-party platforms.
