Mike Miller
January 21, 2025

I've been making apps since just after the App Store launched - it's actually what made me want to make apps in the first place. Looking back over this journey, it's amazing to see how much has changed. Let me take you through this evolution, because what's happening right now in mobile development is absolutely incredible.
For about the first seven years after the app stores launched, there was really only one way to make apps - you built them native. On iOS, you were working with Objective-C, and honestly? It was scary stuff. The code was incredibly verbose, and when you were reading it, it was hard to understand what was actually going on. Over on the Android side, you had Java. While not quite as intimidating as Objective-C, Java was incredibly longhand - you had to write tons of code just to do simple things.
Building for both platforms? That meant maintaining two completely separate codebases. But it wasn't just about the programming languages. The APIs for essential features were all pretty rough around the edges. Want to add maps? Complex. Need Bluetooth connectivity? Complicated. Even basic stuff like fetching data from servers and parsing JSON was a hassle. Every feature required deep technical knowledge and a lot of boilerplate code.
Before React Native, the mobile development world was desperately seeking a solution to the duplicate work problem - nobody wanted to maintain two separate codebases. PhoneGap (later Apache Cordova) tried using web technologies, wrapping HTML, CSS, and JavaScript in a native container. Xamarin took a different approach with C#, promising native performance. Some teams even tried using game engines like Unity for business apps, showing just how desperate developers were for a solution.
But none of these early attempts really cracked the code. Whether it was clunky performance, poor user experience, or development headaches, you'd often end up spending more time fighting with the framework than you would have spent just writing native code. The mobile world needed something better.
Then both platforms evolved in a way that changed everything. Apple introduced Swift, and it was a game-changer for iOS development. I was part of that wave - looking at Objective-C thinking "ah, this is scary," then Swift comes along and suddenly I'm thinking "wow, this is so much easier. I can actually really make apps now."
Google wasn't far behind. They saw the success of Swift and introduced Kotlin for Android development. It was basically their version of Swift - a more modern, approachable language that made Android development feel less cumbersome.
At the same time, those clunky APIs I mentioned? They got better. Want to add a map to your app? Much easier. Need to work with Bluetooth or track location? The APIs improved dramatically. Even basic stuff like fetching and parsing data from servers became more straightforward. The barrier to entry was getting lower, but we were still building separate apps for iOS and Android.
Facebook's React Native emerged from a real problem: they had separate teams building the same features for Instagram and Facebook on iOS and Android. Their solution? Take React, which was already gaining popularity in web development, and create a system that could translate React components into native mobile components.
React Native gained huge momentum, becoming the hot new thing in mobile development. But I actually didn't jump on that wave initially. The developers I was working with at the time had a pretty clear take: "Yeah, it's just kind of clunky. It doesn't create a better quality app."
Take Instagram as an example. It's probably the best React Native app ever built - it's an incredible app. But to get there, they had to build tons of custom UI and implementation code. They made it work, and work well, but it required a lot of heavy lifting behind the scenes. This became a common pattern: you could build great apps with React Native, but you often needed to dive deep into native code to get the quality you wanted.
I remember exactly when everything changed. I was watching Google IO, and Flutter was announced in one of these little talks. Right at that moment, I knew that all of mobile engineering, desktop app engineering, and even web development was going to be completely different.
Flutter flipped the script on how we think about cross-platform development. React Native tries to transpile your code into native components, but Flutter said, "Hey, what if native components aren't actually that important?" Instead of trying to use native UI elements, Flutter just draws everything itself, similar to how a game engine works. And here's the thing - my mom doesn't care if an app is made with native components. She has no idea. What she cares about is that the app works well.
This approach means if you write your app in Flutter (using Dart, which is very approachable for JavaScript developers), it can run consistently anywhere - iOS, Android, web, macOS, Windows, even game consoles. One codebase, running everywhere, looking exactly the same.
Now, you might think drawing everything yourself would be resource-intensive, but modern devices have made this a non-issue. Even on lower-powered Android phones, Flutter apps run at really high quality. The development community has noticed too - Flutter has actually surpassed React Native on Google Trends, and every new project I take on now is Flutter.
Let me be clear - we're in the golden era of mobile development right now. This isn't just an iteration - this is the second app store wave. The first wave was "here's the app store, build stuff for it." Now? The tooling has been completely rebuilt, AI has arrived at exactly the right moment, and I believe every idea is going to be tried by anyone in the whole world.
When I'm writing Flutter apps with AI assistance, I'm at least 30% more efficient. And it's not just about coding faster - AI does things I hadn't even thought of. Sometimes you're sitting there thinking, "Okay, I know this can be better, but how?" You just ask the AI, and it'll give you new ideas. That's huge.
But here's the real game-changer: tools like Cursor. That command-K functionality, where you just highlight a block of code and tell it what you want to change? It's magic nearly every time. Want to make a list item look better? Add spacing? Put gaps between elements? These might sound like small things, but they're the tedious tasks that add up over time. Command-K just handles them instantly.
This is actually why I believe native apps are basically dead. When you're making a React Native or Flutter app, you can use all these amazing AI tools in your workflow. But if you want to make a native iOS or Android app? You're stuck using Xcode or Android Studio. Sure, Apple and Google are trying to add AI features to their IDEs, but they're way behind. I tried the Android Studio Gemini tools, and honestly? They took a long time to give wrong answers.
The reality is, for 95% of what developers do, there's no significant value in making a native app anymore. The only time you really need to open Android Studio or Xcode is for very specific native features, and that's becoming rare. Even with things like push notifications that require native code, it's just a small part of the overall development process.
The evolution of mobile development has been a journey of making things easier and more accessible. But what we're seeing now isn't just another step in that journey - it's a fundamental transformation. Projects like Expo are pushing to make React Native even more approachable, and new initiatives like one.dev are trying to unify native and web development.
Even the major players are starting to adapt. Google's launching new tools like IDX, and Apple's beginning to explore AI features in Xcode. They might be playing catch-up, but they see where the industry is heading. The question isn't whether this transformation is happening - it's how fast traditional development tools and approaches will evolve to keep up.
But the most exciting part? The barrier between having an idea and making it reality has never been lower. This isn't just about changing how we build apps - it's about changing who can build them. And that's going to lead to apps and ideas we haven't even imagined yet.

