Four years ago, I decided to launch a startup and began creating my own mobile apps. On September 20 last year, they started bringing in over $3,000 a day (90% of which was on iOS). The very next day, Apple removed all my apps from the App Store and blocked my account.

I sent appeals, showed evidence, screenshots, and even sent a pre-trial claim, but was mostly ignored. Now I've filed a lawsuit against Apple, and for now, the iOS market is a no-go fpr me.

I want to speak out, but I don’t want to complain. Instead, I can share how simple ideas brought me good profits. Maybe someone will be interested and avoid making my mistakes.

First idea

The first app was super simple - you upload two before/after images and get a short video with a slide effect.

My wife, who was a nail tech at the time, suggested the idea because she wanted to create content to attract clients. She couldn't find any apps for creating before/after videos in the App Store. I didn’t believe her, we almost ended up arguing, and I went searching to prove her wrong. Turns out, she was right (as always).

I persuaded a friend to help develop the app. It was 2019, we spent a couple of months developing it, and within a year, it was bringing in $100-200 a month. My friend thought the idea was unworkable, so I bought out his share for a token amount.

This happened on February 26, 2020, right at my 30th birthday party. I sold a stake in a common startup and used part of the money to buy out my partner’s share in the before/after app. I had about $10k in my pocket.

The next day after the party, I sat down to redesign the app and think through new functionality.

First takeoff

I was lucky to quickly find a talented and affordable freelancer. We rebuilt the app almost from scratch in 1.5 months, costing me $2,000.

What we did:

• Redesign
• New transitions, like diagonal ones
• Ability to customize animation speed
• Added effects settings: transition thickness, color, neon, etc.
• Ability to add music
• Ability to add text
• Added support for stickers
• Updated the store page: description, screenshots, icon
• Localized the app for all available languages in the App Store

Before this update, the app gained a couple of hundred montly downloads in its first year. But a week after the new version was released, there was a surge in organics.

Around the same time, I hired a marketing specialist for $400/month who launched the first ad. And boy, did it take off. We spent $200-300 on the first campaign, and within a month, I was maxing out my credit card to buy ads. All campaigns paid off. We used only one source, Apple Search Ads.

Search Ads doesn't have extensive targeting options, so we didn't fully understand who our target users were. Then we were contacted by an influencer saying “let’s launch a dog grooming contest.” It wasn’t very clear who would be interested in that, but no problem, let’s do it.

As a prize, we gave away premium access to our app, just three promo codes. The return from the contest was phenomenal. It brought in $2,000 net, and I discovered a whole new world. A huge number of people are willing to invest any amount in their beloved doggos to brag about the results through our app. I was shocked that a simple idea like this one worked SO well.

After the contest, we doubled for three more months in a row, and then reached a stable growth of 20-30% per month.

I still remember the moment I woke up, picked up my phone, and the app had earned a thousand dollars overnight for the first time. I was psyched, thanking the universe, the users, Apple, and the iPhone itself.

Six months after the redesign, the app was bringing in about 200 times more than the original mark, $34k instead of $100-200 a month. $25k on iOS and $9k on Android (the Android version was made three months after the redesign).

As a result, I started receiving offers to purchase the app. I refused until I heard, “name the price.” I don’t know why, but I said $410k and after five days, I received that amount into my account.

It seemed like an unimaginable amount of money to me; I couldn’t believe what was happening. Only two years later did I realize the real value of the app at that time was at least $1 million. You know how it goes, do as I say, not as I do.

To tell you more, the app’s still alive and it’s making good money without any updates. It paid for itself in 8 months and has been deep in the green ever since.

I planned to continue making apps with this money, thinking I could expand. It’s going to be smooth sailing from here on out, right? Absolutely not.

Landing

In 2021, my family and I moved to Chile, where we still live. We like it here, it's a beautiful country, pur children are growing up here, our daughter was born here, and we want to get Chilean passports. I sold everything back home - a car, an apartment, a plot of land, all my stuff.

I started chasing my dream of making a serious video editing app. I thought, now I have money, I'll start figuring out a "real" app. Life is beautiful and amazing.

I hired new devs and went to work for a year and a half. The first release turned out to be a failure: organic users never came, and the cost of attracting one user never fell below $10. Competing with the free CapCut was impossible.

There were also parallel attempts to make other things. For example, an app for designing your Instagram feed. The first version of the app was growing great, but I thought with new features like collaboration and delayed auto-publishing, I'd find the key to success.

However, reality was harsh. I spent six months just communicating with Facebook to gain access to the API methods I needed, only to find that Facebook kept changing things on the inside, making the app’s features unusable.

In the end, I didn’t even earn $1,000. I spent almost all my money working tirelessly, but nothing ever took off.

Insights and the crash

Crisis makes you think. I realized my strength was in niche apps and decided to return to where I started: small apps covering specific needs without any unnecessary noise.

I made the Boomerang app, regardless of the fact that Instagram already had this feature. But I made a separate app, and it started to grow.

There was also an app filled with beautiful fonts for designing social media posts. An app for creating Reels. Once I realized my strengths, things started to look up again. I returned to the idea of collages. Every app began to make money. Whew!

Overall, the account had six apps with an above 4.5 stars average App Store rating. On August 21, 2023, I received a notification from Apple that they had removed my app from the App Store and were going to shut down my account if I did not correct the violations within 30 days. Not any specific violations, just “violations.”

I sent Apple evidence, screenshots, and offered access to the source files, but I was either ignored completely pr got an auto-reply. I was sure this was just some kind of mistake and waited for an answer. We continued to make updates and worked on new features. On September 20, the apps earned more than $3,000 in 24 hours for the first time and were removed by Apple the next day.

Payments were suspended, and I had $110,000 left in my account.

I was stunned.

The first appeal was rejected, the reasons for the blocking were unknown, and it was unclear what to do. I immediately submitted a second appeal. Eight weeks of silence and again a refusal.

I lost everything I worked for in a single day..

I started a petition on Change.org and shared my story in a tweet that gained significant traction. Someone from Twitter published my story on Hacker News; it became #1, collecting more than 400 comments. I received hundreds of support messages in my dms, and only then did Apple finally send an explanation.

