Understanding HRV: How Is It Calculated, and What Does It Mean?

Imagine watching an electrocardiogram (EKG) of your heart. Each spike represents a heartbeat, specifically the “R” peaks in medical terms. The time between these peaks is called the RR interval.

In a perfect world, if your heart beats once every second, you’d have a heart rate of 60 beats per minute (bpm). Simple, right? But in reality, your heart isn’t a metronome. The intervals between beats vary — sometimes it’s 1.1 seconds, other times it’s 0.9 seconds.

These tiny fluctuations are what Heart Rate Variability measures. HRV quantifies the variation in time between each heartbeat, giving us insights into our autonomic nervous system’s activity.

Calculating HRV: A Step-by-Step Guide Using RMSSD

To truly grasp HRV, let’s break down how it’s calculated using the Root Mean Square of Successive Differences (RMSSD):

Step 1: Collect RR Interval Data

First, we gather the time intervals between successive heartbeats (in milliseconds):

• RR Intervals: 666, 636, 645, 670, 660

Step 2: Calculate Successive Differences

Next, we find the differences between each consecutive interval:

• 636–666 = 30
• 645–636 = 9
• 670–645 = 25
• 660–670 = 10

Step 3: Square Each Difference

We square each difference to eliminate negative values:

• (-30)² = 900
• ⁹² = 81
• 2⁵² = 625
• (-10)² = 100

Step 4: Calculate the Mean of Squared Differences

Compute the average of these squared differences:

• (900 + 81 + 625 + 100) / 4 = 1,706 / 4 = 426.5

Step 5: Calculate the Root Mean Square (RMSSD)

Finally, take the square root of the mean:

• √426.5 ≈ 20.66 milliseconds

This RMSSD value represents your HRV — a higher number indicates greater variability between heartbeats.

Interpreting HRV: High vs. Low Variability

So, what does this number tell us?

• High HRV: Suggests a healthy, responsive autonomic nervous system. Your body can adapt to stress and recovery efficiently, makes sense right the time between heart rates is more flexible and higher, hence the adaptability.
• Low HRV: May indicate stress, fatigue, or overtraining. Your body might be struggling to cope with physical or mental demands, here your heart rate might be higher and more steady, like when you are in a dangerous situation, you want your heart to beat steadily fast.

However, extremes in either direction can signal issues. An abnormally high HRV could point to arrhythmias, while an exceptionally low HRV might indicate chronic stress or potential health problems.

Again think about its calculation, a too high of an HRV means your heartbeat is not beating rhythmically at all, it’s beating arrhythmically, while too low means your heart rate is always dangerously high, hence too steady, your body assumes you are always in a dangerous situation.

The Autonomic Nervous System: HRV’s Puppeteer

The Autonomic Nervous System (ANS) is the master controller behind HRV. It regulates involuntary body functions like heart rate, digestion, and respiratory rate. The ANS has two main branches:

1. Sympathetic Nervous System (SNS): Known as the “fight or flight” system, it ramps up heart rate and reduces HRV by releasing adrenaline.
2. Parasympathetic Nervous System (PNS): Dubbed the “rest and digest” system, it slows down the heart rate and increases HRV via the vagus nerve.

Balance is key:

• Dominant SNS Activity: Leads to lower HRV, indicating stress, poor recovery, or inflammation.
• Dominant PNS Activity: Results in higher HRV, reflecting relaxation, good cardiovascular health, and stress resilience.

The HRV Paradox: Why the Absolute Value May Be Misleading

Here’s the kicker: The absolute value of your HRV might be meaningless when compared to others.

HRV is influenced by a multitude of factors — age, genetics, fitness level, lifestyle, even the time of day. Your personal baseline is unique. You might have an HRV of 50 and be in peak condition, while your friend has an HRV of 80 with similar health.

Comparing HRV values between individuals is like comparing apples to oranges. What truly matters is how your HRV changes over time.

