The phrase “there’s an app for that” was popularized and trademarked by Apple in 2009 to advertise the iPhone 3G. While that slogan is now 15 years old, apps are still relevant and even critical for some industries and applications. Over this same period, Apple’s iPhone has held roughly 60% of the U.S. market and doubled its global share. Technology has shifted over the course of these years, with even Apple’s underlying language making a major shift from Objective-C to Swift in 2014. With proliferation of cross platform technologies like React Native’s and Flutter’s ability to deploy to iOS and Android and with even more advances in mobile web technology, in 2025, should you still be thinking: “there’s an app for that”?

Native capabilities

A native app gives you seamless integration with iOS features. Some capabilities, like camera control have been fairly straightforward for a while on the native platform and have increasingly become easier on cross-platform and web. But the closer you get to the device, the harder it becomes to access particular frameworks. Features like device monitoring and reporting often depend on privacy‑focused APIs that are straightforward in native Swift but difficult or impossible to achieve elsewhere.

Apple is also rolling out “Apple Intelligence,” its on‑device AI framework. With Apple’s heavy emphasis on privacy, access to these APIs will be slow and limited on cross‑platform tools. For use cases that depend on new or device‑specific features, a native approach gives you the most direct path to integrating cutting‑edge technologies.

Native user experience

I think of user experience as a triangle:

• Brand – The unique fonts, colors, and themes that make your company recognizable.
• App – The specific identity of each app or line of business (think Coke, Diet Coke, Coke Zero).
• Platform – The conventions and design language of the platform your app runs on.

It’s the platform corner where native iOS development shines. UI elements like accordions or radio buttons may feel natural on the web but out of place on iOS. Ignoring platform conventions is like using the exact same ad on a local radio station and a global YouTube video: it may work, but it’s not optimized.

When you want a native experience you use native UI elements. You might put a tab bar at the bottom of the screen, you most likely have a navigation bar at the top with standard back and close buttons for screen push’s and modals respectively, and you exclude elements from other platforms when they don’t fit (the aforementioned radio buttons on iOS). And when you do, you have a seamless transition to the next look and feel for the platform. Recently, Apple announced “liquid glass.” Whether you are a fan or not, if you’ve implemented native controls in your app, you can update to this new look for nearly free, as opposed to being at the behest of cross-platform tools to update (or not) their libraries.

Simplicity of development and deployment

This concept of nearly free cascades into this next point. If you develop with a native language on the native platform, you minimize the need to accommodate all build paths to different platforms from one codebase. In the words of software development, you give each app one job. By not needing to deploy code to multiple platforms from one codebase you can minimize the debugging effort and potential defect flip-flopping from one platform to the other. You can setup your CI/CD systems, and in the case of iOS, utilizes some built in tools and processes, to get your app from feature complete to the user as quick as possible.

Custom development of unique UI or other experience elements can be endeavored purposely to make your app stand out vs recreating wheels of web interactions on an iOS app. Native date pickers, file interactions, API integrations and other straight forward development is available right from native frameworks. Need example code? Apple’s developer ecosystem offers an abundance of well-documented examples.

So, is there an app for that?

Fifteen years later, there’s still a strong case for native iOS development. If you want your app on a user’s home screen, it has to feel right. It has to perform better than a web app. With iOS leading the market, investing in a high‑quality native experience pays off.

Today, more than ever, there really is an app for that.

I remember what it was like when I first started making things on the computer. I can’t even say they were websites or even code at first. I recall using a program called ResEdit on my dad’s Mac Plus to mess with icons and game resources. Tweaking randomly until something worked. I couldn’t reproduce the patterns that led to success but tried very hard to make sense of them.

Recently, I started working with my daughter on a Raspberry Pi hooked up to a kit car. The directions weren’t great; the most helpful piece of documentation was a YouTube video that moved too fast and was out of date. But we eventually got it working. I shared with her the thrill of repeated failure leading to a flash of success. The 10,000 ways to not make a lightbulb, until we did.

