Humanity continues to move forward, and technology is the driving force that moves us to new horizons. As MartianCraft celebrates its 22nd year in business, alongside the 50 years of Apple, we look back to see what humanity’s past can teach us about our future.

Somewhere in the tall grass of an East African Rift Valley, a couple million years ago, a hand closed around a stone and struck it against another. The flake that broke away had an edge — and that edge changed humanity forever. Not because the tool itself was remarkable, but because of what it represented: a mind that could look at the world and imagine it as it could be, not only what it was.

Every meaningful leap in human history has followed a similar arc: Someone looked at a limitation and refused to accept it.

The 20th century showed that humans, when they put their minds to it, could compress a millennium into a single hundred-year sprint that could drive humanity forward more than they could ever imagine.

The Wright Brothers’ First Flight. Image via Library of Congress.

The Wright brothers’ 12-second flight at Kill Devil Hills (near Kitty Hawk, North Carolina) in 1903 gave way, within a single lifespan, to humans tracking footprints across the surface of the Moon.

Marconi’s crackling transatlantic radio signal in 1901 became the backbone of a global communications network powered by microwaves, twisted copper wires, fiber optics, and satellites.

Alexander Fleming’s accidental discovery of penicillin in 1928 launched a pharmaceutical revolution that roughly increased the human lifespan by 32 years or more.

John Bardeen, William Shockley, and Walter Brattain, the inventors of the transistor. Image via AT&T / Bell Labs. Public Domain.