Your baseline is of importance here, unless you have a too low (approx. <20) or too high of an HRV (approx. >200), everything in between can be totally fine and does not indicate anything.

Studies have shown that with training and mindfulness, you're able to increase your HRV compared to your baseline by roughly 50%.

The Bottom Line: Focus on Personal Trends, Not Numbers

Monitoring your HRV trends can provide valuable insights into how your body responds to various stressors, training loads, and recovery practices. Devices like Whoop or Oura are tools to help track these changes — not absolute judges of your health.

Remember those days when you felt fantastic, but your device reported poor recovery? That’s because HRV is just one piece of the puzzle. It should complement, not replace, how you feel and perform.

Final Thoughts

HRV is a fascinating metric that offers a glimpse into your body’s inner workings. But like any data point, it’s most powerful when used correctly. Instead of focusing on the number itself, pay attention to the trends and what they tell you about your lifestyle.

In the end, listen to your body. Use HRV as a guide, not a gospel. After all, you’re more than just a number.

Just when you thought tech couldn’t get any more thrilling, along comes AI and chatbots crashing the party. Tools like ChatGPT have taken the tech world by storm, making everyone wonder if they’ll soon be outwitted by their toaster. It’s like we’ve opened Pandora’s inbox, and now even our emails are smarter than us. But hey, if AI can handle the small talk, maybe we can finally focus on important things — like debating pineapple on pizza.

A recent paper called “No “Zero-Shot” Without Exponential Data” suggests that there might be a limit to what Gen-AI can reach and that we even may hit that plateau soon.

Let’s not call it AI

Technically speaking, these models rely on neural networks, specifically architectures like Transformers. Imagine a colossal web of mathematical functions inspired by the neurons in our brains — if our brains were made of silicon and had a penchant for number crunching. They train on vast datasets, absorbing more information than a conspiracy theorist on the internet at 3 AM.

Take GPT (Generative Pre-trained Transformer), for example. It uses something called “attention mechanisms” to weigh the importance of different words in a sentence. Think of it as the model’s way of saying, “Hey, maybe I should focus on the noun here instead of that pesky preposition.” It’s like having a conversation with someone who actually pays attention — for once.

During training, the model learns to predict the probability distribution of the next word in a sequence. It’s not generating thoughts or ideas; it’s playing an elaborate game of statistical Mad Libs. It looks at the context you’ve given and fills in the blanks based on patterns it’s learned. Ask it about quantum physics, and it’ll string together jargon that sounds convincing — until an actual physicist rolls their eyes.

Now, calling them “AI” might be giving them a bit too much credit. Sure, they can generate text, images, and even deepfake videos that’ll make you question reality. But do they understand what they’re creating? Not a chance. They’re just number-crunching wizards following algorithms, without a sprinkle of consciousness or genuine intelligence. So, labelling them as AI is like calling a calculator a mathematician. It’s catchy, but doesn’t quite add up.

Now that we speak of a complex mathematical function instead of Intelligence, and we take them as what these tools are, let’s break down what limits they could have.

The Elon Problem

Elon Musk first announced self-driving cars, using machine learning models to drive completely autonomously in 2013. Well, that hasn’t aged well, has it?

Let’s break down the problem, shall we? Humans can learn to drive in a few weeks because we understand the concept of reasoning. We don’t just guess whether turning the steering wheel left or right will avoid that pothole; we know it. We know we live and we die, and that jumping off a building is a one-way ticket to an unpleasant landing. We grasp the concepts of reality — the rules that shape our actions and responses to problems.

We only answer intelligently if we don’t know a problem

Think about when your intelligence really kicks in — kind of like the gas pedal in a car. When do you really use it? Not when you’re just going through your routine, not when you zone out for a few minutes and suddenly realize you’ve been driving to work when you meant to go somewhere else. No, it kicks in when you’re faced with something you haven’t seen before and don’t know how to respond. That’s when you really have to put on your thinking cap and reason out your decisions.

