On March 21, 2026, I completed the Apple Search Ads Certification, deepening my understanding of how to effectively promote apps on the iOS App Store. Here are the most important rules and strategies I learned for advertising applications and maximizing visibility, downloads, and ROI:
In Apple Search Ads, the match type you choose for a keyword determines how closely a user’s search must match your keyword for your ad to appear. Exact match gives you the most control and typically warrants a higher bid, since you know the term is highly relevant. Broad match and Search Match cast a wider net, so you may want to start with lower bids and adjust as you see which terms perform best. As a rule of thumb: bid more aggressively on exact match keywords you know convert, and use more conservative bids for broad or discovery-focused campaigns until you identify new high-performers.
In Apple Search Ads, “keyword mining” (sometimes called “harvesting”) is the process of using Discovery campaigns and Search Match to uncover new, high-performing search terms you might not have thought of. When these new keywords start driving installs or conversions, you move them into your Exact Match campaigns and add them as negatives in Discovery. This keeps your data clean and ensures you’re always expanding your reach with fresh, relevant keywords. It’s a continuous cycle: discover, test, promote, and repeat.
The first step in structuring search results campaigns is to divide your keywords into four separate campaigns, each focused on a different keyword theme. This structure helps you measure results, monitor performance, optimize campaigns, and scale for long-term growth. The four recommended campaign types are:
Note: If you already have existing search campaigns, avoid importing them directly into Apple Ads. Apple recommends building campaigns from scratch for best results, as importing can lead to poor performance.
Pro Tip: For the cleanest data and most efficient budget, add your best-performing keywords (Brand, Category, Competitor) as negative exact match keywords in your Discovery campaign. This prevents your discovery ads from showing for terms you already know work, so Apple’s AI is forced to find new, long-tail search terms. It also keeps your reports tidy—your main campaigns show performance for proven keywords, while Discovery only surfaces new opportunities. When a new term starts performing, move it to your main campaign and add it as a negative in Discovery. This is a standard best practice among experienced Apple Search Ads managers, and it’s made a big difference in my own projects. (Example: For SlotParking, I’d add “Detroit parking” and “parking app” as negatives in Discovery, so the AI finds new phrases like “overnight parking near Ford Field.”)
What is Max CPT? Max CPT (Maximum Cost-Per-Tap) is the highest amount you’re willing to pay for a single tap on your app’s ad in the App Store. It acts as your bidding ceiling—you’ll never pay more than this amount for a tap.
Apple Search Ads uses a second-price auction system. This means you don’t always pay your full Max CPT. For example, if you set your Max CPT at $1.00 and the next highest bid is $0.60, you’ll only pay just enough to outbid them—typically a little above $0.60. But if your Max CPT is set too low compared to competitors, your ad may not be shown at all. Setting a competitive Max CPT helps ensure your ad gets visibility without overspending.
When launching a campaign, you’ll choose a daily budget—the average amount you want to spend per day. While your actual daily spend may vary (sometimes going a bit over or under), Apple ensures that your total spend for the month won’t exceed your daily budget multiplied by the average number of days in a month (about 30.4). If you set a specific end date for your campaign, your total spend will be capped at your daily budget times the number of days the campaign runs. Your campaign will keep running and spending each month based on your daily budget unless you pause, remove, or set an end date for it. This gives you predictable control over your ad costs while allowing for some daily flexibility.
How to Set Your Max CPT: Work backwards from your target cost-per-install (CPI). For example, if you want to keep your cost per install at $2.00 and your data shows that 1 out of every 4 ad taps leads to an install (a 25% conversion rate), divide your CPI goal by your conversion rate. In this case, $2.00 ÷ 4 = $0.50. That means you should set your Max Cost-Per-Tap (CPT) at $0.50 or less to stay on budget. This approach helps you bid confidently and ensures your ad spend aligns with your business goals.
Takeaway: Completing the Apple Ads Certificate gave me a strategic framework for running compliant, effective, and data-driven ad campaigns on the iOS App Store. By following Apple’s rules and applying these strategies, developers can boost app visibility, attract quality users, and maximize return on ad spend.
When I set out to build a robust backend for my portfolio projects, I wanted speed, clarity, and reliability. FastAPI checked all the boxes: it’s async-first, type-safe, and developer-friendly. Here’s how I shipped a production-ready API using FastAPI, Pydantic, httpx, Uvicorn, Thunder Client, and Render.
Sample Endpoint:
from fastapi import FastAPI
from pydantic import BaseModel
import httpx
app = FastAPI()
class Weather(BaseModel):
city: str
temperature: float
@app.get("/weather/{city}", response_model=Weather)
async def get_weather(city: str):
async with httpx.AsyncClient() as client:
resp = await client.get(f"https://api.weatherapi.com/v1/current.json?key=YOUR_KEY&q={city}")
data = resp.json()
return Weather(city=city, temperature=data["current"]["temp_c"])
Takeaways: Combining FastAPI, Pydantic, httpx, Uvicorn, Thunder Client, and Render makes backend development fast, reliable, and fun. I can ship new endpoints in minutes, test them instantly, and deploy updates with zero downtime.
Read the CoastCast Case Study
Sometimes, the best opportunities come from a bit of luck and a lot of initiative. On a recent visit to the Water Board Building with my Challenge 5 team, we had no idea that our trip would coincide with the monthly board meeting. We simply wanted to learn more about the organization and explore ways our skills could make a real difference in the community.
As we entered, we found ourselves in the midst of the board meeting. Rather than quietly observing, our project manager seized the moment and stood up to address the board directly. With genuine curiosity and a spirit of service, she asked if there were any pain points the board faces daily that technology—and our team—could help solve.
The board responded candidly, sharing a real challenge they encounter. This unexpected conversation may have set the stage for our Challenge 5 project and, potentially, secured a client whose needs align perfectly with our mission to create meaningful, real-world impact.
We are now waiting to meet with the board again, eager to learn more and begin working on a solution. This experience is a testament to the power of showing up, asking questions, and being ready to serve. Our journey to the Water Board Building was more than a search for a project—it was a step toward making a lasting difference in our community.
What is Challenge Based Learning (CBL)?
Challenge Based Learning is an educational approach where learners tackle real-world challenges through hands-on projects, teamwork, and iterative problem solving. Instead of memorizing facts, students identify a meaningful challenge, research solutions, build prototypes, and reflect on their process. CBL encourages creativity, collaboration, and practical application of knowledge.
History:
CBL was developed by Apple in 2008 as part of their education initiatives. It was designed to make learning more engaging and relevant by connecting classroom activities to real-world issues. The method has since been adopted by schools, universities, and organizations worldwide—including the Apple Developer Academy, where I experienced CBL firsthand.
How It Works:
1. Engage Phase: Start with a big question or real-world problem. This phase includes developing an Essential Question (a broad, meaningful inquiry), a Challenge Statement (the actionable challenge to solve), and Guiding Questions (specific questions that help break down the challenge and focus investigation).
2. Investigate Phase: Research, brainstorm, and explore possible solutions. Here, learners answer guiding questions, gather evidence, and refine their understanding of the challenge.
3. Act Phase: Build, test, and iterate on a solution. Teams develop prototypes, implement their ideas, and share results.
4. Reflect: Share results, learn from feedback, and improve. Reflection includes evaluating the process, outcomes, and learning gained.
Examples & Places Used:
- Apple Developer Academy: Teams work on civic tech, accessibility, and product design challenges.
- Universities: Engineering and business students solve sustainability, health, and social impact problems.
- K-12 Schools: Students address local community issues, like recycling or safety.
- Corporate Training: Employees use CBL to innovate and improve workflows.
My Experience:
At the Apple Developer Academy, CBL shaped how I learn and build. Working in teams, we tackled real challenges—like improving accessibility in apps or designing civic platforms. The process taught me to collaborate, iterate, and connect learning to real impact.
Why It Matters:
CBL prepares learners for the real world. It builds critical thinking, teamwork, and adaptability. By focusing on authentic challenges, it makes learning meaningful and empowers students to make a difference.
Learn more about Challenge Based Learning at Apple Learning Center
When building apps with SwiftUI, you’ll often use both structs and classes—but understanding their differences is key to writing clean, efficient code.
Structs are value types. When you create a struct and assign it to a new variable, Swift copies the entire value. This makes structs predictable and safe for UI components. In SwiftUI, views are almost always structs because they’re lightweight and easy to manage. Structs don’t support inheritance, but they do support protocol conformance.
Classes are reference types. When you assign a class to a new variable, both variables point to the same object in memory. Classes are ideal for managing shared state, like data models or observable objects. Classes support inheritance, which lets you build more complex hierarchies. In SwiftUI, you’ll use classes for things like ObservableObject to manage app data and notify views of changes.
When to use each?
Use structs for UI, simple data, and anything that doesn’t need to be shared or mutated across multiple places.
Use classes for shared state, data models, and objects that need to be observed or mutated by multiple views.
struct CityView: View {
var cityName: String
var body: some View {
Text(cityName)
}
}
class CityData: ObservableObject {
@Published var cityName: String = "Detroit"
}Summary: Structs keep your UI fast and safe. Classes help you manage shared, mutable data. Knowing when to use each is a core skill for any SwiftUI developer.
Publishing your app to the App Store is a milestone for any developer. Here’s a step-by-step guide based on my experience:
Tips: Read Apple’s guidelines, test on real devices, and prepare clear screenshots and descriptions. Stay positive—every step is a learning opportunity!
Apple Intelligence is Apple’s new suite of on-device AI features powered by foundation models. I’ve started experimenting with these capabilities in my projects—using the on-device foundation model in Stamped! to generate personalized itineraries for users, and in CommonSight to create dynamic story cards that help tell the story of Detroit neighborhoods. The ability to run powerful AI directly on the device is pretty amazing: it keeps user data private, enables fast responses, and opens up new creative possibilities.
Personal Story: When I first integrated Apple Intelligence into Stamped!, I was blown away by how quickly the itinerary generator adapted to user preferences. It felt like magic—seeing the app suggest routes and activities based on real input. In CommonSight, the story cards became more dynamic and engaging, helping users connect with Detroit’s neighborhoods in a new way.
Technical Details: I used Apple’s foundation model APIs to process user data locally, ensuring privacy and speed. The integration was straightforward, but tuning the model for my specific use cases took some trial and error.
Lessons Learned: On-device AI is powerful, but it’s important to balance automation with user control. I learned to provide clear options and feedback so users feel empowered.
What’s Next: I plan to experiment with more personalized recommendations and interactive features, and I’m excited to see how Apple Intelligence evolves.
User Impact: Early testers loved the privacy and speed, and their feedback helped me refine the experience.
Learn more about Apple Foundation Models
The Laws of UX are foundational principles drawn from psychology and cognitive science that guide designers in creating intuitive, user-friendly interfaces. By understanding how people perceive, process, and interact with information, designers can build products that feel natural and easy to use. I genuinely enjoy design and want to learn as much of it as I can in order to be a stronger software engineer—improving communication and understanding between design and engineering teams.
Personal Story: My interest in design started when I realized how much a simple UI tweak could change the way people use an app. At the Apple Developer Academy, I saw firsthand how accessibility and clarity make a difference for real users.
Technical Details: I apply principles like Hick’s Law and Fitts’s Law in my projects, using minimal navigation and high-contrast buttons. In SlotParking, I used SwiftUI’s accessibility features to make the app usable for everyone.
Lessons Learned: Design is about empathy—understanding what users need and making their experience seamless.
What’s Next: I want to keep learning, attend more design talks, and collaborate with designers to bridge the gap between engineering and design.
User Impact: Feedback from users and mentors has helped me refine my approach and build more intuitive products.
Every project I build—from SlotParking to Stamped!—reflects these principles. I prioritize clarity, reduce unnecessary choices, and use familiar patterns to help users feel confident and in control. Accessibility and usability are always at the core of my design process. Hearing the creator of lawsofux.com speak live at DevCreate313 inspired me to dig deeper into these principles and apply them in real-world projects.
Learning and applying the Laws of UX has made me a more thoughtful designer. I’ve seen firsthand how small changes—like simplifying a menu or making a button bigger—can dramatically improve user satisfaction. I recommend Laws of UX (lawsofux.com) to anyone serious about design. It’s practical, actionable, and rooted in real science.
I’ve used TestFlight to beta test Stamped!, TakeFlight, Relationship Builder, and other smaller projects. The platform makes it easy to distribute pre-release builds, gather real user feedback, and iterate quickly. I feel comfortable with both the technology and the process of receiving feedback—because feedback is a gift. It helps me build software that’s truly usable, not just what I think is right.
Personal Story: The first time I sent out a TestFlight build, I was nervous—what if people didn’t like it? But testers gave honest feedback, and I learned to embrace it. Their suggestions led to real improvements.
Technical Details: I use TestFlight’s crash reports and feedback tools to track issues and prioritize fixes. Managing testers and updates is straightforward, and I’ve built a routine for quick iterations.
Lessons Learned: Feedback is essential. It’s not always easy to hear, but it’s what makes software better.
What’s Next: I plan to expand my tester pool and try new features in future projects.
User Impact: Testers have helped shape my apps, making them more reliable and user-friendly.
Learn more about TestFlight
CommonSight is my first internship and my first experience working with a boss in tech. I’m enjoying the process—learning how to collaborate, take feedback, and build a civic platform that empowers Detroit neighborhoods. The project has taught me about real-world teamwork, technical challenges, and the importance of clear communication. It’s exciting to see our work make a difference in the community.
Personal Story: Early in the internship, I was nervous about working with a boss and a new team. But I quickly learned the value of collaboration and open communication.
Technical Details: We use Firebase and SwiftUI to build scalable features for CommonSight. Integrating AI for story cards was a new challenge, but rewarding.
Lessons Learned: Teamwork and feedback are key. Building for civic impact means listening to the community.
What’s Next: As I get deeper into the internship, I plan to write more about our progress and impact.
User Impact: Community feedback has shaped our roadmap and helped us prioritize features.
Read the CommonSight Case Study
SlotParking is my first MVP designed for real-world impact. I am trying to incorporate all the lessons I learned in the Apple Developer Academy into this project—taking an idea and making it a product in the real world. Instead of building in isolation, I’m launching a hands-on pilot in Detroit—personally visiting parking lots, pitching the app to owners, and using flyers to drive adoption. The goal: make finding a parking spot in busy downtown Detroit easier for everyone, using tech that solves a real problem. By showing the MVP to actual users and lot owners, I’m gathering feedback, validating the product, and learning what works. This approach lets me iterate quickly and build a solution that truly meets the needs of the city. In the future, I will ask for advice on whether this could be monetized.
Personal Story: I remember the first time a lot owner gave me feedback—it was tough, but it helped me see the real needs of users. Every conversation is a chance to improve.
Technical Details: SlotParking uses SwiftUI, Firebase, and real-time updates to track parking spots. I built the MVP with a focus on usability and quick iteration.
Lessons Learned: Building for the real world means adapting fast and listening to feedback.
What’s Next: I want to explore monetization and continue testing to see if SlotParking works in Detroit.
User Impact: User feedback has shaped the app and helped me prioritize features.
Read the SlotParking Case Study
Launching Stamped!—a city passport app on the App Store was a milestone in my developer journey. This was the first app I built that I really felt passionate about, and it showed—I would stay up late and wake up early to build it. I was obsessed. Stamped! lets users explore cities, check in at landmarks, and collect digital stamps for their travel adventures. From initial concept to shipping, I learned how to design engaging progression loops, polish UI/UX for accessibility, and navigate Apple's review process. Responding to real user feedback helped me iterate quickly and improve the experience. Seeing Stamped! live and available to travelers worldwide was both exciting and humbling—and it inspired me to keep building and improving. There are still many things I want to work on in future updates, and balancing that with work and other projects is difficult, but I want to add a live currency converter, a full translator, make it available in different languages, and possibly experiment with monetization through a pro version. This was a real milestone for me. If you're working toward your first launch, stay curious, keep learning, and celebrate every step!
Personal Story: I was obsessed with Stamped!—sometimes working late into the night, sometimes waking up early just to fix a bug or add a feature. The passion paid off when users started sharing their travel stories.
Technical Details: Stamped! uses SwiftUI, CoreData, and integrates with Apple Intelligence for itinerary generation. I focused on accessibility and user feedback throughout development.
Lessons Learned: Passion drives progress, but feedback shapes the product.
What’s Next: I want to add more features, expand to new cities, and experiment with monetization.
User Impact: User stories and feedback have inspired new features and improvements.
View Stamped! on the App Store
Xcode 26.3 feels like a mature, polished IDE for Apple developers. I began learning code at an interesting time—this is my first IDE, and I want it to help me work faster, but also explain things I may not have learned yet. I want it to help me learn and be a tool, not a crutch. The new features—especially improved SwiftUI previews, faster build times, and enhanced accessibility tools—make daily development smoother and more productive. I appreciate the stability and performance improvements, as well as the expanded support for Apple Intelligence APIs. The UI is cleaner, and the debugging experience is more intuitive. One standout is how Xcode is starting to support agentic coding: workflows where AI and automation help generate, refactor, and test code alongside the developer. This shift makes coding more collaborative and efficient, letting me focus on creative problem-solving while routine tasks are handled by smart tools.
Personal Story: Learning code with Xcode as my first IDE was a wild ride. I made plenty of mistakes, but each one taught me something new.
Technical Details: I use SwiftUI, Apple Intelligence APIs, and Xcode’s debugging tools daily. The IDE helps me work faster and learn as I go.
Lessons Learned: Tools are important, but curiosity and persistence matter more.
What’s Next: I want to keep exploring new features and push the limits of what Xcode can do.
User Impact: Feedback from teammates and mentors has helped me improve my workflow.
Learn more about Xcode
If you look closely at Apple’s marketing images, you’ll notice a curious detail: the time on iPhones and iPads is almost always set to 9:41. This isn’t a coincidence—it’s a tribute to a historic moment in Apple’s history.
The Origin: The 9:41 rule began with the launch of the original iPhone. During Steve Jobs’ legendary keynote on January 9, 2007, he revealed the iPhone to the world at exactly 9:41 AM. Apple’s designers set the time in all product images to match that moment, creating a subtle nod to the company’s biggest milestone.
Why 9:41? Apple’s presentations are meticulously timed. The team wanted the product reveal to coincide with the time shown on the screen. When Jobs unveiled the iPhone, the clock matched the keynote’s schedule—making 9:41 a symbol of innovation and precision.
Design Impact: Since then, 9:41 has appeared in nearly every Apple device image, from iPhones to iPads and Macs. It’s a small detail, but it reflects Apple’s attention to storytelling and brand consistency.
Fun Fact: Before the iPhone, Apple used 9:42 for the original Macintosh launch. The switch to 9:41 marked a new era for the company.
Takeaway: The 9:41 rule is more than just a time—it’s a reminder of Apple’s culture of detail, history, and the impact of Steve Jobs’ vision. Next time you see an Apple ad, check the clock!
The Apple Human Interface Guidelines (HIG) are the gold standard for designing intuitive, accessible, and beautiful apps for iOS, macOS, and beyond. As a developer and designer, I’ve found that following the HIG not only improves usability but also helps apps feel at home on Apple platforms.
The HIG is Apple’s official design framework, covering everything from navigation and layout to color, typography, and motion. It’s a living document that evolves with each platform update, providing best practices for building apps that are clear, consistent, and delightful to use.
In projects like Stamped! and SlotParking, I applied HIG principles to design navigation bars, tab bars, and modals that feel native to iOS. I paid special attention to touch targets, color contrast, and dynamic type. Testing with real users helped me refine flows and catch accessibility issues early.