The invention of the transistor at Bell Labs in 1947 (in large part due to efforts coming out of World War II; see “Chip War” by Chris Miller <hhttps://www.simonandschuster.com/books/Chip-War/Chris-Miller/9781982172015>) was a tiny, quiet thing that set off a chain reaction that would reshape every industry, every government, every household on the planet.

Each of these breakthroughs shared a common element: They didn’t just solve a problem; they expanded the definition of what was possible. And each one demanded a new kind of craftsperson — someone who could wield the new tool not just competently, but with intention and care.

The Dawn of the Personal Computing Revolution

By the mid-1970s, computing had already proven itself indispensable — but only to institutions. Mainframes filled climate-controlled rooms. Terminals were tethered to universities and corporations. The power of computation was real, but it was locked away behind access badges and operator consoles and out of reach to all but a few researchers.

The two “Steves,” Wozniak and Jobs, with their Apple I computer in 1976 at the Homebrew Computer Club. Image author unknown.

Then, on April 1, 1976, in a garage in Los Altos, California, Steve Jobs, Steve Wozniak, and Ronald Wayne signed a partnership agreement and founded Apple Computer Company. It was April Fool’s Day — a fitting birthday for a company whose founding premise sounded to most of the computing establishment like a joke. They thought ordinary people should be able to own computers, and they set out to make that a reality.

MacBook Neo, Apple’s latest computer in 2026. Image via Apple, Inc.

Half a century later, the device in your pocket carries more processing power than every machine NASA used to reach the Moon, combined. Apple’s platforms (iOS, macOS, watchOS, tvOS, visionOS) form the foundation of an ecosystem that touches billions of lives daily. The App Store alone has fundamentally reshaped how software reaches people, how businesses operate, and how developers build their livelihoods. What started as a contrarian bet in a California garage became the single most influential platform company in history.

Today, Apple turns the big 5-0. Fifty years in the making, and they’re still doing what they do best: bringing technology to the masses in a stylish way.

Software as a Craft

Somewhere along the way, the world started treating software like a commodity — something to be produced as cheaply as possible, as quickly as possible, by whoever would do it for the lowest rate. Offshore it. Template it. Ship it fast and fix it later. The prevailing wisdom became about velocity and volume, not vision and craftsmanship.

But software was never a commodity. Not really.

Software is the medium through which modern businesses think, communicate, and serve their customers. A poorly built application isn’t just a technical failure: It’s a broken promise to every user who opens it. A clunky interface, a data leak, a crash at the worst possible moment. These aren’t abstract engineering shortcomings. They’re experiences. They shape how people feel about your brand, your product, your judgment.

The best software has always been built the way the best things in any discipline are built: by people who understand the material deeply, who care about the details others overlook, and who take genuine pride in the finished product. Software development, when done right, is a craft. And like all crafts, it rewards experience, demands discipline, and cannot be faked.

Twenty-Two Years of Crafting

On April 1, 2004, MartianCraft opened its doors — sharing a birthday with the company whose platforms would define our work. The timing was poetic, even if it was intentional. When we started, Apple had yet to enter its most influential years. The Mac was just starting a resurgence, thanks to a massive rewrite to the Mac operating system with Mac OS X. The iPhone was still three years away, the App Store was four years away, and the entire landscape of mobile-first, platform-native software development was way over the horizon.

We were here before the App Store existed. We were building for Apple platforms when “there’s an app for that” hadn’t yet been coined. And for 22 years — from the first iPhone SDK to SwiftUI, from iCloud to on-device machine learning — MartianCraft has been doing the same thing: building exceptional software for clients who understand that quality matters.

That longevity isn’t an accident. It’s the result of a deliberate philosophy. We have never chased the lowest bid, and we have never offshored our engineering. Every line of code that ships is from MartianCraft, written by seasoned developers based in the United States — people who are not just proficient in Apple’s platforms but who are genuine experts, many of whom have been building for these systems since before the iPhone existed.

Our clients are discerning because their products demand it. When the quality of your software is the quality of your customer’s experience, there’s no room for “good enough.” There’s only great.

The AI Inflection Point

All of this brings us to the current inflection point and the answer to a question that dominates every conversation in our industry right now.

Artificial intelligence, and specifically large language models, has arrived with a force that few technologies in the short history of computers can match. Tools like Claude, ChatGPT, GitHub Copilot, and more can generate code, draft documentation, and scaffold entire applications in seconds. The productivity gains are real, the implications are staggering, and, for many in the software industry, the anxiety is palpable.

Will AI replace developers? Is the craft of software engineering on borrowed time?

Here’s what 22 years of software development has taught us: Every major technological shift produces the same fear and the same opportunity.

When the App Store launched, web developers were worried they’d be obsolete. When Swift replaced Objective-C as Apple’s language of choice, a generation of developers feared they’d be left behind. When cloud computing matured, entire categories of infrastructure engineers were told their days were numbered by the onset of “no code applications.”

In every case, the technology didn’t eliminate the need for skilled practitioners. Instead, it raised the bar.

It demanded more judgment, not less. More taste, not less. More understanding of the why behind the code, because the what got easier to produce.

AI is the most powerful amplifier the software industry has ever seen. But an amplifier is only as good as the signal it’s amplifying. Feed it mediocrity, and you get mediocre output at scale. Feed it the expertise of engineers who understand platform conventions — who think in terms of user experience rather than function signatures and who know the difference between code that works and code that’s right — and you get something extraordinary.

This is the future we’re building toward at MartianCraft. Not a future where AI replaces craft, but one where craft is more important than ever. When anyone can generate code, the differentiator becomes the judgment, taste, and expertise that determines which code to generate, how to architect, and why the details matter.

We believe that the crafter behind the tools is important. That skills and experience are what generate the best results. That’s why we use AI as a tool, but never to “vibe code” anything. Our software is hand built, detail oriented, and put through exacting standards that we hold high.

That’s why even the details on our website are thought out and always have a human touch. Articles like this on our site are written by people who are crafting their stories for other humans, edited by humans (hi, Liz!), and have hand-drawn artwork as the chef’s kiss.

The Next Chapter

Fifty years ago, Apple bet that personal computing would change the world. Twenty-two years ago, MartianCraft bet that quality would always matter and that there would always be clients who refused to settle, who understood that their software was too important to hand off to the lowest bidder or leave to an algorithm to decide what’s best.

Both bets paid off. Both continue to.

As we look ahead, the landscape is shifting faster than ever. On-device AI, spatial computing, and platform convergence are creating opportunities that would have sounded like science fiction a decade ago.

The tools are more powerful. The stakes are higher. The margin between great software and everything else continues to widen.

MartianCraft was built for exactly this kind of moment — a moment that rewards deep expertise, principled craftsmanship, and the kind of long-term partnership that doesn’t come from a vendor catalog or an offshored sprint team.

It comes from skilled craftspeople who love what they do and strive for the best products of their work. That’s why we hire people who love the challenge, who push the needle forward. We don’t take the easy way out; we embrace things that are built with sweat and integrity.

We’ve spent 22 years earning the trust of clients who expect the best.

… and we’re just getting started.

AI is everywhere these days. It’s difficult to go a day without hearing something about AI or LLMs. Google searches now include AI overviews, and free services pop up regularly with new AI interfaces to accomplish various tasks. Users can generate images, make art, make music, and, yes, even generate code.

If there’s one thing that history has shown, it’s that ignoring new technology won’t make it go away. More importantly, the early adopters of major advancements tend to pull ahead in related fields.

How You Shouldn’t Use AI

Still, I think it’s important to recognize that what we know as “AI” right now is not true artificial intelligence. We’re seeing exciting new technology that opens up a lot of new possibilities, but it is limited. At this point, most of us have that one friend (or more) that uses AI for everything. While I appreciate capturing the value of tools like AI as much as any tech geek, modern AI is weak when it comes to making decisions within a broader context.

“Building apps in Swift and SwiftUI isn’t quite as easy for AI tools as other platforms, partly because our language and frameworks evolve rapidly, partly because languages such as Python and JavaScript have a larger codebase to learn from, and partly also because AI tools struggle with Swift concurrency as much as everyone else. As a result, tools like Claude, Codex, and Gemini often make unhelpful choices you should watch out for. Sometimes you’ll come across deprecated API, sometimes it’s inefficient code, and sometimes it’s just something we can write more concisely.” — Paul Hudson¹

When it comes to iOS development specifically, what does this mean? It means that AI is excellent at pulling from existing references and resources, known APIs, etc. to create code that compiles and runs (usually) — but that code might not be what you actually need. It may not solve your reported issue, it might be out of date, use deprecated code, use unsafe practices, miss key elements, and so on. To put it simply, don’t trust AI to do your job for you.

Some of you reading this will think to yourself “well duh,” but there will be just as many people who balk or question this statement. “Vibe coding” has been an increasingly popular approach to software development, and while it may have good use cases in my opinion it’s an extremely dangerous path. To be clear, this is not an old man shaking his fist at new technology; rather, this is someone who has already seen vibe-coded apps and features break down and require additional developer time to debug and fix what could have just been written correctly the first time.

A phrase I’ve heard tossed around in software engineering circles is “treat it like a junior developer.” I agree with this sentiment to a degree, but the mindset here matters. It’s important to think about the broader implications of that idea. If you treat your AI tool as a junior developer, that makes you the senior developer. With that comes a few important qualifications to the practice:

• Never ask the AI to do something you don’t know how to do yourself. Why not, you might ask? Well, how would you know if it was done correctly? How would you catch critical mistakes or issues in the implementation? You wouldn’t — and you won’t.
• Review any code an AI wrote as you would that of a junior. Scrutinize it, think of how it fits in the greater context of the architecture, look for common mistakes like memory leaks, redraw loops, etc.. Build it and test that it does what it claims to do.
• Don’t assume or trust that the AI knows the right answer or that it knows something you don’t. If you read the code and your initial thought is “wait, what?”, it’s probably best to be more thorough in your review.

All this to say that the code should be treated as suspect. Because of this, in many cases it might be more time efficient to just do the task yourself.

It’s worth noting that even those companies that have openly embraced vibe coding may be more conservative behind closed doors than their public announcements suggest. Builder.AI, for example, promised a platform that could create apps using vibe coding with no specific expertise required. However, after the company completely collapsed financially (from ~$1.5 billion in value to ~$0), it was revealed that they were using cheap programmers to do the bulk of their coding grunt work, rather than AI. So even a company that wanted to embrace vibe coding found that it was lacking and that they needed human input and developers to finish the job.²

How You Should Use AI

With all that being said, how should we use AI? I’ll be honest, when I first sought to answer this question I found it far more nebulous than I initially expected. I asked around, and for every four developers, I got five answers. There were, however, a few consistent themes in the responses. I’ve come to realize that how (and to what extent) devs use AI is a fairly personal decision, but the bulk of the uses fall into a few categories.

“We can ask it to help break down the problem if we want. We’re still breaking down the problem, we’re still finding the pieces. And so now I actually use AI all day long. I have copilots from GitHub inside of Xcode. … [O]ne of the complaints people have about that is it can’t do like whole apps or like whole views or stuff like that. And I actually like it that way.” — Donny Wals³

Efficiency

The first category that came up regularly was efficiency. AI can look at your project, recognize patterns, and create boilerplate code for you. It can also expand existing patterns if there is a lot of repetitive code required. A good example would be if you need to add another REST API call to your app, you could ask your preferred AI companion to generate the new API based on your existing patterns. You just saved yourself maybe 10-15 minutes of work.

What about a simple SwiftUI view that doesn’t have any special behavior or requirements? AI can do that for you. Need to refactor some old UIKit into a modern SwiftUI view? Probably not an issue. You can even ask your AI companion to review blocks of code for readability, potential risks or bugs, etc. It’s fairly helpful in this regard and can catch things you might overlook.

Additionally, if you use scripting in your development workflow, AI is great at that. The existing documentation and examples for scripting languages are massive compared to that of Swift/SwiftUI, so the AI has a lot more rabbits to pull out of its proverbial hat for that application.

Here’s an important note on all of those uses: Always double check the AI’s work. Again, treat it like a junior developer. It can recognize and copy patterns, but as I mentioned before it doesn’t understand context. The code might work, but make no sense in the broader feature or architecture.

Tests

This one is huge for me. We all love unit testing and the multitude of benefits it provides during large projects. But if you’re like me, you don’t necessarily like taking the time to write unit tests. They can bog you down a bit, and can interrupt your workflow if you’re working on a big task.

This is definitely a place where AI can help. Ask it to write unit tests. Be specific in your prompt for what your expectations are and what you want to test. Let AI generate the bulk of the test, then go in and fine-tune it to your specifications. This is a huge time-saver, and you get the benefits of unit testing-driven development. In addition to writing the tests, you can ask AI to check test failures and quickly identify the cause of the failure. This can be a wonderful tool to save you debugging time.

“Swift Assist serves as a companion for all of a developer’s coding tasks, so they can focus on higher-level problems and solutions.” — Susan Prescott⁴

Debugging and Code Evaluation

Tools like Claude, Cursor, and Copilot can be great for debugging and code review. You can ask the AI to look over your code for any issues, and it will find them. In fact, it will almost always find something. A lot of the time it’s wrong, but it’s also often right, and it can be a wonderful tool.

However, once again, it’s very important to remember that AI doesn’t understand context. It can’t see the bigger picture or understand the overarching architecture of your project. Keep this in mind when you read its feedback. It’s OK to tell the AI when it’s wrong and ask it to remember that, and it’s OK to reject suggestions that would be problematic in ways the AI might not see.

In short, use AI tools to get feedback, but take everything the AI suggests with a grain of salt and carefully consider what its suggestions might do in the broader context of the codebase.

Accessibility

This is a great use for AI, and it supports a best practice that I know many of us sometimes overlook. It can be very easy to write your code and create your user interface without thinking about accessibility features, especially if they don’t affect you directly. This is a workflow you can add to your AI — have it check for missing accessibility features. My AI has called me out on this a couple times, and my only response was “Oh yeah, that’s a good idea.”

Final Thoughts

AI has a wide range of tools that can make a senior developer’s process more efficient and their code cleaner and more polished. It allows us to spend less time doing boilerplate and setup and more time fine-tuning and making cleaner, more robust architectures.

If there’s one major takeaway from this discussion, I would say it like this: AI is a new suite of tools for engineers, not a replacement for them. Everything an AI can generate requires someone with genuine knowledge, expertise, and understanding of the requirements, the broader context, the target audience, etc. to bring the project home.

Never be afraid of using the newest, greatest tools. Anyone who rejects AI tools outright is very likely to fall behind at this point; but on the other hand, anyone who thinks AI is a replacement for an engineer who can provide the informed analysis on the project will find themselves tying their own hands.

Apple just did something wildly out of character.

On February 3, the company that rehearses Keynotes for months and guards product secrets like nuclear codes just … dropped a beta. No event. No Tim Cook. No “one more thing.” Just a surprise Xcode 26.3 release with features that weren’t even on the roadmap, complete with tutorials and an open invitation to try it now.

What’s inside? AI agents that can actually control Xcode.

Not “suggest the next line” AI. Not “autocomplete on steroids” AI. We’re talking AI that reads your entire project, understands your architecture, refactors dozens of files simultaneously, fixes bugs, writes tests, and interprets compiler errors — while you’re in a meeting.

You know that moment in sci-fi movies where someone says “Computer, fix the hyperdrive” and it just … does? We’re there. Except it’s “Claude, add Dark Mode support” — and your iOS app suddenly has Dark Mode.

Three weeks ago, this was science fiction. Today, it’s a beta download. Let’s talk about what just changed.

What is MCP?

Model Context Protocol (MCP) is an open standard created by Anthropic that allows AI models to securely connect to external tools, data sources, and applications. Think of it as a universal adapter that lets AI assistants like Claude interact with your development environment in a structured, safe way.

Instead of you copying and pasting code suggestions from a chat interface, MCP lets the AI actually interact with Xcode — reading your project files, understanding your app’s structure, running builds, and even making changes directly. It’s like having a knowledgeable pair programmer who can actually touch the keyboard.

MCP offers a powerful, standardized protocol for tool integration, surpassing traditional IDE plugins. Its client-server architecture, with Xcode as the MCP host and AI agents as clients with specific permissions, enables context-aware assistance that factors in your entire codebase, not just the open file.

MCP empowers AI to become a true development teammate, not just a code suggestion tool. Its standardization ensures consistent AI-assisted development across tools and continuous improvement as the ecosystem matures.

With Xcode supporting MCP, you don’t have to copy and paste code between the chat and your files; instead, the AI agent can take control of Xcode using data and context providers Apple has included.

What is Agentic AI?

Agentic AI refers to AI systems that can take autonomous action to complete tasks, rather than just responding to single prompts. An agentic AI can plan multistep workflows, use tools, make decisions, and iterate on solutions without constant human guidance.

Traditional AI code assistants are like having someone suggest the next line of code. Agentic AI is like delegating an entire feature implementation. You might say “Add dark mode support to this app,” and the agent will analyze your code, identify all the files that need changes, make those changes, test them, and fix any issues it finds — all with minimal supervision.

Agentic systems use reasoning and planning capabilities to break down complex tasks into subtasks, execute them using available tools (through MCP), evaluate results, and adjust their approach. In Xcode 26.3, this means the AI can navigate your project structure, analyze dependencies, run the compiler, interpret errors, search documentation, and iteratively refine its solutions. It’s particularly powerful for refactoring, fixing bugs that span multiple files, and implementing features that require coordinated changes across your codebase.

This represents a force multiplier for development teams. Rather than speeding up individual coding tasks by 20-30%, it can potentially handle entire features autonomously, allowing senior developers to focus on architecture and complex problem-solving while the AI handles implementation details. This could dramatically compress development timelines for certain types of work.

How Do I Set Them Up?

The first step is getting Xcode 26.3. As of the publication of this article, Xcode 26.3 has now been released publicly and is available from the Apple Developer Downloads (https://developer.apple.com/download/all/?q=Xcode) website or the Mac App Store (https://apps.apple.com/us/app/xcode/id497799835?mt=12).

When you launch Xcode 26.3 for the first time, you’ll get the dialog above, giving you some information about the release and a video link to see more details (https://developer.apple.com/videos/play/tech-talks/111428).

To get started with agentic AI development, go to Settings (Command+,), select Intelligence, then choose either the OpenAI or Anthropic provider. Click “Get” to download the models for interacting with Xcode for your provider. Next, you’ll need to authenticate with your provider.

You need a paid account with either OpenAI Codex or Anthropic Claude to use them with Xcode. If you have a subscription plan, it’ll utilize the usage available in your subscription first, then any API access you have allowed for your account.

Once you’re signed in, you can also select the models that should be used for Xcode, if supported. For Anthropic, you can select between Opus, Opus + Sonnet, or just Sonnet. Opus is the highest reasoning model from Anthropic while Sonnet can give you a better cost to reasoning approach for smaller tasks that don’t require as much reasoning about the situation.

When you’re ready to begin, toggle the Coding Assistant by clicking the Intelligence icon in the left pane or by pressing Command+0.

The Coding Assistant has a message box at the bottom where you type your prompt and an attachment button that lets you attach an image for mockups or other visual aids that can help the model process your request. Type in a prompt, and it’ll jump into action. Thanks to the MCP integration with Xcode, Claude and Codex can really shine, interacting with the Xcode project fully: creating new files, refactoring efficiently, even making provisioning changes without you lifting a finger.

The best part is that you get rich in-line previews of code and SwiftUI previews — plus the app automatically builds itself, checks for errors, then fixes those errors, ensuring that when the agent is done, the app builds cleanly and is ready for manual or automated testing.

We really like the way Apple has integrated the Coding Assistant into Xcode and can’t wait to see what is next for Xcode and MCP integration. We think the best way to experience this is just to write prompts with it. So let’s take a look at how you can get started in your own iOS projects.

Writing Your First Prompt

The key to effective agentic AI development is learning to delegate tasks rather than micromanaging code generation.

Starter Prompts for Beginners

Start with contained, well-defined tasks:

“Add a new SwiftUI view called SettingsView with toggles for Dark Mode, notifications, and haptic feedback. Use the same styling as ProfileView.”

This gives the agent clear constraints and a reference point. The agent will:

• Create the new file in the appropriate location
• Implement the UI with proper SwiftUI patterns
• Match the styling you specified
• Update your navigation to include the new view, if needed

“Fix the memory leak in ContentView. The images aren’t being released when the view disappears.”

The agent will analyze your code, identify the leak source, and propose a fix.

Intermediate Prompts for Experienced Developers

Once you’re comfortable with the starter, you can delegate more complex work:

“Refactor the networking layer to use async/await instead of completion handlers. Maintain the existing error handling behavior and update all call sites.”

This is a tedious but straightforward refactoring that touches many files — perfect for an agent.

“The app is crashing when users rotate the device on the detail screen. Debug this and implement a proper solution.”

The agent will run the app in the simulator, reproduce the crash, analyze the stack trace, and implement a fix.

Advanced Prompts for Senior Developers

“Implement offline support for the entire app. Cache all API responses locally, sync changes when connectivity returns, and handle conflict resolution using last-write-wins strategy. Update the UI to show sync status.”

This is a multiday feature that the agent can break down into subtasks: setting up Core Data or SwiftData, implementing the sync engine, modifying all network calls, adding UI indicators, and testing various offline/online scenarios.

“Our test coverage is at 45%. Analyze the codebase and write unit tests for all ViewModels and service classes, aiming for 80% coverage. Focus on edge cases and error handling.”

The agent will examine your code, identify untested paths, and generate comprehensive test suites.

Best Practices

• Be specific about constraints: Clear directions like “Use SwiftUI, not UIKit” or “Don’t modify the existing database schema” help the agent stay aligned with your architecture.
• Reference existing patterns: Pointing to a file by name, like “Follow the same pattern as UserViewController,” tells the agent to maintain consistency.
• Iterate in conversation: If the first result isn’t quite right, you can refine, such as: “That works, but use Combine instead of async/await for consistency with the rest of the app.”
• Review everything: Agentic AI is powerful but not infallible. Always review changes before committing, especially for production code. Remember that you are the developer in charge, use the AI to your advantage and always feel free to prompt the AI in the same way you would a junior developer: If you want something done a specific way, be sure to tell it.
• Start small, scale up: Begin with low-risk tasks (like writing tests or documentation) before delegating critical features.

What This Means for iOS Development

For individual developers, Xcode 26.3’s agentic capabilities can eliminate much of the tedious work that slows down development — boilerplate code, refactoring, test writing, and bug hunting. This frees you to focus on what humans do best: creative problem-solving, user experience design, and architectural decisions.

For teams and organizations, this technology could significantly compress development timelines for certain types of projects, particularly those with well-defined requirements and established patterns. However, it also raises important questions about code review processes, testing strategies, and how to effectively manage AI-generated code at scale.

The real power of Xcode 26.3 isn’t that it makes AI write code faster — it’s that it makes AI a collaborative partner that can analyze your entire project context and can take meaningful action. Whether you’re a solo developer building your first app or a CTO managing a large iOS team, the agentic development paradigm is worth exploring.

You’ve probably heard the buzz phrase “vibe coding,” but do you know what it means — or whether you should be jumping on the bandwagon? In this article, I’ll introduce you to the pros and cons of this way of developing code and talk about how you can get started with it.

At MartianCraft, we focus on building iOS apps in Xcode, so the models and tools I’ll discuss will be specific to that — but the overall ideas apply to any kind of development.

So, what is vibe coding?

The term “vibe coding” was coined in February 2025 when Andrej Karpathy posted about using AI tools like Cursor and “fully giving into the vibes” — forgetting code even exists while developing through conversation with an LLM.

The idea of vibe coding grew and gained momentum throughout 2025 as LLMs improved, making it easier for people to use them to create code. But the development community continues to have mixed feelings about vibe coding, with some viewing it as a tool that improves productivity and others believing that it makes people worse developers.

Before AI, developers spent a lot of time and energy not only writing code (including boilerplate code) but also researching, viewing code from other projects, correcting false starts, and so on. The promise of AI is that you don’t need to do that anymore: You can just ask the model to generate the code you’re looking for, whether it’s boilerplate or, in some cases, a full-blown app. You can also use it as a coding assistant that can debug and answer questions about your code. But does the reality live up to the promise?

At MartianCraft, we consider vibe coding to be one more tool in our toolbox — and as with any tool, it’s important to understand its strengths and limitations. Let’s start with the basics of LLMs.

Large language models

LLMs, or large language models, are a type of AI that can recognize text, images, videos, and more, based on specific training. The most common form of LLM is the one you’ve likely come across that responds to text (and now image) prompts through a chat-based interface, like ChatGPT or Claude.

One of the things that make LLMs so powerful is that they can be trained: You can teach a model to become an expert in a specific area. For example, on OpenAI’s GPT Store you’ll see models that focus on a variety of niches, including one that focuses on SwiftUI.

However, LLMs definitely have some limitations and restrictions. Here are some of their most basic limitations:

• LLMs are not human, no matter how conversational their replies are. Don’t expect them to comprehend beliefs or emotions, or to think like a real person.
• LLMs are almost always confident about their answers, but those answers are sometimes completely wrong (so-called hallucinations). You always need to double-check what they have to say.
• LLMs have no built-in real-time knowledge. In fact, every LLM has a cutoff for its knowledge base — for example, the cutoff for ChatGPT 5.1 is mid-2024. So if you ask ChatGPT about breaking news or, say, when iPhone 17 was released, it can only answer by scraping the web for current information. If you were to turn off web scraping, it couldn’t tell you when iPhone 17 came out.
• LLMs also have limited long-term memory. When you interact with them, they only store tiny bits of information from the conversation, not every detail. If you want to reference something from a conversation several days earlier, you will more than likely have to re-enter the information you discussed.

So LLMs are very powerful, but you have to watch for hallucinations and outdated information, which they will present with total confidence.

LLMs and coding

For coding, this means you have to be extra careful when you’re dealing with relatively recent APIs. Let’s say you want to integrate Liquid Glass into your SwiftUI app. Liquid Glass was introduced in 2025, so it’s not part of ChatGPT’s knowledge base. If you ask ChatGPT, it will more than likely provide you with code it found on the internet — which might be fine — but its knowledge limit means that it won’t incorporate the best practices in Apple’s developer documentation.

On the other hand, using an LLM to build code — vibe coding — takes advantage of a trained AI’s strengths in pattern matching and consistency. It can be a helpful tool for a variety of development roles.

Designers

Vibe coding can be a great tool for designers who don’t know how to code to start learning, whether they want to expand their skills as a dev team member or to build hobby products that they’ve designed for themselves. And although designers who do have experience coding are more rare, they can also use vibe coding to their advantage — in fact, they probably have the highest potential of building a successful product through vibe coding. This type of designer understands user experience and user interface design, and they can bring those designs to life via code thanks to AI.

Beginning developers

Vibe coding is a great way to learn how to code. You can ask the model to build a feature and then ask it to break the code down. You can also ask the model questions, like “I want to integrate Core Data into my app, can you lay out the instructions on how to do that?” The model will break down how to add Core Data, including the entities, attributes, and relationships you need. Then, you can ask the model to generate the code to fully integrate Core Data in your app. And if you get stuck, the AI is there to help. This can be a great way for beginning developers to get experience with complex tasks.

One caveat, though, is that AI-generated code should never go into a production codebase until it has been reviewed by an experienced developer who understands app architecture, security issues, and the other important factors that go into creating user-ready apps.

By the way, if you’re learning to code you can also copy open source code into an LLM and ask it to explain the code for you. That may not fall under the category of “vibe coding,” since you’re not generating code, but it’s a great way to use the tool to increase your coding knowledge and skills.

Mid- to senior-level developers

If you have some experience with development, you’re in a great position to really put vibe coding to work for you. Experienced devs can use AI to generate template code for specific features that they can then iterate to their liking, so they don’t have to start coding that feature from scratch. They can also use it to help clean up their code, fix bugs, simplify over-complex logic, modernize code (such as converting UIKit code to SwiftUI), build more complex user interfaces, and more.

As a mid- to senior-level developer, you likely spend time waiting for more novice devs to complete redundant or tedious tasks. Working with an LLM can allow you to generate and review code in a fraction of the time. And having knowledge and experience means that you can carefully review the AI output to catch errors and steer the LLM to produce results that work for you.

Which brings us to the topic of prompts.

The art of vibe prompting

Prompts are at the core of being an effective vibe coder. A prompt is simply the instruction given to the AI model, but the way it’s phrased determines the quality of the response you get back from the model. Well-structured prompts are detailed enough to guide and give the model a direction. With the right prompt, you can build anything. Let’s look at some examples of stronger and weaker prompts.

Here’s an example of a weak prompt: “Build a to-do list app in SwiftUI.”

This prompt is much too vague and doesn’t give the model any kind of solid direction. It doesn’t define any features or specify any additional tech stacks. There are no UX or UI expectations. A prompt like this can cause the model to make a lot of assumptions, which can lead to results that are not what you had in mind.

A better prompt would look something like this: “Build an iOS to-do list app using SwiftUI and SwiftData for iOS 17+. App requirements are: the ability to add, delete, and mark a task completed. The app will need to persist data locally using SwiftData. I want the project to follow the MVVM style, and it also must support light and dark appearances. Use a clean, Apple-style UI.”

This prompt provides the model with a clear tech stack, feature scope, UI and UX directions, and information on how to organize the files. It’s much more likely to produce the results you’re looking for, especially with a few rounds of iteration.

While it’s important to give the model enough information to work with, you also need to make sure that the information you provide is clear and actionable. Here’s an example of an overcomplicated prompt:

“Build an iOS to-do list app using SwiftUI or UIKit. I prefer SwiftUI, but if you think UIKit is better, use that. Use MVVM or something similar, but not too rigid. The UI should be minimal and also customizable, modern but timeless, and mainly optimized for power users and beginners. Should also support 15+ but must use the new APIs where possible. Can you include analytics, notifications, background tasks, and any type of accessibility options too? The app also needs to be able to scale to millions of users, but it needs to be simple. Don’t over-engineer it, but make sure it’s production ready.”

A prompt like this is unlikely to produce good results (or maybe any results). There’s no clear direction: The requests are all over the place, and some of them are confusing, like “The UI should be minimal and also customizable.” Customizable how? It would be better to provide an example of how the UI can be customized to help direct the model. Also, asking the model to decide the best approach means that it has to first come up with a solution, and then compare that solution to other solutions to make sure it’s truly the best one. All the while, it has to factor in completing all the tasks in the prompt — it will end up getting overwhelmed, and the response will suffer.

Learning to write prompts with the right balance of detail and conciseness takes a bit of trial and error, but the good news is that you can see the results quickly and adapt your approach until you’re getting the results you’re looking for.

AI models and tools

For those who are ready to start integrating AI into their workflow, what’s the best way to do that?

First, it’s important to understand the difference between AI models and AI tools. Models are the underlying LLMs, such as GPT-5, Claude, and Llama. Each model has unique training data preferences, token limits (more on tokens in a moment), and performance characteristics.

Tools, on the other hand, are applications or platforms — like Cursor, AlexCodes, or Xcode’s predictive code completion — that make these models available for developers to use. Some tools offer access to multiple models: AlexCodes, for example, gives you the freedom to select which model you want to use on the fly. This can be good for when you’re building different types of apps and you want to rely on the strengths of different models for different tasks.

Next, you need to understand the role of tokens for AI users, both as an individual and for enterprises. A token is basically the unit of thinking for AI. It’s a unit of data — like a word, a piece of punctuation, or even a part of a word — that the model breaks text down into in order to process and generate language. For comparison, you can think of tokens for AI as being like pixels in images or frames in videos. There are two types of tokens: input tokens, which are generated from your prompt and sent to the model, and output tokens, which the model sends back in response to your prompt.

Why does this matter to you as a user? Because, unfortunately, you have to pay for them. Tools offer a certain number of free tokens, but beyond that, any time tokens are being generated, you’re getting charged.

For example, as an individual using OpenAI’s ChatGPT app on the free plan, you are likely to quickly hit your account token limit. At that point, you will have to upgrade your account to use more tokens. But even as a paying user you can still hit token limits, depending on how long the conversation is, how long your prompts are, and the tasks in your prompts. You’ll receive an alert as you get closer to your limit, and in this case it’s suggested that you start a new conversation with the model so the model can continue to perform at its best.

For an enterprise with an AI chat feature in your app, your monthly usage bill is determined by the amount of tokens being generated in your app. You’ll also be charged for all the API calls made. As you can imagine, as your user base scales up, AI can get costly: More users equals more tokens. More tokens equals rising cloud bills, unpredictable costs, and pressure to figure out ways to optimize prompts to reduce cost.

So tokens can be a headache, whether you’re an individual consumer or an enterprise. As a consumer, determining the right plan for you depends on how much you’re going to be using the tool. On the enterprise side, it’s all about monitoring costs and figuring out ways to reduce them.

Below are some comparisons of popular AI models and AI tools you can use with Xcode to build iOS apps.

Comparing popular models

Comparing popular AI tools for Xcode

Final thoughts

Lastly, there are a few important things to keep in mind when you’re vibe coding. They boil down to this: Vibe coding isn’t a substitute for development knowledge.

It’s a great way to learn by seeing code generated for you, but most AI-generated code is outdated — or worse. Until AI model imitations truly become limitless, I wouldn’t trust it to build an entire app on its own.

Vibe coding can lead to real issues later down the line for your app, especially around scalability and security. AI-generated code can be more complex than it needs to be, and it can include inefficient logic that can cause bugs, performance problems, or even vulnerability as your app’s user base grows.

In short, vibe coding should be used as a tool, not a replacement for the human work of development. Understanding how to code is essential for getting the most out of vibe coding. For iOS development, Apple’s Swift documentation is a great place to start.

As we step into 2026, the landscape of iOS development is undergoing one of its most significant transformations in over a decade. At MartianCraft, we’ve spent years at the forefront of Apple platform development, and the convergence of technologies we’re witnessing today feels genuinely unprecedented. From Apple’s bold new design language to the democratization of on-device AI, from revolutionary improvements to Swift’s concurrency model to the maturation of spatial computing — this is a pivotal moment for anyone building applications in the Apple ecosystem.

This article explores the key technological advancements and emerging trends that have captured our attention, imagination, wants, and desires. Whether you’re a C-level executive evaluating technology investments, a product leader planning your roadmap, or a fellow developer eager to understand what’s coming, we hope this serves as both a practical guide and an invitation to share our excitement about what lies ahead.

Apple Intelligence

Last year, Apple worked to add Apple Intelligence throughout iOS 26, even going as far as opening up their on-device models to third-party developers through Foundation Models. This was a game-changer for so many applications, which can now implement artificial intelligence without relying on costly APIs and usage from Anthropic, Google, or OpenAI.

This opened the flood gates for apps to offer better AI solutions to end users, but many developers found these models to still be lacking. Some of the chief complaints with the local Foundation Models have been that it’s slow and that it can’t process the amount of data that you can do with specialized services.

Apple has solved these local Foundation Model challenges with their Private Cloud Compute system. This system was developed to integrate with Apple’s own LLM servers or partner APIs to process larger tasks that require more power — securely and without exposing user data. Of course, the local models were made available to developers, but the Private Cloud Compute integration is exclusive to Apple’s first-party apps, including the Shortcuts app.

We’re excited to see the work that Apple has done over the past year with the local models and their PCC models. We’re also hoping that Apple opens up their PCC models so that third-party developers can integrate with them with an API, even if it means that Apple charges for usage like they do with WeatherKit and other developer APIs and tools.

Siri

Siri was supposed to receive a major overhaul in iOS 26, but it seems that Apple has yet to deliver on that feature. Most recently we’ve seen that Apple is planning on partnering with Google to integrate their Gemini AI platform with Siri to process requests and beef up the reliability of the virtual assistant that has been on our iPhones since iPhone 4S.

As we look forward to this year, we’re hoping to see Apple deliver on this promise and actually make Siri improvements that show notable impacts to users and developers alike.

App Intents and the Promise of Real Integration

The evolution of App Intents represents one of the most significant opportunities for third-party developers to finally make their apps first-class citizens in the Siri ecosystem. With the App Intents framework, Apple provided the foundation for apps to expose their functionality in ways that Siri can understand and execute — but the developer experience and user discoverability remain challenging.

What we’re hoping to see this year is a more intelligent Siri that can actually reason about the intents our apps expose. Currently, users need to know the exact phrase or shortcut name to trigger many app-specific actions. With the integration of more capable language models, Siri should be able to understand natural variations and contextual requests. If a user says “show me my recent transactions” in a banking app, Siri should be smart enough to map that to the appropriate App Intent without requiring the user to memorize specific trigger phrases.

We’d also like to see improvements in how Siri handles multistep workflows that span multiple apps. The Shortcuts app has shown us what’s possible, but these workflows shouldn’t require manual setup for common tasks. Imagine Siri understanding “I’m heading to the gym” and automatically updating your workout app, adjusting your smart home settings, and queueing up your exercise playlist — all through intelligently chained App Intents.

Perhaps most importantly, we need better debugging and testing tools for App Intents. Currently, developers are working somewhat in the dark, unsure of how Siri will interpret their intents in practice. Apple could dramatically improve the developer experience with better Xcode integration, simulation tools, and analytics showing how users are actually trying to invoke our app’s functionality through Siri.

Liquid Glass Improvements

Liquid Glass was Apple’s biggest design changeover in iOS since iOS 7. It’s a very divisive design change: There are folks who absolutely love the design, and there are people who absolutely hate the design. Love it or hate it, we’re looking forward to stability with the new design in the same way we saw improvements to and stability in the iOS 7 redesign inside iOS 8.

The iPad Challenge

The iPad implementation of Liquid Glass has been particularly contentious, and for good reason. The larger canvas of the iPad exposes many of the design system’s growing pains in ways that the iPhone manages to hide. The translucent, flowing aesthetic that feels premium and spatial on a 6.1-inch screen can feel overwhelming and disorienting on a 12.9-inch display.

One of the primary challenges is information density. The iPad has always been about productivity and multitasking, but Liquid Glass’s generous spacing and emphasis on negative space often feels at odds with these goals. Many productivity-focused apps have reported that their iPad interfaces now show significantly less content per screen, forcing users to scroll more frequently. The beautiful glassmorphic cards and panels that define the design language consume substantial screen real estate, and on the iPad, this feels like a particularly wasteful trade-off.

The multitasking experience presents another set of complications. Split View and Stage Manager were already complex features to design for, but with Liquid Glass’s translucent layers and dynamic blurring effects, maintaining visual hierarchy and ensuring that interactive elements are clearly distinguished has become significantly more difficult. When two apps with Liquid Glass interfaces are side by side, the layered translucency can create a visual soup where it’s unclear which controls belong to which app.

We’re hoping that iOS 26 dot releases and iOS 27 and beyond will bring refinements specifically tailored to the iPad’s unique needs. This might mean more aggressive information density options, clearer visual separation in multitasking scenarios, or even context-aware adjustments to the Liquid Glass effects based on what the user is doing. Apple has historically been thoughtful about these kinds of platform-specific considerations, and we’re optimistic that they’ll continue to iterate on the iPad experience throughout the year.

We’d also like to see Apple provide better tools and guidelines for developers navigating these challenges. The current design resources don’t adequately address how to balance the aesthetic goals of Liquid Glass with the practical needs of information-dense applications. More comprehensive design patterns for tables, lists, and data-heavy interfaces would be invaluable.

Claude Code and Other LLM Agents

Over the past two years, LLMs have changed the way that we do development for iOS applications. There’s still a lot of improvement to go, but the landscape is changing right before our eyes.

The Swift and SwiftUI Gap

The promise of AI-assisted development has been tantalizing, but the reality for iOS developers has been more complicated than for our colleagues in web development or backend engineering. The fundamental challenge is that Swift and SwiftUI are relatively niche languages in the grand scheme of LLM training data. While there are millions of JavaScript and Python repositories to learn from, the corpus of Swift code — particularly modern SwiftUI — is substantially smaller.

This manifests in practical ways that slow us down daily. LLMs often suggest outdated patterns from the UIKit era when we’re working in SwiftUI. They hallucinate modifiers that don’t exist or combine them in ways that won’t compile. They’re particularly weak with Swift’s more advanced features, like result builders, property wrappers, and the newer concurrency model with async/await and actors. When working with cutting-edge APIs from the latest iOS releases, we frequently find ourselves correcting the model more than being assisted by it.

The challenges extend beyond code generation. iOS development has unique tooling, build systems, and deployment requirements that LLMs struggle to navigate. Xcode project configurations, build settings, provisioning profiles, and the intricacies of App Store submission are all areas where current AI assistants provide limited value.

A Changing Landscape

That said, we’re genuinely excited about the trajectory we’re seeing. Tools like Claude Code, GitHub Copilot, and cursor.ai are rapidly improving their understanding of Swift and SwiftUI patterns. We’re starting to see models that can handle more complex refactoring tasks, suggest appropriate architectural patterns for SwiftUI apps, and even help navigate the transition to Swift 6’s strict concurrency checking.

What’s particularly promising is the emergence of agentic coding assistants that can work more autonomously. Rather than just providing code snippets, these tools can understand broader project context, make cross-file changes, run tests, and iterate on their own output. For iOS development, this means an assistant that can update a view model, modify the corresponding SwiftUI view, adjust the navigation flow, and ensure everything still compiles — all from a natural language prompt describing what you’re trying to accomplish.

We’re also seeing interesting developments in multimodal LLMs that can understand design mockups and generate corresponding SwiftUI layouts. While the results aren’t production ready yet, the ability to go from a Figma design to a rough SwiftUI implementation in minutes rather than hours could fundamentally change how we approach prototyping and iteration.

Looking ahead to 2026, we’re optimistic that the combination of larger training datasets (as more developers adopt Swift and SwiftUI), more sophisticated models, and better integration with Apple’s development tools will narrow the gap between the AI-assisted experience in iOS development and other platforms. We’re particularly hopeful that Apple will embrace this trend and provide official APIs or tooling that help LLMs understand Xcode projects, access documentation more intelligently, and perhaps even integrate with the compiler to provide better error correction and suggestions.

The key is maintaining realistic expectations. LLM assistants are tools that augment our capabilities, not replacements for deep iOS development expertise. The developers who will thrive in 2026 are those who can effectively collaborate with these AI tools while bringing irreplaceable human judgment about architecture, user experience, and the subtle nuances that make iOS apps feel truly native and polished.

What are you most excited about in iOS development this year? We’d love to hear your perspective, continue the conversation, and build apps alongside your team. Reach out by contacting us here.

The annual list celebrates the nation’s top B2B organizations with a proven history of empowering entrepreneurs and driving business growth.

San Francisco, CA, November 5, 2025 – Inc., the essential media playbook for the entrepreneurs and leaders defining our future, unveiled its fourth annual Power Partner Awards recognizing B2B companies nationwide that have demonstrated an unwavering commitment to supporting startups and helping established businesses scale. MartianCraft is proud to be featured among the select group of firms recognized for excellence in software development, infrastructure, and technical innovation.

The Inc. Power Partner list is compiled based on rigorous feedback from the people who know these companies best: their clients. Every honoree received high marks for being a vital catalyst in helping leadership teams navigate the complexities of the modern business landscape. By managing critical functions—from sophisticated mobile architecture and cloud migration to digital transformation—these partners allow founders to stay laser-focused on their primary mission.

“This is our definitive guide to the vendors and suppliers who go above and beyond for small- and midsize customers,” said Inc. editor in chief Mike Hofman. “Our vetting process involves deep research into products, services, and reputation, underpinned by direct testimonials from founders who have seen the results firsthand. We are thrilled to highlight these genuine, mutually beneficial partnerships.” “Receiving this honor for another year is a profound reflection of our team’s consistency and passion,” said Kyle Richter, CEO and co-founder of MartianCraft. “At MartianCraft, we don’t just build apps; we build long-term trust. This award belongs to our developers and designers and the visionary partners who challenge us to push the boundaries of what’s possible in mobile technology every day.”

Having recently surpassed two decades of innovation, MartianCraft continues to bridge the gap between ambitious ideas and technical reality. While we are proud of our legacy—which includes developing the first multiplayer iPhone game and pioneering digital publishing—we remain focused on the future. In 2025, we continued to lead the way in creating high-impact mobile solutions that solve real-world problems for Fortune 100 giants and burgeoning startups alike. Our ability to integrate seamlessly with internal teams and deliver polished, scalable code remains the cornerstone of why businesses choose us as their long-term technical partner.

To view the complete list of 2025 award winners, go to: https://www.inc.com/victoria-salves/meet-the-2025-power-partners-in-technology-development/91240338 The November 2025 issue of Inc. magazine is available online now at https://www.inc.com/magazine and will be on newsstands beginning October 28, 2025.

About MartianCraft

MartianCraft is a premier mobile software design and development agency. We specialize in solving complex technical challenges, from refining enterprise-grade software to launching disruptive new ventures. Our expertise spans native iOS, Android, Mac, and robust backend development. With over 1,000 apps shipped for a diverse range of clients, we combine twenty years of experience with a forward-looking approach to mobile craftsmanship.

About Inc.

Inc. is the leading media brand for the risk-takers and innovators shaping the future of business. Through world-class journalism and prestigious recognitions like the Inc. 5000 and Power Partners, Inc. provides entrepreneurs with the tools and community they need to succeed. With a brand footprint of over 40 million, Inc. continues to be the most trusted resource for those driving the global economy. For more information, visit www.inc.com.

Launching an app is a lot like staring out at the horizon just before sunrise. You know something big is about to happen, there’s a surge of possibility in the air, and you can feel the weight of every decision leading up to that moment. I’ve had the privilege of standing on the cusp of many product launches in my career, and I’ve learned that successful launches don’t just happen. They’re deliberately built, piece by piece, with the same care and precision we dedicate to coding our very best features.

For the past two decades, I’ve dedicated my efforts at MartianCraft to crafting delightful app experiences and guiding those products through every stage of the development and launch cycle. Time and again, I’ve found that no matter how exceptional the product is under the hood, a successful launch hinges on laying the proper groundwork, understanding the market, and knowing how to speak to your audience in a language that resonates.

I want to explore some of the most important lessons I’ve learned about building and releasing a product in a way that not only draws attention on day one but also sets the stage for lasting success. From the earliest seed of an idea to the months that follow your initial release, the decisions you make around marketing, monetization, and user engagement often prove just as critical as the choices you make in your code.

It starts with having a sense of purpose. Whether you’re an individual developer hacking on weekends or a dedicated team pulling long hours, it’s worth taking the time to articulate—at a fundamental level—what problem your app solves or what experience it offers that users can’t find anywhere else. I’ve seen teams working on brilliantly engineered apps that nonetheless struggled mightily in the market, and when I asked them what set their product apart, they sometimes stumbled. If you can’t quickly express why your app matters, your potential customers will have a hard time seeing its value, too.

When I’m consulting with clients at MartianCraft, we often start by crafting a one-sentence product statement that captures the heart and soul of what we’re creating. This isn’t just some empty marketing exercise; it forces us to confront the idea’s feasibility, its audience, and its path forward. If there’s no crisp statement we can all agree on, that’s usually a sign that we need to revisit the concept before we commit any further resources to it. Establishing that sense of purpose early doesn’t just guide your team’s decision-making—it also shapes how you’ll approach your marketing later on, because it crystallizes the talking points you’ll lean on to attract your first users.

That’s the thing about marketing an app: People often associate “marketing” with splashy ad campaigns or big promotional stunts, but it’s more about aligning your product’s value with the people who need it. If you’re building a fitness app designed for busy professionals, for instance, your entire marketing narrative should address the unique hurdles that demographic faces—time constraints, limited resources for elaborate workouts, and an immediate need to track progress on the go. You can’t effectively speak to those points unless you’ve had conversations with potential users or tested your assumptions in some real-world capacity. Otherwise, you’re left guessing, and guesswork is a risky strategy when you have mere seconds to capture someone’s attention in the App Store.

This is where an early beta or soft launch can shine. Over the years, I’ve become a strong advocate for letting real people (beyond an internal QA or close friends) try the product as soon as it’s minimally functional. Those folks become your best source of raw, unvarnished insight. They’ll tell you if the onboarding flow is too confusing or if the main feature you’ve been pouring your energy into doesn’t resonate at all. Because they’re seeing the product without the developer bias we all naturally have, they reflect how the broader public might react when you eventually open the floodgates. I’m always amazed at how a handful of early users can highlight an issue that might have taken us weeks to uncover on our own. By nipping those snags in the bud, we pave the way for a smoother rollout later.

Even more importantly, those same early adopters can become your first brand ambassadors. They’ve had a sneak peek of something special. They feel invested in its success because they helped shape it with their feedback. When you finally go live, they’re the ones tweeting about it, telling their co-workers, or writing genuine App Store reviews that carry a lot of weight. I’m not suggesting that you should rely solely on this crowd to make or break your launch, but I’ve seen how a few dozen or a few hundred engaged beta testers can jump-start word of mouth in a big way.

Of course, word of mouth alone rarely drives an entire launch strategy—especially if you’re aiming for a strong presence in a crowded category. That’s where the underappreciated craft of App Store optimization, or ASO, enters the picture. ASO might not have the glamour of a polished marketing video or a newsworthy product announcement, but it remains one of the most powerful tools in an app developer’s arsenal. When an app is fully launched, a fair chunk of its traffic can come from organic searches in the App Store. If your product description, title, subtitle, and screenshots don’t speak to the keywords that align with your audience’s needs, you’ll miss out on that natural discovery channel.

I’ve lost track of how many times I’ve seen incredible apps hamper their own growth with a generic App Store listing. They might be using a single screenshot that doesn’t convey the core features or a description that’s too high-level to spark interest. When you work diligently to optimize your listing—using relevant keywords, high-quality visuals, and a concise, benefits-oriented description—you make it crystal clear to the browsing public why your product deserves their attention. That’s the sort of improvement that might result in a measurable bump in paid conversions and downloads, and it’s not something that requires elaborate coding. It’s simply taking the marketing and user-alignment work you’ve already done and expressing it effectively on your storefront.

Speaking of storefront presence, there’s a great deal of power in collecting early user reviews and ratings. We’re social creatures, and we like to hear from others about whether an experience is worthwhile. That’s why I encourage teams to think carefully about how and when they prompt users for reviews. If you do it too early or with too much frequency, you risk irritating new users and cutting short that honeymoon phase. But if you approach it at a moment when someone has just had a great experience or completed a milestone, it can feel like a natural extension of their positive engagement. If you give users the opportunity to express that enthusiasm publicly, that’s valuable currency—not just on launch day but over the lifespan of your product.

Of course, attracting users and generating excitement is only the first part of the equation. You also have to sustain people’s interest, monetize effectively, and keep your users coming back. Monetization strategies vary widely based on the nature of the product. Some work best with a straightforward one-time purchase price. Others thrive on a subscription model, offering ongoing value that justifies a recurring fee. A freemium approach can be especially appealing if you have a broad user base and want to entice them with a free experience before unlocking premium features.

I’ve often been asked how to decide on a monetization strategy, and I always return to the principle of alignment: The way you charge for an app should align with the kind of value your users see in it. If your app helps users on a continuous basis—like monitoring their health metrics, organizing their work tasks, or providing fresh content—it’s logical that you’d set up a subscription. On the other hand, if it’s a self-contained utility that solves a single problem once, a one-time purchase might make more sense. The key is to avoid letting the business model damage the user experience. A clunky paywall or invasive advertising can quickly alienate the people you worked so hard to win over.

Regardless of your pricing approach, you’ll need a plan to engage users and maintain that relationship beyond the initial install. This is where thoughtful push notifications and email campaigns can make a difference. I say “thoughtful” because it’s all too easy to overdo it. We’ve all installed apps that bombard us with notifications about every minor feature or milestone, and the result is often an instinct to disable notifications or uninstall the app entirely. I encourage developers to think about the user’s perspective: What kind of push notification would genuinely add value to someone’s life today? If your app organizes finances, maybe it’s a heads-up about an upcoming bill or an unusual transaction. If it’s a reading app, maybe you’re suggesting the next installment of a series they’ve been following. The moment a user sees that push as a useful nudge rather than an interruption, you know you’re building loyalty instead of resentment.

These same principles apply to post-launch growth. As a developer, you should be collecting data and insights on how people engage with your product. Are they dropping off at a certain step in the onboarding sequence? Do they love a feature you considered minor, while ignoring the main one you spent months polishing? This kind of feedback is a gift, because it tells you where to invest your energy. You might find that a small design tweak or a new feature extension can reignite interest and get users to explore areas of the app they missed before.

In my experience, the most successful products—be they small indie apps or large-scale corporate endeavors—are the ones where the team remains curious after launch. They run experiments, ask questions, and aren’t afraid to pivot if they uncover a path to greater user satisfaction. That curiosity also pays off when it comes to marketing. Instead of launching once and calling it a day, consider how you might create waves of excitement. You could introduce an interesting new feature, partner with an influencer or organization that shares your target audience, or craft an engaging promotional campaign for a seasonal event. Each of these angles can breathe new life into your product, capture fresh attention, and expand your user base.

As I often remind our clients at MartianCraft, the launch is an important milestone—one that absolutely deserves planning and celebration—but it’s not the end of the journey. If anything, it’s the beginning of a new phase where real customers begin to shape and grow your app in ways you might not have anticipated. When you’re ready for that reality—when you welcome user feedback, iterate quickly, and adapt your marketing strategies to support ongoing engagement—you create a product that can thrive long after those initial downloads.

All these lessons boil down to a simple truth: Launching a successful app is a holistic endeavor that spans product vision, audience alignment, user experience, technical polish, and ongoing refinement. Whenever I stand in front of a team preparing to release something they’ve poured their hearts into, I urge them not to overlook the intangible elements that make or break that glorious Day One. Don’t wait until the final week to think about how you’ll capture press interest or communicate your value to potential users. Don’t assume that people will simply discover your app because you pushed it to the App Store. Instead, take charge of your launch narrative, pair it with a meaningful user feedback cycle, and set up a framework for lasting relationships with your community.

Over the years, I’ve seen that there’s no shortcut or secret handshake that guarantees overnight success. But if you weave these principles into your process—true clarity of purpose, genuine engagement with your community, thoughtful marketing that conveys real value, and a post-launch plan to keep iterating—you stand the best chance of lighting that spark that moves your product from just another icon on the screen to a deeply valued part of your users’ digital lives. If you can achieve that, you’ll be far more likely to look back on your launch as the start of something truly remarkable.

My son traveled to Mexico recently with his mother. On the first day of the trip, his mother called to let me know that his iPhone was lost. They weren’t sure when it had gone missing, but thought maybe it had fallen out of his pocket.

Immediately, I checked the Find My app to track the phone’s location. It was in an open-air market they had visited. Over the course of a few hours, the phone moved inside one of the shops, onto the road, then to what looked like a warehouse in a completely different part of Mexico. Then it went dark.

His phone didn’t fall out. Someone picked it out of his pocket. And, believe it or not, this was the second time his phone was lost or stolen on a trip — both times in countries where neither my son nor his mother speak the local language.

The first time, his phone was genuinely lost and was most likely destroyed from a fall. It was stressful not being able to get a hold of him, but I didn’t worry about the safety of his personal information. This time, I had to wonder whether his phone had been locked — and if not, what the thieves had access to. I suspected that his phone had been stolen by an organization, based on how quickly it was transported across the country. I had serious concerns that the people who took it might have the means to break into the device and access any personal information in the phone.

It’s a fear we all have while traveling: What if my phone gets stolen? Most people would consider it second only to losing a wallet. Our phones contain bank information, our credit cards and debit cards, concert tickets, personal information, sensitive photos and videos, and lots more.

What Is at Risk? What Should I Worry About?

In addition to financial information, photos, and other private details, there are a few risks that we don’t always think about when we consider the possibility of a lost device.

Location Information

If your device isn’t secured or was unlocked when it was lost, the Find My app could be a map directly to your other devices and family members. This would be considered an immediate and dangerous risk that should be one of the first things you work to counter. We will cover this later.

PII

PII — personally identifiable information — means any information that could be used to piece together your identity. By itself, your name isn’t all that dangerous, but when combined with your state, a photo of your family with a geotag, your mother’s full name in your contacts, and so on, a picture starts to form. People who work in the field of selling data can piece that puzzle together and provide interested parties that information. Most of us don’t really think about how much important, personal information we leave in our devices. When was the last time you cleaned out your Notes app? Do you save emails locally?

Emotional Considerations

Anyone who has been the victim of a theft can tell you that it can make you feel vulnerable and unsafe. It is a feeling that your personal space was violated, and even things in your pocket aren’t safe.

So what can we do? How can we protect ourselves, and what do we do if our device is lost or stolen?

Know Your Device

One thing that always surprises me is how little iPhone users know about their device. Most people aren’t aware of the multitude of valuable safety features it includes. The first, and easiest, way to protect your phone and the private contents within is to familiarize yourself with those safety features and take advantage of them.

Find My

We already mentioned the scary part of this feature, but it’s also a valuable safety tool. First, it can be used to track down your missing device, as I did when my son’s device went missing. In my case, I sent the location to the local police, but I assumed I would never see that device again. This is where the other tools come into play.

If your device is lost but you think you have a chance of recovering it, you can mark the device as lost.¹ This changes the phone’s settings to display a message that the phone has been marked as missing and lets anyone who finds it call the emergency contact information you provide. If you left your phone behind at a restaurant, for example, this can be a great way to get it returned to you. Also, as I mentioned earlier, there is a risk of Find My being used on a stolen phone to track your other devices. Marking the device as lost or stolen disables the tracking features and prevents this type of abuse, so it’s important to mark any missing device as lost as soon as possible.

If, however, you believe your phone was stolen, there is another option: erasing the device.² This lets you mark the device for erasure. The next time it’s powered on in a service area, the erasure will trigger and clear all the contents. The device will also keep an activation lock, so it can’t be used by another person without specialized software.

Passcode

This will be a brief and simple point: Make your passcode difficult to guess. You don’t need a 15-digit code, but make it something that the average person won’t think to try. I am shocked by how many friends and family set their phone passcodes to things like 0000, 1111, 1234, etc. iPhones let you try 9 passcodes before a temporary timeout, and 10 attempts before locking the device entirely. You better believe that a thief is going to try simple codes like those immediately. If one of them works, that person now has access to your whole device. They can bypass biometrics by choosing Use Passcode for most apps, including Wallet.

This is pretty much the worst case scenario for a lost phone. So don’t do this. Choose a real passcode that contains different numbers … and don’t use your birthdate. That’s one of the most common passcodes, and if a thief also scores anything along with your phone that has your birthday, they’ve got the keys to the kingdom. The best passcodes are things that are easy for you to remember but would be hard to link to you.

Back Up Your Device

Before you leave for a trip, and at night if you have the time and strong WiFi, create a backup of your device. Most of our devices do this automatically, so long as you have storage available, but doing it manually means you know precisely when the last backup was and that your data and information are retrievable. This is a step many people forget, and it’s an unpleasant surprise to restore from a backup and realize you’re missing the last couple weeks of photos and messages.³

Medical ID

Of the features I’ve mentioned here, I think this is the one the fewest people know about or use. I highly recommend changing that: Set up your medical ID in the Health app. You can add as much or as little information as you want. This feature’s intended purpose is to provide someone assisting you in an emergency with important medical information, but even if you have no medical conditions that you want to add, you can still add your name and an emergency contact number (preferably someone who is traveling with you). If someone finds your lost phone, they might check the medical ID and will have a way to contact you.

Personal Behavior and Practices

A skillset I learned from the Army is being a “hard target.” This is general advice I recommend everyone start using. The idea is to make yourself look like someone who is aware of their surroundings, unconcerned, and in control. Thieves and other criminals look for “easy marks”: people who are unaware, distracted, nervous, etc.

Being a hard target is simpler than people think and can be accomplished with just a few steps.

• Be aware of your surroundings. Every now and then, check your left and right to see whether there are people too close to you. Give yourself a bit more space if needed.

• Occasionally, check behind yourself. (Only occasionally, and always casually. Looking behind yourself or over your shoulder regularly will make you look nervous.)

• Keep your eyes up. When you’re walking around outside, especially in an unfamiliar area, it’s neither the time nor the place to be looking at your phone or device. It’s OK to check it on occasion, such as for directions, but your eyes should be up and looking around most of the time.

• Keep your personal belongings (wallet, phone, keys) in a place that is difficult to access. A general rule is that you trade accessibility for security. The harder something is to get, the safer it is — and vice versa. Choose travel clothes with hidden pockets or zippered internal pockets that make pickpocketing significantly less likely.

• Learn to walk through crowds without bumping into other people. This is by far the hardest part, and in some cases it might not be entirely possible. Pickpockets generally use a momentary impact, like bumping into you, to perform the pick. Being aware of the people around you and making sure none of them touch you can significantly reduce the chance you get pickpocketed.⁴

Welp, My Phone Is Gone. What Now?

If you find yourself in the unenviable position of having lost your iPhone, there are some things you should do immediately and some steps you should take in the long term to limit the possible damage from a lost device.

What to Do Right Now

If you have another device, the first thing you should do is go straight into Find My and locate the missing device. It’s entirely possible that you left it at a restaurant or on the counter of the shop you just left.

If you don’t recognize the location or it’s not immediately nearby, activate Lost Mode. This is the most important step to do as soon as possible. It locks the device down, limits access, and keeps other people from digging around in the device, even if you left it unlocked or have no passcode (seriously, after all the reasons I just gave?).

Second, if you have any reason to believe any of your accounts might have been exposed (maybe you had your bank app open the last time you saw the device), preemptively change your password for those accounts. Remembering a new password is a small sacrifice to avoid potentially catastrophic issues.

Third, if you suspect the device was stolen, contact the local authorities. Then contact Apple Care, if you have a plan⁵, and your carrier to inform them of the loss. These can save you heartache later if the thief attempts to use your device for anything, especially if it was unlocked. You don’t want to be held responsible for your device being used for crime or for international calls that aren’t covered in your plan.

Finally, make sure you still have some means to get in touch with other people. A temporary local flip phone is better than radio silence.

What to Do Later

If you haven’t been contacted for the rest of the day, even with the device in Lost Mode and/or with your Medical ID enabled, it’s best to treat the device as gone for good. You can keep checking Find My, as your phone might get dropped off at the local police station or cell carrier shop by an honest citizen — but if it’s in an area you don’t recognize, do not go there. A cell phone is not worth risking your personal safety to retrieve.

If the device is well and truly lost, mark it for erasure using the Find My app, then work with Apple Care or your carrier for a replacement device. You can restore the new device using the backup you remembered to create before your trip.

Finally, take some time to review whether there were any times you made yourself vulnerable to a pickpocket or other thief and think of ways you could reduce that sort of risk and exposure in future trips.

In the end, with only a small amount of effort, you can make it so that losing a phone (while frustrating) is an inconvenience rather than a potentially devastating release of sensitive personal data. Security and safety is a personal job for each of us. Protecting ourselves and our loved ones can sometimes be as easy as 20 minutes of prep work before you take a trip.

When a startup founder or small business leader sets out to build the next great app, one of the first crossroads is choosing a development partner. Do you go with the big-name agency with a sprawling team and shiny portfolio, or a boutique firm known for its specialized expertise? The decision isn’t just about hourly rates or project quotes — it’s about what those dollars actually buy you. As one founder quipped after hiring a large agency, “after taking an entire month, a conference room of 20 people were proud to say they finally decided on a font!”¹ His frustration underscores a broader question: Big agencies vs. boutique firms: What are you really paying for in app development?

In this post, we’ll unpack the true costs (and benefits) that often hide behind the proposals. Consider this a candid exploration, drawn from firsthand experience, of how large agencies and smaller boutique firms differ in value, process, and partnership.

The Price of Overhead and Scale

Big agencies certainly look impressive on paper — dozens of specialists, slick offices, and a roster of Fortune 500 clients. But supporting that engine comes at a price. Large agencies carry significant overhead: pricey real estate, layers of management, sales teams, and even those elaborate espresso machines. Those costs trickle down to clients. As one small agency owner put it, “the higher the expense sum, the more for the clients to subsidize.”¹

Overhead alone doesn’t make big agencies “bad” — scale can bring benefits — but it does mean you might be paying for more than just development work. If your project will only use a fraction of a large agency’s massive team, make sure you’re not covering more than your fair share of their overhead.¹ Boutique firms, by contrast, run lean by necessity. With smaller teams and fewer bureaucratic costs, they can often operate on lower margins. A boutique agency doesn’t maintain a bench of idle staff or a huge downtown office to impress investors, and that can translate to more competitive pricing for the client. In fact, one survey found 72% of businesses reported better satisfaction when working with smaller firms.²

There’s also the matter of efficiency. Larger organizations sometimes suffer from the “too many cooks” problem — more internal meetings, more approval layers, and a slower pace. All of that can burn time (and budget). Research on IT projects has shown that large projects run 45% over budget on average while delivering 56% less value than predicted.³ The reasons vary, but bureaucracy and scope creep are chief among them. A boutique firm, with a tighter crew, is often nimbler by default — fewer handoffs and meetings mean more time spent writing code and designing features.

Access to Senior Talent vs. Layers of Management

Another hidden cost in working with a big agency is who actually does the work. When you hire a large agency, you’re typically introduced to a polished account manager. But that friendly liaison isn’t writing your code. In many big agencies, especially if you’re not a top-tier client, your project may be delegated to junior developers or outsourced teams, with senior architects only glancing at it periodically. You might communicate mostly with project managers who act as go-betweens. As one analysis noted, at big agencies “you will be assigned a series of contacts who will be your proxy to the talent behind your project.”¹

Boutique firms tend to cut out those layers. When you hire a smaller agency, you often talk directly to the lead developers, designers, or even the founders. The very people writing your code and crafting your UX are in the meetings hearing your vision firsthand. This direct line has huge advantages: less telephone-game confusion and a stronger shared understanding of the product. In fact, smaller agencies excel at providing direct access to senior talent.²

This difference shows up in results. One industry survey found 81% of brands working with boutique agencies report better outcomes due to direct involvement of senior talent.⁴ When a founder chooses a boutique partner like MartianCraft, they’re paying for the accumulated expertise of senior engineers who have launched hundreds or even thousands of apps.

Flexibility, Agility, and Client Focus

Building a great app often requires navigating change — new user feedback, shifting market demands, or unplanned technical hurdles. This is where the flexibility of your development partner becomes crucial. Large agencies have established processes and big teams, which can make them less agile in responding to change. They might insist on formal change orders for even minor tweaks, or require lengthy internal approvals to adjust course. Onboarding with a large firm can itself be a slow process — negotiating a complex contract, then waiting while they assign personnel and schedule kickoff meetings.

Boutique firms generally offer a stark contrast here. With a smaller team and a flat hierarchy, a boutique agency can often start quickly and pivot readily. Need to change a feature after a week of user testing? You’ll likely be talking directly to the lead developer, who can say “no problem, let’s adjust” without three meetings and approvals. According to a recent HubSpot‑cited study, 84 % of brands chose smaller agencies for greater flexibility, underscoring faster turnaround and adaptive campaign adjustments as key advantages over larger firms .⁵

Client focus is a related advantage. A boutique firm doesn’t answer to shareholders or distant corporate directors; we answer to our clients. We’re not chasing an acquisition or the next round of investor funding — our success rides on the success of your project. That fundamentally changes the attitude toward flexibility.

Transparency in Pricing and Process

Have you ever looked at an agency invoice or proposal and scratched your head at where the numbers come from? With large agencies, that’s not uncommon. The pricing models can be complex: blended rates, multiple resources allocated (some of whom you never meet), and retainers that lock you in. Many founders have lamented opaque pricing from big vendors, from padded hours to surprise fees.⁶

Boutique firms build their reputation on transparency. They have to — one bad word-of-mouth review can hurt a small company far more than a giant one. At MartianCraft, we strive for clarity: straightforward proposals, clear outlines of what’s included, and open communication throughout. We’ve even written about the importance of avoiding unexpected costs — a philosophy that guides how we scope projects.

One advantage here is how changes are handled. Almost every app project will evolve after kickoff. Large agencies often treat these as change orders, invoking formal re-scoping (and often extra charges). Boutique firms tend to be more flexible in scope management.

A Partner Relationship vs. Being “Just a Client”

Perhaps the most significant difference — and the hardest to quantify — is the quality of the relationship. For a big agency, your company might be one of dozens (or hundreds) of active clients. Your project’s importance to them is proportional to the size of your contract.

In contrast, a boutique firm lives and dies by the success of each client engagement. We can’t afford to treat any project as disposable or lower priority — and, frankly, we wouldn’t want to. Clients aren’t just accounts for us; they’re partners. A boutique team is likely to celebrate your app’s wins as their own, because they are.

There’s also a human element: personal connection. When you work with a boutique firm, you get to know the people — their names, their faces, their quirks — and they get to know you. Communication tends to be more frequent and frank. This fosters trust. It’s telling that 74% of brands that work with boutique agencies report higher satisfaction, versus 58% with larger agencies.⁵

The Bottom Line: Choosing the Right App Development Partner

When weighing a big agency vs. a boutique firm as your app development partner, it’s crucial to look past the surface. The big agency might promise a broad array of services and a reassuringly large team, while the boutique firm promises a focused, senior-led effort. The real question to ask is: What am I paying for, and is it what my project truly needs?

If your app initiative is mission-critical, depth beats breadth. You want the A-team focused on your product, you want to know where each dollar is going, and you want the flexibility to course-correct without hassle.

As a 2024 Inc. Power Partner award winner, MartianCraft has been recognized for delivering exactly that: a proven track record of supporting clients and helping them grow. We take pride in operating without fluff or bureaucracy, so our clients get maximum value.

In the end, “what you’re really paying for” comes down to trust and value. And in the world of app development, outcomes matter more than promises.

Every developer has to start at the beginning. We all go through stages of growth, and inevitably we make mistakes. It’s all part of the process, and it can be a valuable, if sometimes painful, way to learn.This is why we have senior developers and the code lifecycle, to make sure our mistakes don’t make it into the final version of our code.

This article won’t be a deep dive into code. I won’t be giving specific examples of proper APIs and syntax or telling you which architecture is better than the others. This article is far more personal. These are lessons I have learned by making mistakes (sometimes big ones) and applying my retrospective to see how that happened and how to avoid doing it again. Some of these are lessons I learned developing for iOS, but some are things I learned from my time in the military that carry over well.

You’ll have to make your own mistakes, of course, but I hope this article can help even one developer learn from my mistakes.

Attention to Detail

This is a mantra that was absolutely drilled into me (literally—by drill sergeants) in the army. “Attention to Detail, Motivation is Key.” It seems fairly self-explanatory, but the application eludes most people and varies depending on the context. In the army, attention to detail might be checking a coordinate for a third time, making sure your map is oriented correctly, ensuring you know where all of your equipment is, etc.

In coding, it’s a bit different. Let’s say you’re working on a bug in an application. You’ve found the cause and even identified the individual line causing the issue. Good work, but slow your roll for a moment. Before you go, “OK, I see the problem, and the fix is obvious!”, why don’t we take a look at the call site? Why is it executed? What does it do? More importantly, what is it supposed to do? What about the file or view it’s nested inside; what does it do? Is it doing what it’s supposed to? What will your “fix” do to all of this?

This is a lesson I’ve “learned” repeatedly. You get a bug report, it’s 4:30 PM on a Friday, and all you want to do is fix the bug and wash your hands of it. But be careful down that road; down there, there be dragons. There’s nothing more embarrassing as an iOS engineer than tagging your boss and saying “fixed the issue for you,” then getting messages two hours later that you broke a key feature or maybe even the whole app with your “fix.” That extra 20 minutes to truly understand the change you’re making can save you embarrassment and potentially hours of time hotfixing your mistake.

Slow is Smooth; Smooth is Fast

Once again, this is a military mantra. It’s something heavily ingrained in anyone who has spent significant time training in difficult or complex tasks. But I’ve found that this mantra applies to every aspect of my life, from the army to childcare to Brazilian Jiu-Jitsu and even to coding.

The concept is simple enough: Take your time and do each task as slowly as is needed to do it correctly. If you’re making mistakes, typos, logic errors, or overlooking potential issues, you’re going too fast. This generally applies best to learning new skills, but it can also be applied when you’re retraining yourself out of bad habits. By taking your time and focusing on the right way to perform a task, you’ll train your muscle memory on the correct way to do things.

At first, when something is new to you, you have to think about the individual pieces of the task. What is the correct syntax? What about placement, best practices, thread safety, etc.? Over time, the more you repeat a common task slowly and correctly, the faster you’ll be able to execute it with the same skill level. Those details that you used to have to think about are now intuitive. Eventually, even complex tasks can seem like you’re doing them in a rush, but you’re actually just well trained.

“Take your time” might seem counterintuitive in iOS engineering, since deadlines are a very real thing. But I don’t mean “work slowly on purpose,” and I definitely don’t mean “slack off and watch TV or take a nap.” In this context, “take your time” means don’t rush your work. Take the time to understand the context you’re working in, and when it’s time to write your code take a moment to think about the best way to do it. Sometimes a five-minute pause to consider the whole workflow can help you decide “Oh, this approach is much better than my first idea.” Or sometimes you write half of your solution, then realize “I really should have done it this way instead.” Go back and do it that way. Don’t pawn it off as technical debt and move forward. If it’s an extra 20 minutes or even an hour to do something right, rather than a patch job, it’s absolutely worth it.

But Don’t Get Trapped in the Planning Loop

I suspect (or maybe just hope) every engineer has fallen into this trap. It looks something like this:

1. Receive a new large feature request.
2. Identify where this feature would need to go in the code.
3. Read through the existing code to familiarize yourself.
4. Think about how best to make the new feature.
5. Think of some issue with your first idea.
6. Repeat steps 3 - 5.
7. Repeat steps 3 - 6.

Before you know it, you’re at the end of a work day and you haven’t actually written any code, and you don’t feel any closer to a decision. Not ideal, but we don’t want to rush things right? Sure, but you do have to start writing at some point.

After doing this too many times, I’ve started breaking the cycle after step 4. Even if I immediately start seeing potential flaws in my plan, that’s OK. Maybe in the process of writing the code, I’ll stumble on the solution. I certainly won’t fix code I never wrote in the first place. So here’s what my revised steps tend to look like:

1. Receive a new large feature request.
2. Identify where this feature would need to go in the actual code.
3. Read through the code that already exists to familiarize myself.
4. Think about how best to make the new feature.
5. Start writing.
6. Keep writing until the feature works.
7. Test the feature.
8. Clean up the code.
9. Push up my initial version to my branch. (It’s finished and working, so I keep a record of it.)
10. Go back through the code and consider whether there are better approaches:
    1. Maybe a class would work better here than a struct?
    2. I don’t like how the data flow is managed here.
    3. Maybe I could use an Environment variable here instead of passing the data down through three layers of views.
    4. Etc.
11. Make changes that will improve the code.
12. Repeat steps 7 - 11 as needed.

In some ways, code can be very similar to art. My brother is an artist, and he is absolutely never happy with a piece. He will modify and tweak it until it barely resembles the original version. Engineers fight the same battle. We finish a feature and immediately think of things we could have done better, ways we could improve efficiency or cleanliness. The best we can do is to go through a few iterations within the reasonable timeframe we gave our client and have a working, tested, and verified solution when deadlines approach.

We will always have some level of technical debt. We are constantly improving (hopefully), and our understanding evolves with time. That’s OK, but we can’t get lost in the rabbit hole trying to invent the perfect solution or the perfect feature. That leads not only to failure but also to missed deadlines, because perfection is intimidating and you will second-guess everything you write. Instead, aim for functional, clean, reusable code that accomplishes the task you set out to do, and if it’s really important you can revisit it later. An opportunity will almost always present itself when some new feature gets added in that same code. Now’s your chance to make those fixes! But don’t get lost in the loop.

“Fight for the Users” (Be Customer-Experience Driven)

This is one that I still struggle with, and it’s a newer concept for me if I’m being completely honest. Obviously, we all know that we’re making our apps for users. But that’s not the same as approaching your architecture and feature implementation with that in mind.

So how do we apply this to our code? I’m not a designer. (I can’t even see colors, for crying out loud.) But it’s simpler than you might think. Run your code, but don’t just confirm that it works. When you make a feature or fix a bug, check that it works, yes—and then play with it. Try to think about it as a user, not an engineer, especially for new features. How does it feel? Would you be able to find it if you hadn’t written the code? Does the experience make sense? Would a less tech-savvy user be able to figure it out? And, most important of all, is this something people will actually use? Has any user expressed an interest in this?

We often get ideas from the top asking for features, and our first response should be “who asked for that?” or “who is going to use this?” If the answer to these questions ever appears to be “no one,” reach out to the people who requested the feature. Give them your feedback in a constructive way, and try to work directly with the design team and business analysts to come up with experiences that actually make sense. All of us—coders, designers, and business analysts—can get lost in the “idea-driven” trap where we come up with new, awesome ideas and want them thrown into our apps. But if users don’t want it and won’t use it, it’s just wasted code and unneeded clutter in the app. Keep your apps user-driven.

It’s important to differentiate this from pushing back on things you don’t want to do for whatever reason. But for any feature we’re making, we should always know its intended purpose and its target audience. This knowledge will inform your decisions on how to build it, and that can make a massive difference. As Captain Francis Hooke once said, “A word to the wise is enough. The old proverb is, forewarned, forearmed.”

It’s also important to understand that this isn’t a replacement for testing. Unit tests and QA are more thorough processes, with their own place in the lifecycle of code development. Speaking of which…

Live the Code Lifecycle

We’re all familiar with the code lifecycle:

1. Plan
2. Design
3. Implement/Develop
4. Test
5. Deploy
6. Maintain

Straightforward enough, right? But the simple presentation of these six steps can lead to some common mistakes based on a couple easy misunderstandings.

For one thing, you always see this cycle presented as though development moves in only one direction: from planning to designing to implementing, and so on. But when something goes wrong, you often need to bump back to the step before the one you’re in.

For example, you can be on the Develop step, only to realize you’re missing designs for some of the views. Bump it back, reach out to your design team and let them know. Or you could be in the Test stage and discover your feature doesn’t work or introduces a new regression. Looks like you broke something that already worked. Back to the Develop stage. Don’t be afraid to move backward in the cycle if that’s what your project needs.

The other misunderstanding I’ve come across is the belief that all testing happens in the Test step. Makes sense, right? Wrong. If you have a QA team, it’s not their job to confirm that your code actually works. It’s not your code reviewer’s job, either. That’s your job. Testing by the developer is actually part of the Develop stage. I have been guilty of forgetting this many times, and it has never failed to punish me.

Before you submit a pull request for review, run your code on your simulator. Test your feature, and then (this is key) test all the features that had already existed before you added yours. You don’t have to do a full QA test cycle, but play with the app and make sure that things that worked before still work. Then do it on your real device. I know it seems like overkill, but there have been many times where code that worked perfectly on the sim crashed the app on a real device.

Once you’ve done that testing yourself, put your code up for code review, the final stage of the Develop step. Code review is essential and should never be skipped or rubber-stamped. Write a real description: Put what you changed and why you changed it, make a relevant checklist to show you tested those things, and include a screenshot or a video if appropriate. This is maybe 10 minutes of extra work, but it will help your reviewers do their job. More importantly, when you submit your review request you can walk away confident that you did everything you could to ensure success. You’ve done your due diligence, and you’re much less likely to get a message at 8pm saying your changes broke production.

IPC Skills are Necessary

Another key skill set I developed outside of software engineering is interpersonal communication (IPC) skills. Many people don’t understand just how much goes into good communication. In my time as a police officer, I took (and later taught) entire 8-hour courses on communication skills. Despite that, there are some lessons I, with dozens of hours of training and real-world experience, have learned the hard way as an iOS engineer.

Those of us who have chosen a career where most of our communication is with a computer, terminal, IDE, or maybe even AI are not, traditionally, a social bunch. That doesn’t change reality, sadly. You need to be able to communicate effectively with design teams, business analysts, managers, supervisors, and maybe even executives or clients. So here are a few tips.

First, a piece of advice that I was given by my squad leader while serving in Iraq: “Every time you have something you want to say, stop for just three seconds and think about it. If you still want to say it after three seconds, go for it.” At first, this seems silly, but I find that often, after those three seconds, I say nothing at all. Just as often, I completely rephrase my intended message. It might seem disconnected, but this is a practice I use in my daily work even now. It can be something as simple as looking at a message or email a few seconds before you hit send and re-reading it. It’s often the case that what we think does not always translate well into what we say or write. Re-reading your messages and emails can keep you from inadvertently coming off with the wrong tone or communicating incorrect information—and in some cases, you might realize the answer to the question you were about to ask.

Second, understand that good communication is less about being a raconteur and more about being able to put ideas into a simple, easy to understand form. With that in mind, as iOS engineers, keep the technical out of it as much as possible when you’re working with your non-technical clients and colleagues. Non-coders don’t want to hear a technical manual. If you’re good at analogies, try to relate the idea you want to get across to generic knowledge your colleague will be familiar with. If analogies aren’t your thing, that’s OK—try using simple, short phrases. Instead of telling your business analyst about race conditions or recursive issues, let them know “There’s a problem using this new feature. It’s conflicting with existing features and causing unexpected problems.” Then, and here’s the important part, let them know what this issue means to them. “This has delayed development a bit, so it will take an extra week to make sure the new code is functional, safe, and free of regressions.”

Finally, plan ahead. It’s pretty rare for developers to suddenly and unexpectedly need to discuss our work with someone not in our dev team. Most often, we get advance notice of a meeting or a call. So use that time. Make yourself notes. There’s an app for that. Write a couple key points down, then read through them and consider, “Would a non-engineer understand this?” If the answer to that is “no,” reword it.

And by the way, if IPC skills are something you struggle with, there are courses you can take to improve them. It’s worth it. Good communication is essential for success in all aspects of life.

When All Else Fails, Start at the Beginning

Alright, we’ve learned our lessons, and we’re ready to get out there, forearmed with knowledge. But sometimes, despite all your skills, you run into an issue you just can’t suss out.

You’ve used every debugging trick you know, and you’re still stumped. What do you do? Ask your senior? Sure, you can and should do that if you’re stuck. But they can’t always immediately swap over to your issue. What can you do in the meantime? Catch up on YouTube? Probably not the best choice.

The answer is to re-evaluate your assumptions and start at the beginning. This was a lesson I learned fairly recently. Sometimes, when you’ve checked data flow, race conditions, and logic errors, and you’ve debugPrinted everything you can think of and tried every other trick in your toolbox, you’re still stumped. This is when it helps to go back to step 1: “What’s the most fundamental piece of this code?”

Let’s say your view isn’t updating in real time. Well, then step 1 is that the data you’re looking at is observed in some way. If you want changes to reflect in real time, the view needs to know it changed. Swift has a bunch of tools to implement this, from Combine to ObservableObject to the new Observable macro and its family of tools. So which one are you using? OK, let’s confirm that the observer is actually working. Put in some checks to see if changes are actually sending the onChange callbacks…

You get the idea: If you’ve eliminated everything else, start looking at things you just assumed are working. Apple bugs happen. Logic that had been working before could actually be faulty, bad logic just waiting for the right use case to trigger its flaws. Don’t take anything for granted. No code is perfect, no tool beyond reproach. And no developer, either—maybe you assumed your senior developer’s code works correctly and didn’t check it for the source of your bug. Check it. Everyone can make mistakes, no matter how senior.

I’m not done making mistakes. Every one of us learns something new every day. It’s a constant journey of self-improvement and better understanding. But I hope that these insights I have gleaned from my past mistakes can help others avoid a hard lesson or two.