No “Zero Shot” without exponential data

Zero-Shot Generalization: Refers to a model’s ability to apply learned knowledge to new, unseen concepts.

Studies find that the frequency of a concept in the pretraining dataset is a strong predictor of the model’s performance on tasks involving that concept. Performance improvements are not linear but follow a log-linear trend, indicating that models require exponentially more data to perform better.

The models are sample inefficient; they need a large amount of data to make small gains in performance, especially on less frequent concepts.

In simple terms, once a model is trained and believed to have a certain maturity it, counterintuitively, requires exponentially more data to learn something new.

So what does this mean?

I believe we will soon reach a plateau with the current approach to “AI.” Once we’ve fed all the data from the internet — which we’ve mostly already done — and squeezed out the last bit of performance on reasoning tests, our current approach with Generative AI will inevitably reach a point where adding more data won’t yield any further gains in reasoning or intelligence.

Think of it this way: once you have read every book on law and trained on them, you are either a lawyer or you are not. There is a limited amount of content to learn from; most of the books repeat the same concepts. If you’re intelligent enough to grasp the core notions of a field, you either get it or you don’t. Repeated exposure to mostly the same input won’t make you a better lawyer.

We can only reach the next step once we start thinking of layers with different architectures!

Only by changing our strategy of feeding more data to enhance these models and finding a way to implement layers that are architected not purely on data, can we truly — or maybe — reach intelligence or reasoning.

One thing is for sure: OpenAI is already working on it, and who knows, maybe they’re on the right track with o1.

You can reference the paper here: No “Zero-Shot” Without Exponential Data

Who do we need?

So, let’s dive into the most crucial decision: figuring out the roles you need. First off, it all depends on the type of project — Mobile, Web, SaaS, or something even crazier. But you’re not here for a game of “guess the project,” so let’s skip that part. Here’s the golden nugget: start lean. Don’t go on a hiring spree like you’re collecting Pokémon cards; you’ll just end up releasing half of them into the wild a year later.

Devs

For instance, if you need a front-end built, hire the absolute minimum: a few front-end developers, maybe two for the back-end, even better, one or two Full-stack developers and get cracking on forming a team. Focus on building team spirit, keep an eye on efficiency, and see how they gel together. Trust me, fewer people means fewer headaches and more pizza for everyone.

Twice the number of developers never meant and will never mean twice as fast, this is just not how it works.

UI Design

Same rules apply: hire only the folks you really need at the start, and let the team grow naturally. Make sure to snag an experienced designer who can keep up with your developers. Hiring someone too junior will cost you precious time, sanity, and maybe your last remaining hairline. If they build frontends that don’t follow best practices or are overly custom, you’ll burn through resources like a kid at a candy store and end up with a codebase messier than a teenager’s bedroom.

Remember, UI design is its own beast; don’t hire someone just because they made a shiny picture once. There are actual design guidelines, like Material Design, Human Interface Guidelines, and Accessibility Guidelines. The person you hire should have at least heard of these and know how to build interfaces that actually conform to them, not just look pretty on Instagram.

UX Design

Depending on your needs, this could be a separate role — and that’s totally cool. It can ignite some creative fireworks! You need someone who challenges designs and usability, conducts user testing, and finds out how users actually engage with your interfaces and navigate the flow. This person should be the one who grabs the team by the collar (metaphorically, of course) and makes them rethink their approach based on real user feedback.

But if your project doesn’t justify having a separate hire for this, that’s also perfectly fine. You can combine these responsibilities under one roof by having the UI Designer wear the UI/UX Design hat. Think of it as merging two superheroes into one — fewer costumes, more action!

DevOps

Before diving into the magical world of DevOps, here’s a pro tip: don’t jump onto a major cloud provider like AWS or Azure from day one — unless you have a really good reason. Going big on the cloud too early means your developers will end up spending way too much time on “Operations” (yeah, it’s in the name for a reason). This could force you to hire someone specifically for handling developer operations just so your devs can get back to doing what they do best: developing. Keep the responsibilities clear, people!