I had a similar experience the other day. I was working on some code and asked an AI agent to build a starter project for me. It worked like magic. I looked it over and wanted to tweak the colors a bit. I poked at it myself but ran into another issue, so I gave it back to the agent. Of course, anything I updated was tossed out. Any slight improvements were one-shot over by the AI. And in some cases, it didn’t even retain its own previous work. I haven’t tried every AI agent or assistant available, but there’s a larger point here.

I was a solo developer in this case, trying to keep my own context while letting the AI write a large chunk of the initial project. If you asked me to explain how the code worked after multiple AI rewrites, I couldn’t without rereading the codebase and reacclimating myself to all the pieces. You often find engineers, and I am not immune, who optimize for code-writing over code-reading, and it was no different here. If I had been on a team, there would have been even more changes evolving the codebase in ways that could cause previous features to disappear. Something I understood yesterday could look completely different today.

This has been a bit of a gripe session about AI-integrated software development so far, but like I said at the beginning, there’s still some magic. For agencies and contracts built around one-shot projects, it’s a perfect fit. Need a website for a one-time event that no one ever needs to maintain? Perfect. Understand that, as has previously been the case, we may need to incur technical debt because of present market pressures? Okay. Need some inspiration or help with a particular error or library feature? Go for it (though I’ve often found that just reading the documentation is more helpful so far).

AI-integrated software development is what everyone is talking about right now. Autocomplete has been a staple of the software engineer’s toolkit for years, and an even smarter autocomplete will be that much more helpful. Tab-completing all the standard method and class documentation? Yes, please. This integration process will be an interesting adventure, one that will require iteration, just like everything else professional software engineers do.

Let’s start iterating, learning, and having our minds blown when things go right (and when they go wrong). I’ve always believed you should understand something before you tear it down.

There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.” - G.K. Chesterton

People (not just old men) are yelling at LLMs to build the thing they have in their head. No longer hindered by not knowing how to build a website or set up a server, they are speaking into existence exactly what they imagined. Vibe coding. Proompts engineered.

This is exactly why everyone hired engineers in the past and now they free from requirements documents, technical specifications, meetings, humans. The role of software engineer and perhaps even wider swaths of the organization can be replaced.

But Seriously

Why did the company founder hire that first engineer, and then a whole team of them? Was it to take words and make them working product? Yes, this is table stakes for a software engineer. Was it only that? No. Here are a few scenarios they hired that software engineer for:

• It’s 11:19pm on a Thursday and for some reason the website stops responding.
• A new feature on the landing page makes the contact link stop working.
• Customers are confused by the purchase page and fail to finalized their purchase.

In short, they solve problems. And they solve problems in real time, in the context of the company culture, product, and constraints. They don’t need constant meetings with the CEO to do it. They are professional software engineers who have seen similar problems before, seek to understand their customers and products, and deliver solutions in a way that AI is still not able to do.

Future generations

Companies are helping train better LLMs for future use (and purchase) rather than training junior engineers in the craft of solving software and product problems. There is no guarantee that your junior engineer won’t move on to another company after you have invested in them but there is certainly not a guarantee that Devin.ai will give you a discount next month because you help build their model. However, centralizing on a handful of LLMs consolidates control of price, creates single sources of failure and in many other ways puts all your eggs in one big opaque basket going forward.

Training the next generation of software engineers alongside your most senior engineers, who can see LLMs as another tool in their tool belt, will pay dividends across the entire landscape of software and product development. It will provide the diversification of skills required for your particular business at exactly the right time. Not with a pricey one-size-fits-all solution but with a real human being who is passionate about their craft and has been trained for exactly this purpose.

If I have seen further, it is by standing on the shoulders of Giants - Isaac Newton

None of us create something from nothing; we are shaped by those around us, both personally and professionally. We assess our strengths and apply them to the task at hand. We co-create with others on our teams and bring to life a product or service that had not existed before to help those around us.