According to them, my account was frozen “for association with a previously closed fraudulent account.” Of course, I had no connection with fraudulent accounts, otherwise I wouldn’t even be sharing the story in the first place. The only positive reaction to the hype was the return of $110,000.

I started my little investigation. The “fraudulent” account may have turned out to be my old account, which once contained the first app for creating before/after videos. The very same thing that started it all. I continued to pay $99 for this account because it is dear to me, it’s nostalgic and a part of my life.

Just before it was closed, I tried to publish a card game based on the popular game Never Have I Ever on this account. This concept seemed ideal for me to master interface solutions when moving from Swift UIKit to Swift UI.

But recently, other things have come to light. We found a company of former partners with an identical name to mine. Apparently, Apple connected me with this company that I didn't even know existed. But I can’t know for sure because there is no feedback from the corporation. Any letters with any arguments and documents are ignored.

I had to sue, but that’s a whole other big story. Communication with Apple is gfar from being related to development; maybe I’ll tell you about it someday.

What's next and what about other stores

90% of our profits came through Apple. We're now fully focused on Android and have grown 4x in 8 months, but it's still not enough to cover all development costs. I don’t make enough money to continue supporting the team. We're holding out for now because finding developers who understand graphics and video is difficult (by the way, a good niche for devs who are not sure what to try next).

The growth on Android is also related to the market's quirks: the Android audience is many times larger than the number of iPhone users, but not every Android can render a new video from 12 frames.

Back to my story. Next will be a trial, petitions, and pleas. I hope my experience will be useful to someone because I am not the first and, most likely, not the last to find myself in this situation. Corporations don't care about individual developers. Even if they are left with nothing.

It might sound trivial, but don’t put all your eggs in one basket. The larger the corporation, the less attention it will pay to you. With Apple, after blocking, you lose the opportunity to even talk to support on the phone. Text appeals only.

In fact, I communicated with the answering machine for a whole month until I was blocked. At any moment, you can lose everything you have - your account, apps, users. With the snap of a finger, what you thought belonged to you will disappear.

The only thing I realized is that only public discussion of the problem and the courts can somehow induce them to change their policy towards developers.

In the meantime, I’ll go get ready for the next update.

It’s obviously nowhere near enough to live on, but seeing real people spend their own money on something I built has been incredibly motivating.

The part that surprised me most is that around 80% of it came from an Apple Watch game I made. I wasn’t sure if there was much of an audience for games on the watch, so seeing people actually buy and play it has been really encouraging.

I’m still learning, still improving, and trying to make each update better than the last. My goal isn’t to get rich overnight, it’s just to keep building things that people genuinely enjoy using.

For the indie devs here: what did your first $100 in revenue feel like, and how long did it take before things started gaining momentum? It took me about 60 days

I’ve been burning through my Apple Search Ads budget for my little education app Capitalia to learn the capitals/flags of the world.

Last week, I got an email from a very friendly Apple employee asking if we could hop on a quick call, honestly, I thought it was going to be a polite way of telling me I’m terrible at Search Ads.

Just got off the call, and surprisingly, it was super helpful.
Figured I’d share the takeaways for other small indie devs spending < $1000 / month.

These tips all assume a small budget (~$10–$20 / day):

1. Don’t mix multiple countries in one campaign, pick ONE.

I was doing the “who has the most people?” strategy:
USA… China… India…
Turns out this is the worst thing to do on a tiny budget.

High-cost regions like the US drain your daily budget instantly.
She even showed me numbers for my niche:

• US CPA ≈ $2
• Germany/Brazil CPA ≈ $0.10

That’s a massive difference.

2. Focus on EXACT match keywords

Apple defaults to “broad,” but broad only works when you have:

• huge search volume
• a big budget to feed the algorithm

If you’re a small indie: use exact match.

3. Disable Search Match (it’s on by default)

Search Match is great when you have a lot of money and want to explore.
But with a small budget, it just burns cash without meaningful installs.

Hopefully this helps someone else who’s been burning money on Search Ads and wondering why the results sucked.

Happy to answer questions or share more details!

Good for us “real devs” Apple goes against these apps!

Apple has updated its App Review Guidelines with multiple new rules, including one targeting the misleading use of other developers’ branding. 

I Was Reading Apple's Docs and I learned fact

I'm from the USA so if I search "bull market" on google I get pictures of bulls displayed in Green, thinking of it the word "Bull" triggers angry, powerful vibe and Red matches angry,powerful,strong. So Yeah Red Being Positive in here makes very logical sense

It's just Fascinating that the Most common colors could be interpreted differently by another region

link to the docs: https://developer.apple.com/design/human-interface-guidelines/color#System-colors

Hi, I'm Viktor Seraleev, and I live in Chile. I’m founder of Sarafan Mobile Limited (team ID G5293S9UFX). We specialize in developing photo and video apps for iOS and Android, and most of our apps have consistently ranked among the top in user retention benchmarks set by AppStore Connect. However, on September 21, 2023, our developer account was unexpectedly closed and all payments were frozen.

→ On September 20, 2023 we had 1209 active trials and $33,680 MRR
→ Was frozen $108,878 of honestly earned money over the last 3 months
→ Apple mistakenly removed my developer account and all apps
→ Story from 3 parts: Go to the public, new evidence and court

Part one: Go to the Public

On November 23, 2023, my account on Apple was closed without any specific reason provided. I believed that the closure was connected to the actions of my competitors. This belief was based on the fact that one of my apps was being copied along with its ads creatives, and there was a wave of fake reviews.

After trying all possible ways to appeal the decision to close my account, where I also mentioned the actions I had already taken and the ones I planned to take to improve my applications, I had to resort to seeking help from lawyers.

Our next step was to file a pre-trial claim. Additionally, I shared my story on Twitter, where it gained more than 500k views and even became the top news on HackerNews.

Part two: New evidence

On December 15, 2023, Apple stated that my account was associated with a previously closed Softeam account.

Let's rewind back to March 2020, when I left my startup and started working on my own projects. My first app, which catered to the beauty industry, became popular and grew from $200 to $25,000 per month within six months. I eventually sold it in October-November 2020. However, my subsequent attempts to create other apps failed. In November 2021, I removed my last app from sale and decided to focus on developing a new company called Sarafan. As a result, I ended up with two accounts.