Maintaining a cloud infrastructure might be standard practice these days, but it’s still a time-sinkhole. You want your devs focusing on building high-quality codebases, not tearing their hair out wondering why some service isn’t running on some cloud provider. So, start simple and scale up when you really need it. Save the heavy cloud lifting for when you’re ready to lift heavy!

Scrum Master

I’ve seen these folks change the game in some cases, like a last-minute sports comeback. But I’ve also seen this role get misused as a glorified project manager or something else entirely. Here’s my take: hire these people when your team is big enough to justify it — like when discussions start spiralling out of control, and compromises are as rare as unicorns. That’s when you need someone to step in, referee the chaos, and get everyone back on the same page before the whole thing turns into a reality show.

These folks are the guardians of the sacred Scrum rituals, and let me tell you, I’m a huge fan. Every single tradition in Scrum exists for a reason — it’s like a carefully crafted recipe. Follow it, and you’ll definitely see results. Ignore it, and you’re just baking a sad, undercooked cake. So trust in the Scrum, my friends, and let these enforcers do their thing!

Project Manager

Let’s talk about the PM role. Some companies think they don’t need one, like it’s an extra piece of furniture. In my experience, the PM role is crucial, depending on the project’s needs. You need someone who has an outsider’s perspective on business needs and is user-centric, like a Jedi master with a lightsaber that smells like customer satisfaction. Ideally, you want to encourage healthy debates on your project. Sometimes you need to defend a perspective to find a compromise, because, let’s face it, informed compromises are the secret sauce of any great product.

So, who should this mythical PM be? Ideally, someone with a hands-on background, either in tech or UX design. Healthy discussions are necessary, but pointless debates are the fastest route to a collective facepalm — especially when one side doesn’t get the requirements or restrictions of the feature or product. The best way to get people involved in decision-making is by putting competent folks in charge — people who know their stuff and can spar on roughly the same level in their respective fields. Nothing kills morale faster than having a clueless buffoon leading the charge, just because you hired them and don’t know how to get rid of them without an awkward goodbye cake.

As your team grows, the PM role becomes more crucial. A lot hinges on hiring the right person, so don’t rush it. Make sure they actually know what they’re doing and have the battle scars in the field and with the type of product you want to build. Once they’re in the game, keep a close eye on the team’s morale and dynamics. Are they working well together? Are they having fun, or does the office feel like the set of a depressing indie film? Remember, a happy team is a productive team, and no one wants to be the boss in a tragic drama.

Tech Lead

This role is responsible for the solutions, the technical direction, and the overall architecture of the product. They need to ensure that the technology stack is appropriate for the project’s goals and can scale as needed. They’re the ones who make the tough calls on whether to refactor or rebuild, and when to introduce new tools or frameworks to keep the team efficient and productive.

A great Tech Lead is both a strategist and a hands-on contributor. They don’t just dictate from a distance; they roll up their sleeves and dive into the code when necessary, leading by example and fostering a culture of excellence. They’re also the go-to problem solver, breaking down complex technical challenges into manageable parts, and helping developers find their way through the weeds when things get tough.

Ultimately, this person is the bridge between the business vision and the technical reality, ensuring that what’s built aligns with the overall goals and is done so in a way that’s maintainable, efficient, and forward-thinking. They drive the team towards innovation, but with a steady hand on the wheel to prevent veering off course. In essence, they’re the glue that binds the technical team together and the compass that guides them toward the project’s success.

Titles don’t matter; responsibility does!

These people can be called whatever you like — the Tech Lead can be called an Architect or might be the CTO of a small startup, working hand-in-hand with the devs, and the Project Manager could very well be the CEO. Titles don’t matter as much as getting things done, knowing who is responsible for what is key here.

How should we work?