How Top Notification Platforms Handle Quiet Hours & Delivery Windows in 2026
No platform offers per-template delivery windows in 2026—it's either per-workflow (Customer.io, Knock), per-campaign (Braze), or global settings. This comparison shows exactly how six platforms handle quiet hours and send time controls based on their documentation and API specs. Braze leads on AI timing (23% open rate lift from Intelligent Timing across their customer base). Novu is the only platform letting subscribers set their own delivery windows. Customer.io and Knock require manual workflow configuration. OneSignal's strength is push-specific optimization across 300K+ apps. Courier combines per-node flexibility with API control. Includes feature matrix, timezone handling, and frequency capping differences.
By Kyle Seyler
January 16, 2026

Notification Observability: How to Monitor Delivery, Engagement, and Provider Health
Notification observability is the practice of monitoring notification delivery, engagement, and provider health using the same tools and discipline you apply to the rest of your application infrastructure. It means tracking whether messages are delivered, opened, and acted on across email, SMS, push, and in-app channels, then surfacing that data in dashboards alongside your other application metrics. Key metrics include delivery rate by channel, bounce and failure rates, provider latency, open rate trends, and click-through rates by template. Teams can build notification observability through DIY webhook handlers that pipe provider events to Datadog or Prometheus, log aggregation from application send logs, or notification platforms with built-in observability integrations. This matters most for multi-channel systems, business-critical notifications like password resets and payment confirmations, and teams using multiple providers with fallback routing.
By Kyle Seyler
January 15, 2026

SMS Opt-Out Rules in 2026
TCPA consent rules changed in April 2025. Consumers can now revoke consent using any reasonable method, including keywords like "stop," "quit," "end," "revoke," "opt out," "cancel," or "unsubscribe." Businesses must honor opt-out requests within 10 business days, down from 30. The controversial "revoke all" provision, which would require opt-outs to apply across all automated messaging channels, has been delayed until January 2027 and may be eliminated entirely. SMS providers like Twilio handle delivery infrastructure and STOP keyword responses at the number level. They don't sync opt-outs to your email provider, push notification service, or in-app messaging. That cross-channel gap is your responsibility. Courier provides unified preference management that enforces user choices across SMS, email, push, and chat automatically.
By Kyle Seyler
January 13, 2026
© 2026 Courier. All rights reserved.