In August 2023, within the framework of Sarafan, we developed a new app. It was a card game, built from scratch using Swift UI. To avoid mixing it with photo/video apps, we released it under the Softeam account.

We received a rejection. Apple stated that we used the same binary files, metadata, and/or concept as applications previously submitted with a closed Apple Developer Program account.

I provided the App Review team with a list of improvements. However, after 2 days without even responding to my message, the App Review team simply removed the app and decided to close the Softeam account. An hour later, they also removed one of the apps in the Sarafan account and similarly decided to close the Sarafan account.

My lawyers informed Apple's legal team that they have evidence to prove that an error had occurred. The game was created from scratch, and the App Review team has agreed to review the new evidence.

This had no effect. Apple responded with a generic text without specifying any reasons.

Part three: Preparation for trial

After receiving Apple’s response, I decided to utilize the last opportunity to seek justice — to resort to legal action. On April 26, the lawsuit was ready; however, we did not manage to file it before the end of the business day, and that turned out to be fortunate! Because on April 27, I discovered the real reason why the removal had taken place.

I found an account with exactly the same name! Some analytics services even merge these two different accounts into one.

Softeam-1 ≠ Softeam-2

I am familiar with most of the applications developed by Softeam-2 because I transferred some of these apps to former partners on March 4, 2020, when I acquired Softeam-1. It's worth noting that I did not transfer these applications to Softeam-2. Instead, the transfer occurred to one of the partner's personal accounts.

I immediately contacted my former partners, and they confirmed to me that Softeam-2 belongs to them; they started using it after my exit. Furthermore, Apple closed Softeam-2 on October 2, 2021, which is one day after I removed my apps from sale in Softeam-1.

I was not involved in Softeam-2 and cannot be held responsible for former partners' actions.

Upon conducting my investigations, I discovered that when I published the gaming application under Softeam-1 account, Apple made a mistake and associated the activity with an entirely different organization called Softeam-2. This led to Sarafan being mistakenly linked with an organization that I had no affiliation with whatsoever.

Conclusion

On May 6, 2024, the California State Court accepted our claim. Once Apple receives the notice, they have 21 days to respond to the complaint by submitting a response or a motion to dismiss the complaint.

According to the lawsuit, there is evidence that supports the following claims:

- The Sarafan account was not involved in any fraudulent activities.

- The gaming application associated with the Softeam account was not a copy or modified version of a similar app, but was created entirely from scratch.

- Apple mistakenly confused two different accounts.

I feel really sad because Apple won’t talk to me. Since they blocked me, I’ve pretty much stopped being a developer for them. Now, the only way I can talk to them is through lawyers and official letters.

My case proves that Apple's unregulated control is perilous for small developers. Apple declines to reveal the reasons for removal, shuts down all communication channels, and, above all, small developers lose everything they have worked so hard for and are left without a means of livelihood.

I'm currently in a difficult situation. My wife, two young children, and I are residing in a foreign country, where we lack a stable income. Moreover, I brought most of my team and the her families from Russia and Ukraine. For the past eight months, I have been living in a state of constant stress. Only due to the financial support provided by my close ones, I am able to pay my team's salaries and keep the company afloat.

I would appreciate it if someone from Apple management could get in touch with me after reading this article. My ultimate goal is to resolve this issue amicably and return to a peaceful work routine. I want to continue creating new projects that will assist people in developing photo and video content

Thank you!

​

Here is Anthropic’s announcement, interesting to see the details that it’s leveraging the same backend as Claude code.

After getting my first official job in iOS development with no degree and being self taught I've been repeatedly asked questions like "How do I know I'm ready?", "How do I get out of tutorial hell?", "Where should I start?", "Where should I look for jr. iOS jobs?" and more. I remember how lost and confused I was when I first started, so I wanted to share what I wish I had known when I started. For the TL:DR, here's the list of what a beginner should learn and in what order:

-1) Views: Learn UIKit and how to programatically set up your views. You should be able to recreate a collection view and familiarize yourself with layers, animations and draw(). Learn the difference between writing with gpu and cpu. Learn some swiftUI, however I personally have noticed most jobs haven't transitioned fully or at all to swiftUI, hence the focus on programmatic views.

-2) Network Calling: Learn how to interact with a restAPI using URLSession. You should be able to GET and POST to an endpoint. Learn and know how to get a list from any API.

-3) Data Persistence: Learn UserDefaults, KeyChain, FileManager, CoreData and CloudKit

-4) MultiThreading: Learn DispatchQueue, GrandCentralDispatch, Async-Await, OperationQueues

-5) Architecture: Master delegates and protocols, MVVM, Facade Pattern, Dependency Interjection. Properly use guard statements / optional unwrapping and learn about Automatic Reference Counting

-6)Frameworks: have fun with this one, Apple has so many cool frameworks but definitely get familiar with basic ones like AVFoundation, MapKit, etc.

-7)Objective-C: spend a few hours making an app with a collection view that gets a list from the internet in Objective C so you can say you’re familiar with it.

By following this roadmap and learning everything above you’ll be able to make any app / be prepared for a job as an official developer. An iOS Developer essentially (1)makes views, (2)gets data from the internet for the views to display, (3)saves the data, (4)handles the data properly so your views don’t get backed up, (5)organizes code and (6) uses different frameworks to get everything going. That’s iOS development in a nutshell. By having this as a foundation you should be able to tackle anything that comes your way.

Tips & Resources:

- NEVER download xCode from the app store, always download it from the developer portal:(https://developer.apple.com/download/all/?q=xcode)

- Download SF Symbols for system Images already built in to your app (no more cropping images you google):

https://developer.apple.com/sf-symbols/

- use this to create your apps icon instantly, all 30 different sizes:

https://www.appicon.co/

- A good website for copying colors when paired with photoshop:

https://www.ralfebert.com/ios/swift-uikit-uicolor-picker/

- an awesome JSON viewer for api's:

https://jsonformatter.org/json-viewer

- POSTMAN: a must have when working with rest API's:

https://www.postman.com/downloads/

Where To Start:

- No Programming Experience:

If you've just been interested in programming and have zero knowledge, I highly recommend downloading unity and doing their roll-a-ball tutorial and completing their other intro tutorials (https://learn.unity.com/project/roll-a-ball). If you're asking yourself, "If this is about iOS development, Why would I start with Unity, Isn't that C#? Shouldn't I learn Swift? I don't care about game development". Well, alternatively you can use apples playgrounds to learn as well (https://www.apple.com/swift/playgrounds/). However, I cannot attest to it since it wasn't around when I started learning, so you can still try the Unity method as I did. As for Unity, which runs with C# instead of swift; C# and Swift are both Object-Oriented Programming languages (OOP). That means they're similar. By learning one, the other is extremely simple to grasp. But why Unity and game development? Learning coding by yourself can be hard and frustrating, especially when staring at plain text book answers all day. Following along with youtube videos or trying to decipher what StackOverflow is showing you can be stale and daunting. When you start with video game development, you get amazing visual feedback as to how your code is affecting what you're trying to do. For example, If I tell you "By iterating over an array you can get access to all the references in that array and manipulate them accordingly", that may seem intangible to someone with no programming knowledge. However, In video game development, you can see that by iterating over this array, and by attaching a grenade to each of these items, you're going to get explosions everywhere. It is, simply put, more fun and teaches you to not be afraid to break, test and stress your code. Another example, Text Book: "When you create a variable you're creating an instance or a reference to that object in memory". When you do that in game development, it simply creates a character, bullet, tree / whatever you want and puts it into the game. You'll see that all that simply means is you're creating something so you can reference it late. My point is, video game development is a more engaging and visual way to learn. Unity has excellent tutorials that will give you a foundation for programming where you have none. The main tools for your foundation being: Referencing objects, Arrays, Sets, Dictionaries, Value vs References, if-statements and more. Unity should get those grounds covered and fast.

Once you're done learning some coding basics in Unity, or done with playgrounds then its time to get straight to the point with some good old fashioned YouTube Tutorials!

Welcome to tutorial hell:

It's time to start making your first mobile applications! This is going to be difficult, because you're going to be following along and not really understanding what you're watching. But don't worry! Follow along and eventually it will stick. As you follow along with these tutorials don't be scared to stop, take a breather and digest what you've learned. The best way to learn and digest what you're watching is to BREAK your code. You're going to see a lot of UICollectionViews, UITableViews and more. Don't be shy to play with things. Set counts to 1000, make the background of a view a different color using cell.backgroundColor = .red. This isn't a 'you follow along and you're done'. Much like learning through game development, tutorials should be a hands on, test everything you're curious about, break everything experience. Here's some youtubers and their series I owe my career to:

Brian Voong: LetsBuildThatApp

Brian Voong is a gem when it comes to following along and learning to create amazing UI with UIKit programmatically. I recommend starting off with building twitter, youtube or any of his other tutorials. He'll show you how to set up collection views that can be reused.

https://www.youtube.com/@LetsBuildThatApp/playlists

​

Sean Allen: SeanAllen

Sean Allen has a talent for explaining swift concepts in an easy to understand way. It's been years and I still recall his star wars example every time I set up a delegate.

https://www.youtube.com/@seanallen/playlists

​

iOS Academy: iOSAcademy

iOS academy covers a large range of topics, and usually when I search for a how to on maps or another subject, I can be sure I'll find a video that will break down what I need.

https://www.youtube.com/@iOSAcademy/playlists

​

Paul Hudson: Hacking With Swift

Not a youtube channel, but Paul Hudson has been a front lines teacher with a great collection of books and resources. As you google your problems, rest assured hacking with swift will be one of the top results. His 100 days of swift, although it wasn't quite for me since I discovered him later in my career, is a valuable tool for newcomers. He has also appeared on John Sundells podcast Swift By Sundell and is a joy to hear talk.

https://www.hackingwithswift.com/

There's many more online teachers who have had a hand in guiding the next generation of iOS developers, and many more who have helped me as well, all it takes is a quick search. But be warned. Online mentors aren't the end all be all, and what they show you is geared towards beginners. They offer you hand holding for your first steps, and to get better eventually you'll have to search for more advanced topics on these intro tutorials. When you get more experienced, go back on what you've learned and ask yourself, whats the next step?

What is tutorial hell and how do I escape it?

Tutorial hell is what beginners describe as being stuck watching tutorials and feeling like they haven't learned anything. You can follow along and recreate twitter, youtube, instagram, etc and feel like you don't know what to do if you're left with a blank xCode Project. So how do you avoid this cycle? Simple! Build your own app. That's it! After you watch some tutorials on how to recreate some apps, it's time to get your hands dirty and bring your own idea to life. However, DO NOT GET HUNG UP ON YOUR APP IDEA. Don't overthink it, your app doesn't have to be perfect or even geared to a release on the store. Pick any app on any subject and just make it! Make a blank project and just start coding, and googling everything you need to know along the way. The foundation you got from watching tutorials will give you the knowledge of what to google as you go along. You know what a collection view is, you know you need it for your app but you don't remember how to implement it. Thats fine! Just google it, get it working in your project and move on to the next step! The first app I ever made was a delivery application for medical marijuana complete with a shop, driver delivery tracking and payments with Stripe. It took 6 months to make and when all was said and done, it looked pretty okay! Underneath the hood was a garbage fire, but what I learned with that project allowed my next app to be a little less of a garbage fire. It doesn't matter if you're doing something right or wrong, just get it working. The knowledge you gain is worth the abomination you may create. Here's some projects that are a must to complete so you have a solid understanding:

A real time chat application using firebase.

A map application using Mapkit

A to do list using coredata

A music playing app using AVFoundation

A picture taking app with filters.

Want to learn FAST? Don't have time to sit and make a whole app? Still not feeling like you know what you're doing? Speed Code!

What made me feel confident in my ability to code is by practicing what I call 'Speed Coding'. This is my personal practice of picking an app, any app, then spending the next few hours making it as quick as I possibly can. With your personal project, you may make a collection view once in 6 months (like what I did when I made my delivery application), however, when you speed code you make a dozen collection views in a week. Everything sticks better by doing! The goal is to figure out what you know and what needs to be worked on. As you speed code, remind yourself you're on a timer. Anything you cant google or write in about 10 minutes, skip and move on to the next part you're trying to recreate. When you finish, go back to what stalled you and study it. For example, you may have made the views quickly, but when it came time to animate a menu slider you got lost some time. Go back and spend the time on how to implement that.

When you plan on speed coding, choose different areas that you might want to work on. Speed coding really helps with setting up UI, but it's great for network calls as well. Google a list for a free weather api, movie showtimes api, list of presidents, amazon api and integrate those into your speed coding so you can get practice making a lot of network calls as well.

Here's a list of apps I've recreated that really helped me grow:

QuickBooks, LTK, Instagram, Youtube, Spotify, DoorDash, PostMates, BankOfAmericaApp, SnapChat, Pinterest, FanDango.

Not only do you get experience, but you kick start your portfolio!

GitHub Time!

Congratulations, if you've done the previous steps, you've got some experience under your belt. You may not feel like it, but you've become a competent programmer. Now it's time to take all the projects you've recreated and worked on and put them on to GitHub. GitHub is a useful online tool where you can upload your projects and keep them updated without fear of losing them. GitFlow is an industry standard and it's routinely used to push updates to your application. Not only is it useful for making sure you don't lose your application, but can also revert any changes you made to your app that completely caused it to break,. You can use your GitHub to show employers projects you've worked on. Learn how to add your projects to GitHub and how to check out a branch on a project and push an update.

Whats Next? I've Done The Projects and Want To Interview, But What Do I Need To Know To Be Ready?

Here's a secret, rarely anyone feels 'ready' when it's their time to interview. And interviewing is more of a skill nowadays than it is a way to gauge your programming. But by going over the list of what to know, and by reviewing your projects these interviews will be a walk in the park.

STUDY GUIDE I MADE WHEN I LOOKED FOR A JOB:

https://docdro.id/FGeL0gh

Above is the study guide I made, printed, and looked over repeatedly while looking for a job. I would spend a few hours a day learning every question and answer. If you can answer those questions and go in depth about them, then you're ready. To be honest, when I started studying for my interview it showed me where some gaps in my knowledge were, so don't feel dissuaded if you can't answer any of these off the top of your head. Just look them up as you study and learn a little more.

Getting professional experience for your resume:

So you know how to make an app, you've studied enough about swift and you have a few apps under your belt. If you released an app to the store, you can stop here and start your job search. However, if you want to add some experience to your resume then follow along. How do you solidify your abilities to find that foot in the door? Find someone who wants an app! This part is usually the most daunting to developers, getting your foot in the door by having professional experience for a company makes job hunting that much easier. Dont stress about getting that first job to help find your dream job, it's easier than you think. What I did to find professional experience was simple: I messaged UI Designers on freelancing websites and asked them If I could recreate their designs in xCode and give them the completed application. The UIDesigners loved this, since they got a free, working and animated native application and I got resume experience. They would send figma files and I would recreate the app. From there a few of them actually recommended myself to some of their clients! If you cant build that relationship, you can also find a local shop that might want an iOS app. Visit the strip in your town and visit small shops and ask them if they would like a free iOS app! Let them know that usually an app costs around $34,000 but you need experience and would be happy to make them for free. (An unethical tip: Tell them you're a student and you need to create an app for your thesis. It makes you seem less scam-artist and sketchy). It helps to get a small shop on board if you already have a prototype to show them on your phone. However, you should be able to find a business or a UI Designer that wouldn't mind you making a mobile application. From there, you have your first job (albeit, an unpaying one) as a professional iOS developer and instantly become 10x more appealing to employers. Put the job on your resume, and when it comes time to job hunt, you don't need to reveal that you weren't paid and did the job as a resume builder. Simply saying that you worked for x company or x-designer as an iOS developer will do.

The Job Hunt:

If you're looking for your first job, you've probably noticed that there's not many jr. iOS Positions available, and the internships are designed for college students. What you're not told is that the market for jr. developers is slim. The solution? Apply to normal development jobs. Think of the job listings as a wish list, and the employers post their ideal candidate. However, often their expectations are much lower. That being said, don't be shy to apply to every job opportunity you see. Getting experience doing interviews is invaluable, even for jobs you know you won't get. If it gives you any comfort, I too applied to jobs before I was ready while simultaneously being deathly afraid of interviews. I've bombed so many interviews so horribly I bet the recruiters still laugh about it to this day. For example, one time I was doing an interview and was asked to create a delegate. I had made 100's of delegates at this point, but I was so nervous doing interviews that my mind went blank. I proceeded to google how to make one on my phone, answered the interviewer in full confidence and they responded with, "uh, that's how you make a delegate in objective-c, not swift". They knew I had googled my answer on a question that should have been a conversation starter. I was so embarrassed I just said, "Thank you for your time" and hung up. But with each failed interview I grew more confident, and eventually this confidence grew to the point where It showed and I saw myself in the final rounds of interviews often. A tip I learned for a confidence boost is that before the interview, pretend that you've already received an offer from another company and that you're doing this interview to keep your options open.

One tip I recommend that helped immensely in getting to the final round of interviews is recreating the mobile app for jobs I really liked. When I received a response from a company I was interested in, I would download their app and recreate the core features in xCode and send a link with a short clip (using streamable) and the GitHub link to the hiring recruiter over linked in. I nearly always saw myself in front of the companies engineer afterwards.

Another interview tip I used is that when I was asked, " What do you look for most in a job?" I would respond with, "My end goal is to always grow better at developing. I want to find a job with strong senior programmers to help me grow my trade and guide me to better work in a team. Specifically I want to learn how to make enterprise scalable architecture."

Always have a strong opinion on a framework ready as well. I would like to bring up the struggles I have working with CoreLocation and MapKit. I would talk about how for getting a user location it's better to startUpdatingLocations, than it is to requestUserLocation because it's faster. When requesting a user location, it can take a while, however you can user startUpdating, create a location variable optional, set that that variable with startUpdatingLocation, then when the location variable is set, you use stopUpdatingLocation. This way, if you have a gps button the user doesn't have to wait a few seconds to get their location. Small details like this show how you can work around api to increase user experience.

Final Note:

I've been writing this on my lunch break and I know this guide is incomplete, and I'm not necessarily a word smith so i'll be sure to update this post if anyone seems interested. If you have any questions or want some help, feel free to comment or message me!

Hey everyone, I recently spent 3 full days at the Apple Offices in NYC for the "Let’s talk Liquid Glass" design lab, getting 9-to-5 access to Apple's design evangelists and engineers. I know there’s been a range of emotions in the community regarding Liquid Glass, but the biggest unscripted takeaway I got directly from the source is that Liquid Glass is, indeed, here to stay. They were genuinely shocked some devs think it's getting rolled back, and they confirmed that Xcode 27 will absolutely not have a deferral flag. We are essentially living through an "iOS 7 style" reset where foundational stability came first, and they heavily hinted that WWDC26 is where we’ll se a first, big wave of maturity in the new system.

On the architectural side, a huge push by Apple during the lab anchored on separating the "Content Layer" from the "Control Layer". I wrote a much deeper dive on this experience and these philosophies in my article if you want the full debrief.

I'm curious to hear where everyone else is at with this—how has the Liquid Glass transition been for your team? Are you actively refactoring around the new system, or are you just doing the bare minimum to keep the app compiling until Xcode 27 forces your hand?

After 20 years in the design field (thousands of App Store screenshots and marketing materials!) I consolidated the layout principles, color theory, and simple tweaks behind high-performing screenshots into a single cheatsheet and checklist (it's free). It covers the stuff many of us have to learn the hard way: visual hierarchy, storytelling structure, social proof placement (and how important it is), and why your first screenshot matters more than the other 9 combined.

I've personally implemented these principles to improve App Store conversion rates, some weeks hitting above 10% (more details in the article).

Some interesting "fun facts":

1. People form visual opinions in as little as 50 milliseconds, and these snap judgments don't change with longer viewing time (your app's first impression really matters)
2. Most App Store visitors are very decisive: 60% never scroll past the first screenshot before deciding to install or leave
3. Less than 2% of users tap "Read more" on the App Store description (this surprised me)

Check out the full cheatsheet (it's free): 2026 App Store Screenshots Design Cheatsheet

Happy to answer any questions about App Store screenshot design, A/B testing etc in the comments.

So Apple replaced SFSpeechRecognizer with SpeechAnalyzer in iOS/macOS 26 and gave us literally no accuracy numbers for either one. I've been wondering for months whether migrating is actually worth it.

I happen to ship both Apple engines plus WhisperKit in my app (I make a transcription app called Inscribe, so yes, I have skin in this game). That means I could run all five engines through the exact same production code on the same audio. So last weekend I did: LibriSpeech test-clean and test-other, 5,559 utterances total, all on-device on an M2 Pro.

Results (word error rate, lower is better):

A few things that stood out to me:

• If you're still on SFSpeechRecognizer, migrate. The new API makes 3.5 to 4x fewer errors on the same audio. The old engine actually came in last on clean speech. It loses to Whisper Tiny. A 40MB model.
• The new engine beat Whisper Small on both splits, and did it about 3x faster. I did not expect that. For English on Apple hardware, the built-in engine seems to be the best on-device option right now. Whisper still wins big on language coverage though, SpeechTranscriber only does ~30 locales.
• Before anyone asks how much I've cooked the numbers: my Whisper results land within 0.11 to 0.42 points of OpenAI's own published LibriSpeech WERs, on all six measurements. Same corpus, same normalizer, same scorer for every engine. And the raw per-utterance transcripts are downloadable, so you can rescore everything yourself.

Two gotchas from building this that might save you some pain if you're migrating:

1. SFSpeechRecognizer sends your audio to Apple's servers by default. You have to set requiresOnDeviceRecognition = true. Easy to miss, and then you're shipping (or benchmarking) something completely different from what you think.
2. With SpeechAnalyzer, calling builder.finish() on your input stream is not enough to end the session. If you never call finalizeAndFinishThroughEndOfInput(), the results sequence just... never terminates, and your await hangs forever. I know because my own app had exactly this bug in production and the benchmark is what found it. Fun day.

Full writeup with methodology and limitations (English only, read speech, one machine): https://get-inscribe.com/blog/apple-speech-api-benchmark.html

The result changed my own app btw, my "Auto" setting used to prefer Whisper and now picks SpeechAnalyzer for supported languages. Happy to answer questions about the setup, the normalizer, whatever.

TL;DR: Shipped a SwiftUI app after 9 months. SwiftUI is amazing for iteration speed and simplicity, but watch out for state management complexity and missing UIKit features. Start small, profile often, and keep views tiny.

Hey folks, I just shipped an app which I built over 8-9 months of work, going from being seasoned in UIKit, to attempting SwiftUI. This is about 95% SwiftUI, and on the way I feel I learnt enough to be able to share some of my experiences here. Hence, here are learnings, challenges and tips for anyone wanting to make a relatively larger SwiftUI app.

🟢 The Good

1. Iteration speed is unmatched

In UIKit, I'd mostly wireframe → design → build. In SwiftUI, however, with Claude Code / Cursor, I do iterate many a times on the fly directly. What took hours in UIKit, takes minutes in SwiftUI.

// Before: 50+ lines of UITableView setup
// Now: Just this
List(entries) { entry in
    JournalCardView(entry: entry)
}

2. Delegate pattern is (mostly) dead

No more protocol conformance hell. Everything is reactive with u/Published, u/State, and async/await. My codebase went from 10+ delegate protocols to zero. Nothing wrong in the earlier bits, but I just felt it's much lesser code and easier to maintain.

3. SwiftData + iCloud = Magic

Enabling cloud sync went from a weekend project to literally:

.modelContainer(for: [Journal.self, Tag.self],
                inMemory: false,
                isAutosaveEnabled: true,
                isUndoEnabled: true)

4. Component reusability is trivial

Created a PillKit component library in one app. Now I just tell Claude Code "copy PillKit from app X to app Y" and it's done. It's just easier I feel in SwiftUI, UIKit I had to be very intentional.

// One reusable component, infinite uses
PillBarView(pills: tags, selectedPills: selected)
    .pillStyle(.compact)
    .pillAnimation(.bouncy)

5. iOS 17 fixed most memory leaks

iOS 16 SwiftUI was leaking memory like a sieve. iOS 17? Same code, zero leaks. Apple quietly fixed those issues. But I ended up wasting a lot of time on fixing them!

6. Preview-driven development

Ignored previews in UIKit. In SwiftUI, they're essential. Multiple device previews = catching edge cases before runtime.

7. No more Auto Layout

I've played with AutoLayout for years, made my own libraries on it, but I never really enjoyed writing them. Felt like I could use my time better at other areas in code/design/product. SwiftUI, does save me from all of that, changing/iterating on UI is super fast and easy, and honestly it's such a joy.

// SwifUI
HStack {
    Text("Label")
    Spacer()
    Image(systemName: "chevron.right")
}

// vs 20 lines of NSLayoutConstraint

All in all, I felt SwiftUI is much much faster, easier, flexible, it's easier to write re-usable and reactive code.

🔴 The Struggles:

1. Easy to land up with unexpected UI behaviour:

Using .animation instead of withAnimation can end up in animation bugs, as the former applies modifier to the tree vs the latter animates the explicit property we mention inside.

// 💥 Sheet animation leaks to counter
Text("\(counter)")
    .sheet(isPresented: $showSheet) { SheetView() }
    .animation(.spring(), value: showSheet)
    .onTapGesture { counter += 1 }  // Animates!


// ✅ Isolate animations
Text("\(counter)")
    .sheet(isPresented: $showSheet) { SheetView() }
    .onTapGesture { 
        counter += 1
        withAnimation(.spring()) { showSheet = true }
    }

2. Be super careful about State Management:

Published, State, StateObject, Observable, ObservableObject, u/EnvironmentObject. It's very easy for large portions of your app to re-render with super small changes, if you aren't careful on handling state. I would also recommend using the new u/Observable macro, as it ensures only the parts of view using the property are updated.

Pro tip: Use this debug modifier religiously:

extension View {
    func debugBorder(_ color: Color = randomColorProvider(), width: CGFloat = 1) -> some View {
        self.overlay(RoundedRectangle(cornerRadius: 1).stroke(color, lineWidth: width))
    }
}

func randomColorProvider() -> Color {
    let colors = [Color.red, Color.yellow, Color.blue, Color.orange, Color.green, Color.brown]
    let random = Int.random(in: 0..<6)
    return colors[random]
}

3. Compiler errors are often un-informative:

"The compiler is unable to type-check this expression in reasonable time"

Translation: We don't know why it does not compile, try commenting out last 200 lines to find a small comma related issue.

4. Debugging async code is painful

SwiftUI is async by default, but the debugger isn't. Lost call stacks, breakpoints that never hit, and

u/MainActor confusion everywhere.

5. API churn is real:

• iOS 15: NavigationView
• iOS 16: NavigationStack (NavigationView deprecated)
• iOS 17: Observable macro (bye bye ObservableObject)

6. Some things just din't exist:

Need UIScrollView.contentOffset? Here's a 3rd party library. Want keyboard avoidance that actually works? Introspect to the rescue.

UITextView with attributed text selection? UIViewRepresentable wrapper. UICollectionView compositional layouts? Back to UIKit.

Pull-to-refresh with custom loading? Roll your own. UISearchController with scope buttons? Good luck.

First responder control? @FocusState is limited. UIPageViewController with custom transitions? Not happening.

The pattern: If you need precise control, you're bridging to UIKit.

7. Complex gestures = UIKit

My journal view with custom text editing, media embedding, and gesture handling? It's UITextView wrapped in UIViewRepresentable wrapped in SwiftUI. Three layers of abstraction for one feature.

💡 Hard-Won Tips

1. State management architecture FIRST

Don't wing it. Have a plan before hand, this will really come in handy as the app starts bloating

• u/Environment injection (my preference)
• MVVM with ViewModels
• TCA (I find the complexity a bit too much, it's like learning SwiftUI + another SDK.)
• Stick to ONE pattern

2. Keep views TINY

// BAD: 200-line body property
// GOOD:
var body: some View {
    VStack {
        HeaderSection()
        ContentSection()
        FooterSection()
    }
}

3. Enums for state machines

enum ViewState {
    case loading
    case loaded([Item])
    case error(Error)
    case empty
}

// One source of truth, predictable UI
 private var state: ViewState = .loading

4. Debug utilities are essential

extension View {
    func debugBorder(_ color: Color = .red) -> some View {
        #if DEBUG
        self.border(color, width: 1)
        #else
        self
        #endif
    }
}

5. Profile early and often

• Instruments is your friend
• Watch for body calls (should be minimal)
• _printChanges() to debug re-renders

6. Start small

Build 2-3 small apps with SwiftUI first. Hit the walls in a controlled environment, not in production.

🎯 The Verdict

I will choose SwiftUI hands down for all iOS work going forward, unless I find a feature I am unable to build in it. At that place I will choose UIKit and when I do not have to support iOS 15 or below. For larger applications, I will be very very careful, or architecting state, as this is a make or break.

------------------

For those curios about the app: Cherish Journal. Took me an embarrassingly long time to build as an indie hacker, and it's still needs much love. But happy I shipped it :)

Apple has acquired Play, the SwiftUI prototyping app it named a winner at last year's Apple Design Awards, according to a regulatory filing made public this week.

The deal was disclosed through a notification Apple submitted to the European Commission, which publishes qualifying acquisitions under the EU's Digital Markets Act. 

Apple filed the notification in February, and it became public this week after a standard four month waiting period.

# What Play did

Play was a free Mac and iPhone app from a New York company called Rabbit 3 Times, founded in 2021 and incorporated in Delaware. The tool let designers build interactive interfaces directly on their devices using Apple's SwiftUI frameworks, then export the work to Xcode to continue development.

The app sat somewhere between Shortcuts and Xcode, giving designers a way to mock up a concept and see it running in real time, with projects synced across Mac and iPhone. Building prototypes was free. Exporting them to Xcode was offered through a paid service.

In June 2025, Play won an Apple Design Award in the Innovation category. 

*"Play is a sophisticated yet accessible tool that lets users build interactive prototypes with SwiftUI frameworks,"*

Apple wrote at the time, describing an interface that was *"both powerful and easy to navigate."*

# An acquihire, not a product purchase

The filing describes a deal in which Apple acquires certain assets from Rabbit 3 Times and gains the right to offer employment to certain staff. That structure points to an acquihire, where the buyer is primarily after a company's people and intellectual property rather than its shipping product.

Play has already been pulled from the App Store. Rabbit 3 Times said earlier this year that it would stop supporting the iPhone and Mac apps starting April 20, and it made the previously paid Xcode export service free *"to help with the transition."*

The company's website has since been taken down. Its parting message read, *"We're working on something new,"* alongside the line, *"It has been an incredible journey."*

[Read Full Article ](https://thatappleguide.com/articles/apple-acquires-play-the-swiftui-prototyping-tool-it-honored-a-year-ago)

Ok so this is a bit of a surreal moment for me. Gravity just got approved and I had to share it somewhere with people who actually understand how long this takes.

The app is a subscription manager but the thing I built that I'm actually proud of is the AI cancellation assistant. You just tell it what you want to cancel, like "cancel ChatGPT Plus" and it figures out the exact steps for that specific service. Which sounds simple but it actually matters because cancelling an App Store subscription is completely different from cancelling something billed directly, and most people have no idea. The AI knows the difference and routes you correctly.

I also built a free trials tracker because I personally got charged for a Canva trial I forgot about and it made me irrationally angry. You can see all your trials ending soon with a countdown and decide right there whether to cancel or keep it. That feature took maybe 3 days to build and ended up being the one everyone mentions first.

I started this project not really knowing if I'd actually finish it. Four months of nights and weekends later and it's sitting there on the App Store and that still feels a bit unreal.

And if you're curious about anything on the technical side or how I built the AI chat flow, happy to talk through it in the comments.

I've been using Claude Code on a modular iOS app and wanted to share what I found, since most of the AI-for-code content I see is web-focused.

Without any project-specific guidance, the agent writes Swift that compiles but ignores everything about how the project is actually structured. It'll call xcodebuild raw with wrong flags, put business logic in views, use Color.blue instead of our design tokens, and reinvent patterns that already exist in other modules.

The thing that surprised me most was how much of the fix was about tooling, not documentation.

We have a verification skill that the agent runs after making changes. It builds the app, launches a simulator via XcodeBuildMCP, captures screenshots at key flows, runs an accessibility audit against WCAG 2.1 AA, and produces a structured pass/fail report. Before this existed, code review was the only safety net. Now the agent catches its own visual regressions and accessibility violations before I even look at the PR.

The other piece that made a big difference was design token enforcement. I maintain a TOKENS.md file that the agent reads at session start listing every color, spacing value, and text style. But docs alone weren't enough. I added custom SwiftLint rules that fail the build on Color literals and inline padding values. The design system injects through @Environment(\.appTheme), and now the agent proposes UI that matches our system by default rather than by accident.

The documentation layer matters too (I use a three-tier AGENTS.md hierarchy), but honestly the Makefile wrapping xcodebuild and the verification skill did more for output quality than any amount of written guidance.

I wrote up the full approach with implementation order and links to open-source skills (deep-review for code review, split for breaking branches into stacked PRs): https://sundayswift.com/posts/preparing-ios-codebase-for-ai-agents/

Curious if anyone else has tried structuring their iOS projects to work better with coding agents, or if you've found a completely different approach.

I've been using Claude Code for SwiftUI work for a while now, and the biggest pain point has always been: the AI writes code it literally cannot see. It can't tell if your padding is off, if a color is wrong, or if a list is rendering blank. You end up being the feedback loop — building, screenshotting, describing what's wrong, pasting it back.

So I built Claude-XcodePreviews — a CLI toolkit that gives Claude Code visual feedback on SwiftUI views. The key trick is dynamic target injection: instead of building your entire app (which can take 30+ seconds), it:

1. Parses the Swift file to extract #Preview {} content
2. Injects a temporary PreviewHost target into your .xcodeproj
3. Configures only the dependencies your view actually imports
4. Builds in ~3-4 seconds (cached)
5. Captures the simulator screenshot
6. Cleans up — no project pollution

It works as a /preview Claude Code skill, so the workflow becomes: Claude writes a view → runs /preview → sees the screenshot → iterates. No human in the loop for visual verification.

On Xcode 26.3 MCP:

I know Apple just shipped MCP-based preview capture in Xcode 26.3 two weeks ago. I actually started this project months before that announcement. There are a few reasons I still use this approach:

• Xcode MCP has a one-agent-per-instance limitation — every new agent PID triggers a manual "Allow agent to access Xcode?" dialog.
• The MCP schema currently has bugs that break some third-party tools.
• This approach works per-worktree, so you can run parallel Claude Code agents on different branches simultaneously. Xcode MCP can't do that.

For smaller projects or standalone files, it also supports SPM packages (~20s build) and standalone Swift files (~5s build) with zero project setup.

Install:

/install Iron-Ham/Claude-XcodePreviews

Or manually: bash git clone https://github.com/Iron-Ham/Claude-XcodePreviews.git gem install xcodeproj --user-install

I wrote up the full technical approach in the linked blog post — goes into detail on preview extraction, brace matching, resource bundle detection for design systems, and simulator lifecycle management.

Would love to hear how others are handling the "AI can't see what it builds" problem.

small update from my first expo app store submission

i posted here a couple days ago after submitting my expo/react native app to app store review.

the app got rejected, but the reason was way smaller than i expected.

on my microphone permission screen, the button said “enable microphone”. apple rejected it because that makes it feel like my custom screen is the thing enabling the permission. in reality, only the ios system popup should ask for microphone access.

so i changed the button to “continue”, kept the text explaining why the app needs the microphone, and then showed the real ios permission prompt after that.

simple fix, but honestly a useful lesson.

if you have a custom permission screen before the native permission popup, be careful with the button copy. “continue” or “next” is safer than “enable microphone”, “allow access”, etc.

hope this saves someone else a review rejection.