Start with the most crucial thing of all: clarifying responsibilities. Be as specific as possible. Best-case scenario? You’ve written everything down and documented it thoroughly for everyone to see. And most importantly, make sure everyone on the team has actually read it — no excuses!

Enforce a culture of feedback. Make sure people know they can come to you when something goes wrong, no matter how high up the ladder you are. Let them know they can criticize you without fearing your wrath. Have regular one-on-ones with the people who report to you, ask for their feedback, and show them you’re never insulted — only eager to get better. Be a considerate listener, and ensure they feel heard, no matter what they bring to the table.

Here’s the most important takeaway of this entire piece: we’re all humans, and building a team is, above all, a people game. Don’t be a jerk — create a respectful atmosphere where people actually want to work with you and with each other. If you sense something or someone is hurting the team spirit, do something about it fast.

Don’t hesitate to let people go if it’s not working out. Set deadlines for making crucial decisions and stick to them, whether it’s about your work or the team’s. Make sure the team knows you can handle rough situations and make important decisions quickly and decisively.

Scrum

Now, a few words on Scrum: I promise I’ll do another piece diving deep into all the methodologies and traditions of it, but for now, remember this — Scrum works if you follow it. And it really works if you take the time to understand the purpose and meaning behind each meeting in the framework.

Make sure your Project Manager understands Scrum inside out and knows how to wield it like a master. For example, ensure that Retrospectives are actually productive and don’t devolve into pointless debates. More importantly, create an environment where people can openly talk about problems without fear and without making it personal. Make sure there are actionable items and follow-ups after every meeting, and aim for each sprint to make the team a tiny bit better than the last. Consistent improvement, one scrum at a time.

Be Hands-On

Chances are, this article isn’t being read by some old-school company where the managers sit at the top like ancient relics who haven’t done anything practical in 20 years.

For everyone else: no matter what your position, get involved and be hands-on. If your idea of “leadership” is just shooting off Slack messages all day and adding to the chaos you likely created, do everyone a favour and hand in your resignation.

Understand your team’s needs, provide direction, and show up at the meetings where your presence matters. Make sure the people you lead feel comfortable bringing their problems to you so you can take action quickly.

And remember, your decisions should empower those in the trenches — the ones actually building the products you care about. They’re doing the most important work. Make sure you know that, and make your decisions count.

How should we set up?

Start with the basics of Scrum, taking it one step at a time. When you encounter a major feature or something particularly complicated, always think about starting with an initial version and iterating on it — never try to fix everything at once.

Set up regular sessions that stick to best practices: Groomings, Plannings, Retrospectives, Dailies, and some extra meetings to introduce new features. Also, schedule regular sessions for whiteboarding complicated features and tackling technical challenges. The key is consistency and communication — like peanut butter and jelly for your project!

Make sure to enforce and foster a culture of following best practices right from the start of the project. Don’t fall into the trap of being too lax in the beginning, thinking, “It’s small right now; no one cares.” Trust me, you should care — and you need to make the team care, too. Best practices in tech aren’t just a checkbox; they’re the bedrock of a successful project. Set clear standards early, and build a culture where everyone understands their importance.

Implement CI pipelines from day one to ensure every piece of code is tested and the application is built correctly — tools like GitHub Actions should be a staple in your workflow. Sweat the small stuff: linting, formatting, and sticking to coding standards. And whatever you do, don’t skimp on code reviews; make them a non-negotiable part of your process from the get-go. Proper reviews catch mistakes early, promote learning, and ensure quality across the board.

Remember, the habits you establish at the start become the norms for the team. By instilling a culture of diligence and excellence early on, you’ll save yourself a lot of headaches later and ensure that your project scales smoothly as it grows.

Before this piece gets too long, I will stop here, follow for more future pieces, where I try to break these down in more detail.

Let’s take a little stroll down memory lane, shall we?