We make plans to wrangle the upcoming problems and build solutions to overcome them. Sometimes, we anticipate obstacles and prepare accordingly; other times, we adapt to unexpected issues. In either case, our goal remains the same: to work more efficiently, produce meaningful results, and continuously improve our products—and our teams. We strive to bring order to chaos, to subdue complexity, and to serve more people through our efforts.

We also bring expertise and craftsmanship to our work. We refine our skills, seek more effective methods, and embrace best practices honed over time. Whether in software development, medicine, construction, or any other field, we don’t settle for the first idea that comes to mind. Instead, we push forward, building on yesterday’s knowledge to create something even better today.

When reviewing feedback on AI-assisted (or AI-generated) code, it often mirrors the feedback given to more junior developers—it’s all about context. One common issue is the rise of duplicate code, as AI tools lack full awareness of the repository’s structure. The solution? The same approach used for junior developers: broader context. If a module already exists that accomplishes the same task, it’s usually best to use it (applying DRY principles at the right level of abstraction). The AI Jr. Dev often struggles to balance maintainability and delivery effectively.

Starting with the belief that everyone deserves dignity and respect is fundamental to creating a great culture, whether in software engineering or any other field. We are born into a shared humanity, beginning life in circumstances beyond our choosing, gifted with abilities through no credit of our own. We did not select our parents or our starting positions, so I am deeply grateful for everything I have been given from the outset.

The strengths we do have should be cultivated, which is why I take a strengths-first approach to leadership. I do not claim to be the best in every area of life, nor would I expect my team to be. That is the value of a team—we bring unique, complementary strengths that, together, drive us toward a greater goal. My focus as a leader is to develop my team’s strengths while supporting their weaknesses through tools, collaboration, and strategic delegation. I do not expect areas where someone performs at a C- level to become A+ work suddenly. Instead, I emphasize helping them refine their strongest contributions—turning A- work into A+—and giving them opportunities to lead in those areas, ultimately strengthening the entire team. People often feel the most passion and fulfillment in these areas of strength.

As strengths are mastered, greater autonomy becomes possible. This autonomy is built on trust that team members can own their work while contributing to the team. Daniel Pink’s autonomy, mastery, and purpose framework, outlined in his book Drive, highlights how these elements foster motivation and productivity. When individuals understand their purpose within an organization and in the broader context of their lives, they are better positioned to recognize and respect the purpose of others, reinforcing a culture of shared dignity.

With this perspective, I approach my work with gratitude. I respect the strengths of those around me and dignify their contributions by granting them autonomy anchored in a clear and meaningful purpose.

This weekend, we had friends visiting from out of town. While waiting to see what my next job opportunity might be, I reflected on the “productivity” of this time. We talked, laughed, ate, and enjoyed each other’s company. Their daughters loved spending time with ours. But I couldn’t help but wonder: Was this a productive use of my time? Should it be? How does it compare to “work”?

Let’s start with the obvious: spending time with friends doesn’t pay the bills (though they generously shared meals with us). Providing for my family is my responsibility, and this weekend didn’t fulfill that directly. Yet, few of us measure the value of a job purely by money. Instead, we aim for work we enjoy, where we can make a meaningful contribution.

So, how do we bring value to the world? Through our talents—unique gifts we use to improve the lives of others. In our jobs, we amplify these talents by collaborating with people who bring their own strengths to the table. Together, we create products or services that help others achieve their goals.

This weekend, we dined out a few times and were struck by how the care and effort of the cooks and servers enhanced our experience. Their work brought joy to our time together. Similarly, while my friends and I didn’t earn money during our time together, we enriched each other’s lives through connection and love, without a team, meetings, or specific career skills.

As I look for my next role, I hope to mirror this: improving the lives of those around me by contributing my talents through a meaningful product or service. In a way, my weekend was “productive”—not in the traditional sense, but in the same spirit as a fulfilling workweek.