My coding journey began in the murky depths of C++. Eventually, I found myself in the shiny, Apple-scented world of native iOS development, slinging Objective-C and Swift. I was one of those die-hard native development fanboys.

You know the type: “Yeah, bro, nothing beats native development. Users can feel that nanosecond of performance difference compared to cross-platform!”

Yep, that was me. A native purist, preaching from the mountaintop. And then… well, let’s just say, I’ve seen the light, and it’s flashing in a glorious array of cross-platform frameworks.

To be fair, my conversion wasn’t just a sudden epiphany brought on by a caffeine-induced coding marathon. No, it was more of a gradual enlightenment, born from both my own experiences and the evolution of cross-platform tools themselves. But, before we get to the shiny future, let’s hop in our DeLorean and rev up to 88 MPH back to the early days of cross-platform development.

Enter stage left: Java! (Just kidding… kinda.) Java was like that one high school teacher who swore their way was the best way to do things. “Write once, run everywhere!” they said. And sure, you could run it everywhere — as long as “everywhere” included the right JVM and a hefty dose of patience. Java was one of the early attempts to deliver on the “code once, deploy everywhere” dream. But, let’s be real — it was more like “write once, debug everywhere.”

And then came the first true contender: Cordova. (Gotcha! Just kidding again.) Okay, seriously, Cordova, Ionic, Xamarin — they all tried to make it happen. But each of them had their own quirks and ultimately ended up being the quirky sidekick who tries to help but just makes things more complicated. Think of them like the Ross Geller of cross-platform frameworks: lovable in their own way, but not exactly what you’d call “cutting-edge.”

But then, a new wave emerged, bringing with it frameworks like React Native and Flutter. This was different — they didn’t just promise “write once, run anywhere”; they actually delivered a pretty decent experience across multiple platforms. The frameworks matured, the tools got sharper, and developers started realizing that maybe, just maybe, it was worth ditching their “native or nothing” mentality.

Architecture is everything

Let’s start with ReactNative. Sure, it’s a JavaScript framework, but don’t let that fool you into thinking it’s just another shiny web toy. No, no, no. This bad boy was built with some serious thought behind it. React Native was designed with the most basic building blocks of app development in mind, and when it comes to building user interfaces, it doesn’t just fake it with some janky-looking HTML wrapped in a mobile app shell.

Nope. React Native plays it smart. It renders down to the corresponding native components, which means your app looks and feels like it was born and raised on the platform it’s running on. None of that “Hey, why does this app look like a weird cousin of a website?” nonsense. It’s all about those native vibes!

And how does it pull off this magic trick? Under the hood, it’s using something called a “JavaScript bridge” to communicate with native code. Think of it like the secret tunnel system in a spy movie — sneaking in, doing the business logic, and getting out before anyone notices something fishy is going on. Your app gets all the performance benefits of native code while still letting you write in good old JavaScript. It’s like getting to have your cake, eat it, and then find out it’s actually a low-carb, high-protein snack.

Now, let’s talk about my personal favourite: Flutter.

Yep, I’m coming clean — I’ve been coding and building apps in Flutter for years, and I can’t quit it. Seriously, it’s like a bad romance where you can’t tell if you’re addicted or in love.

So, what makes Flutter different? Unlike React Native, which plays nice by rendering corresponding native widgets, Flutter goes full renegade. It doesn’t just borrow from native; it has its own rendering engine called Skia. That’s right — Flutter renders everything itself. Every pixel, every button, every widget is drawn by Flutter’s own engine. It’s like that kid in class who not only brings their own lunch but also cooks for everyone else. And you know what? It works!

This approach means Flutter can run on practically anything with a screen. iOS, Android, macOS, Linux, Windows, the web, your toaster, the display on your smart fridge — if it’s got pixels, Flutter’s got it covered. It’s the ultimate Swiss Army knife of app development.

Now, when Flutter does need to talk to native, low-level code, it uses something called Platform Channels. Think of it like a walkie-talkie between two realms — it’s a clever way to keep both the Flutter side and the native side in sync. But here’s the kicker: Flutter does it smarter than React Native. Why? Because Dart (the language Flutter uses) is both Just-In-Time (JIT) compiled and Ahead-Of-Time (AOT) compiled. This dual nature gives Flutter a little edge in performance and a smoother ride when communicating with native interfaces.

So, while React Native is like the kid who plays by the rules but plays them well, Flutter is the rebel with a cause — rewriting the rules of what cross-platform can be, and it’s not afraid to flex its muscles a bit to show who’s boss.

That’s why, once you’ve gone Flutter, it’s pretty hard to flutter back 😏

(You know, cause the logo is a bird, that took me a while, so please take a moment to enjoy)

Why Cross-Platform Development, will always be the future of Apps

So, if you’ve made it this far, congratulations! Either this article isn’t as bad as I feared, or you’re just really bored. Either way, I’m taking it as a win. And if there’s one thing you should take away from all this, it’s that since the dawn of time, humankind has been on a relentless mission to make things easier. We’re hardwired for evolution, which is just a fancy way of saying we’re obsessed with doing more with less — less time, less effort, fewer headaches. And I’m not just talking about coding apps here; I mean literally everything.

The goal? Get more done with fewer people in less time, solving increasingly complicated problems with whatever tools we’ve got handy. That’s basically how we’ve managed to go from rubbing two sticks together for fire to sending a car into space “for fun.”

Back in the day, when I first started building apps, it felt like launching a full-blown Hollywood production. You needed an entire ensemble cast: one team for iOS, another for Android, and if you had to deal with other platforms like Windows, macOS, or the web, well, congrats, you just doubled your staffing needs. And don’t even get me started on the backend folks. Basically, you needed a small army just to get your app running across all the screens your boss demanded.

But look at us now. Times have changed, my friend. Today, small, agile teams are building complex applications with far fewer people involved. We’re sharing resources and knowledge, reusing code, and ditching the “rewrite everything from scratch for every platform” mentality. Why? Because it’s a massive waste of time, money, and sanity to reinvent the wheel just to get it spinning on yet another screen.

Sure, there might be a few cases where native development is genuinely the better option — although, if I’m being totally honest, I’m not really sure what those cases are. But here’s the thing: the more efficient we become, the more everyday problems we can solve. And that’s what it’s all about, isn’t it?

We’ve come a long way, haven’t we? We started this journey with Cordova, which was basically the equivalent of slapping a browser window inside a mobile app and calling it a day. It was like trying to turn a toaster into a gourmet kitchen — sure, it kinda worked, but let’s not kid ourselves about the results.

Then we levelled up with Ionic. Think of it like Cordova’s more ambitious cousin: still mostly web views, but with some shiny new toys to play with. It was progress, but still felt like that kid in gym class who tried really hard but never quite made the team.

Then came Xamarin, which was like, “Hey, what if we actually got serious about this cross-platform thing?” We started digging deeper, including more low-level code, and improving performance. Now we’re talking! It was better — like going from a rusty bicycle to a sturdy scooter. You’d still feel every bump in the road, but at least you were moving faster.

But after years of trial, error, and a whole lot of “Why doesn’t this work?” moments, our two MVPs arrived: Flutter and React Native. These two stepped onto the scene like action heroes in a summer blockbuster, ready to blow up everything we thought we knew about cross-platform development.

And guess what? Now we’ve reached a stage where we can build scalable, user-friendly apps with performance so fast, it’s basically whispering in native’s ear, “I’m right behind you, buddy.”

It doesn’t seem that they are going anywhere, big names are betting on it, even if they do, history tells us, we will keep trying.

Well, this is it — the end of the line. If you’ve made it this far, I guess I must’ve done something right. So, for the love of all things code, leave a like, smash that follow button, and make my day. Come on, don’t leave me hanging like an unclosed tag in a sea of HTML.